[gnso-rds-pdp-wg] authoritative

[Greg Shatan]

I agree with the proposition that we can disentangle the issue of "data of
record" from the issue of accuracy.  I strongly disagree with the idea that
accuracy is "probably outside the scope of our task."

As a matter of fact, accuracy is one of the core issues that this WG was
chartered to deal with.  This is obvious from a review of the charter,
which includes the following statements (emphasis added):

 *As part of its Phase 1 deliberations, *the PDP WG should work to reach
consensus recommendations

by considering, *at a minimum*, the following complex and inter-related
questions:

· *Users/Purposes: *Who should have access to gTLD registration data and
why?

· *Gated Access: *What steps should be taken to control data access for
each user/purpose?

· *Data Accuracy: *What steps should be taken to improve data *accuracy*?

· *Data Elements: *What data should be collected, stored, and disclosed?

· *Privacy: *What steps are needed to protect data and privacy?

· *Coexistence: *What steps should be taken to enable next-generation RDS
coexistence with

and replacement of the legacy WHOIS system?

· *Compliance: *What steps are needed to enforce these policies?

· *System Model: *What system requirements must be satisfied by any
next-generation RDS

implementation?

· *Cost: *What costs will be incurred and how must they be covered?

· *Benefits: *What benefits will be achieved and how will they be measured?

· *Risks: *What risks do stakeholders face and how will they be reconciled?

On 8 November, 2012, the ICANN Board passed a resolution launching the
Expert Working Group on

gTLD Registration Directory Services (EWG) to help redefine the purpose of
gTLD registration data

and consider how to safeguard the data, and to propose a model for gTLD
registration directory

services (RDS) to address *accuracy*, privacy, and access issues.

·      *What are the fundamental requirements for gTLD registration data?*

When addressing this question, the PDP WG should consider, at a minimum,
users and

purposes and associated access, *accuracy*, data element, and privacy
requirements.


There are also some nice charts on pages 3-4 of the Charter (pp. 69-70 of
the Issue Report), which make the same point with greater detail.

Accuracy is absolutely a problem we need to address and resolve.  Knowing
where data came from but not knowing whether (to a fairly high degree of
likelihood) that the data is accurate is not data management; it's just
hoarding, but keeping the receipts.

Greg


*Greg Shatan *C: 917-816-6428
S: gsshatan
gregshatanipc at gmail.com


On Mon, May 8, 2017 at 5:08 AM, Andrew Sullivan <ajs at anvilwalrusden.com>
wrote:

> Hi,
>
> On Sun, May 07, 2017 at 01:31:14PM -0400, Sam Lanfranco wrote:
> > solutions. The key is that it is sourced in such a way that it is
> > recognized as Data of Record.
>
> I think that we mostly agree, but may be quibbling about "source".
> What I think is that the DoR is just what it says it is: the data that
> is recorded as having come from the original source of that data.
> This tells us nothing about whether the original source lied.
>
> That any given datum is in fact part of the DoR could be demontrated
> in different ways, according to the technology in question.[1]
>
> > Once there is agreement on what should be the Data of Record (the DoR
> > fields) for (say) Thin Data, with (say) unconstrained access, there is
> > then the question of which access window(s) [locations (SoR) or
> > processes (blockchain)] provide DoR.
>
> We agree about this, yes.
>
> > As for "can be sure the data is
> > correct", that is the validity issue and separate from the Data of
> > Record and Sources of Record issues.
>
> What _I_ at least meant in any locution like that was not "accurate
> data" but "canonically correct".  That is, when you get the data out
> of the system, how can you be sure that you have the DoR?  In whois,
> the answer is, "You can't".  In RDAP, the answer is, "Did you use
> HTTPS and follow the referrals in the answers you got?"  In some other
> possible future system, the answer might be, "Did you check the
> cryptographic signatures over the data elements you received, and do
> those signatures validate?"  We completely agree that the question of
> whether the data in the system is an accurate portrayal of the world
> is a different question, and probably outside the scope of our task.
>
> Best regards,
>
> A
>
> [1] Historically, we made the demonstration by source repository: we
> asked the registry for data for which the registry had to be the
> source, owing to the registry's position in the system.  So, whether a
> name was registered, the identity of the entity whence came the
> registration (the registrar), the name servers if any associated,
> certain dates, and the status of the domain came from the registry.
> All other data came from the registrar, which was the source for other
> such data.  This was the "thin whois" model.  Unfortunately,
> NICNAME/WHOIS predated the registry/registrar model, and the graft
> onto whois was not too successful, so people decided to use a "thick
> registry" model.  In this model, the DoR is nominally moved to the
> registry, even though registrars may maintain a private copy of
> registrant data that is not necessarily linked to the DoR.  Any
> database geek will tell you that this is a good way to ensure data
> synchronization problems, but it's what we have now.
>
> RDAP as initially designed allows either of these models to be
> followed, and it also allows authentication of the data source through
> the use of https.  With a little ingenuity, RDAP could be extended to
> provide cryptographic signatures over the data elements, thereby
> permitting widespread caching without the threat of data corruption
> (intentional or otherwise).  It's a live question whether the
> engineering effort necessary would be worth it, though I confess I'm
> pretty sceptical.
>
>
> --
> Andrew Sullivan
> ajs at anvilwalrusden.com
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170508/44ee55e9/attachment.html>