[gnso-rds-pdp-wg] authoritative

Mon May 8 17:06:28 UTC 2017

All things considered, the accuracy of the data to provided to the RDS 
will probably be one of the last points of our agenda. Only after 
determining how the new system should look, both from a technical 
framework perspective as well as from a legal, structural perspective 
can we even begin to figure out how this new system should tackle data 
accuracy. It would be my estimation that if a non-public RDS that 
protects the privacy of all data subjects subject to having their data 
entered into it were the result of this WG, as many of us hope, then 
that in and of itself would already be very helpful with regard to the 
issue of data accuracy, just as experience shows that data protected by 
privacy services has an overall better accuracy that public whois data 
in general.

Best,

Volker

Am 08.05.2017 um 17:58 schrieb 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 <mailto:gregshatanipc at gmail.com>
>
>
> On Mon, May 8, 2017 at 5:08 AM, Andrew Sullivan 
> <ajs at anvilwalrusden.com <mailto: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 <mailto:ajs at anvilwalrusden.com>
>     _______________________________________________
>     gnso-rds-pdp-wg mailing list
>     gnso-rds-pdp-wg at icann.org <mailto:gnso-rds-pdp-wg at icann.org>
>     https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>     <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
>
>
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

-- 
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.

Mit freundlichen Grüßen,

Volker A. Greimann
- Rechtsabteilung -

Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann at key-systems.net

Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com

Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems
www.twitter.com/key_systems

Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534

Member of the KEYDRIVE GROUP
www.keydrive.lu

Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.

--------------------------------------------

Should you have any further questions, please do not hesitate to contact us.

Best regards,

Volker A. Greimann
- legal department -

Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann at key-systems.net

Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com

Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems
www.twitter.com/key_systems

CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534

Member of the KEYDRIVE GROUP
www.keydrive.lu

This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170508/b6f2a097/attachment-0001.html>