[gnso-rds-pdp-wg] authoritative

[Andrew Sullivan]

Apologies, I meant "outside the scope of this task" i.e. the current discussion and determining the term we're using.  It's in the charter for sure. 

A

-- 
Andrew Sullivan 
Please excuse my clumbsy thums. 

> On May 8, 2017, at 11:58, Greg Shatan <gregshatanipc at gmail.com> wrote:
> 
> 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/fd819318/attachment-0001.html>