<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>For this reason I feel that the term "authoritative" should indicate source. Accuracy is an issue for the authoritative source to deal with (and yes we should also but at the end as suggested)<br><br>Sent from my iPad</div><div><br>On 8 May 2017, at 19:06, Volker Greimann <<a href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>> wrote:<br><br></div><blockquote type="cite"><div>
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
<p>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.</p>
<p><br>
</p>
<p>Best,</p>
<p>Volker<br>
</p>
<br>
<div class="moz-cite-prefix">Am 08.05.2017 um 17:58 schrieb Greg
Shatan:<br>
</div>
<blockquote cite="mid:CA+aOHUQrhXBJLAu=0D-vLhnOcaPPvxDLJpw2b9B2CwLA2iL3gw@mail.gmail.com" type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-family:verdana,sans-serif">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 "<span style="font-size:12.8px;font-family:arial,sans-serif">probably
outside the scope of our task."</span></div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif">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):</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"> <b style="font-family:arial,sans-serif"><span style="font-family:"calibri,bold",sans-serif">As
part of its Phase 1 deliberations, </span></b><span style="font-family:arial,sans-serif">the PDP WG
should work to reach consensus recommendations</span></div>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span></span></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal">by
considering, <b><i><span style="font-family:"calibri,bolditalic",sans-serif">at
a minimum</span></i></b>, the following complex and
inter-related questions:<span></span></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:symbol">· </span><b><span style="font-family:"calibri,bold",sans-serif">Users/Purposes:
</span></b>Who should have access to gTLD registration data
and why?<span></span></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:symbol">· </span><b><span style="font-family:"calibri,bold",sans-serif">Gated
Access: </span></b>What steps should be taken to control
data access for each
user/purpose?<span></span></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:symbol">· </span><b><span style="font-family:"calibri,bold",sans-serif;color:red">Data
Accuracy: </span></b><span style="color:red">What steps
should be taken to improve data <b>accuracy</b>?<span></span></span></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:symbol">· </span><b><span style="font-family:"calibri,bold",sans-serif">Data
Elements: </span></b>What data should be collected,
stored, and disclosed?<span></span></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:symbol">· </span><b><span style="font-family:"calibri,bold",sans-serif">Privacy:
</span></b>What steps are needed to protect data and
privacy?<span></span></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:symbol">· </span><b><span style="font-family:"calibri,bold",sans-serif">Coexistence:
</span></b>What steps should be taken to enable
next-generation RDS coexistence
with<span></span></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal">and
replacement of the legacy WHOIS system?<span></span></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:symbol">· </span><b><span style="font-family:"calibri,bold",sans-serif">Compliance:
</span></b>What steps are needed to enforce these policies?<span></span></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:symbol">· </span><b><span style="font-family:"calibri,bold",sans-serif">System
Model: </span></b>What system requirements must be
satisfied by any next-generation RDS<span></span></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal">implementation?<span></span></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-family:symbol">· </span><b><span style="font-family:"calibri,bold",sans-serif">Cost:
</span></b>What costs
will be incurred and how must they be covered?<span></span></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="font-size:12pt;font-family:symbol">· </span><b><span style="font-family:"calibri,bold",sans-serif">Benefits:
</span></b>What benefits will be achieved and how
will they be measured?<span></span></p>
<div style="border-top:none;border-right:none;border-left:none;border-bottom:3pt
dotted windowtext;padding:0in 0in 1pt">
<p class="MsoNormal" style="border:none;padding:0in"><span style="font-size:12pt;line-height:115%;font-family:symbol">·
</span><b><span style="font-family:"calibri,bold",sans-serif">Risks:
</span></b>What risks do stakeholders face and how
will they be reconciled?<span></span></p>
</div>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="color:black">On
8 November, 2012, the ICANN Board passed a </span><span style="color:blue">resolution
</span><span style="color:black">launching the Expert Working
Group on<span></span></span></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="color:black">gTLD
Registration Directory Services (EWG) to help redefine the
purpose of gTLD
registration data<span></span></span></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><span style="color:black">and
consider how to safeguard the data, and to propose a model
for gTLD
registration directory<span></span></span></p>
<div style="border-top:none;border-right:none;border-left:none;border-bottom:3pt
dotted windowtext;padding:0in 0in 1pt">
<p class="MsoNormal" style="border:none;padding:0in"><span style="color:black">services
(RDS) to address </span><b><span style="color:red">accuracy</span></b><span style="color:black">,
privacy, and access issues.<span></span></span></p>
</div>
<p class="gmail-MsoListParagraph" style="margin:0in 0in 0.0001pt
13.5pt;line-height:normal"><span style="font-family:symbol">·<span style="font-variant-numeric:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:"times
new roman"">
</span></span><b><span style="font-family:"calibri,bold",sans-serif">What
are the fundamental requirements for
gTLD registration data?<span></span></span></b></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;text-indent:13.5pt;line-height:normal">When
addressing this question, the PDP WG should consider, at a
minimum, users and<span></span></p>
<div style="border-top:none;border-right:none;border-left:none;border-bottom:3pt
dotted windowtext;padding:0in 0in 1pt">
<p class="MsoNormal" style="text-indent:13.5pt;border:none;padding:0in">purposes
and associated access, <b><span style="color:red">accuracy</span></b>,
data element, and privacy requirements.<span></span></p>
</div>
<p class="MsoNormal"><span> </span></p>
<div class="gmail_default" style="font-family:verdana,sans-serif">
<div class="gmail_default">
<div class="gmail_default">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.</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">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.</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">Greg </div>
</div>
</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>
<p style="text-indent:0in"><span style="font-size:12.8px"><a moz-do-not-send="true" name="UNIQUE_ID_SafeHtmlFilter_UNIQUE_ID_SafeHtmlFilter__GoBack"></a></span><b style="font-size:12.8px"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#002e62">Greg
Shatan<br>
</span></b><span style="font-size:10pt;font-family:Arial,sans-serif;color:black">C:
917-816-6428<br>
S: gsshatan</span><font face="Arial, sans-serif" color="#000000"><span style="font-size:13.3333px"><br>
</span></font><a moz-do-not-send="true" href="mailto:gregshatanipc@gmail.com" style="font-family:Arial,sans-serif;font-size:10pt;text-indent:0in" target="_blank"><span style="color:#1155cc">gregshatanipc@gmail.com</span></a></p>
<p style="font-size:12.8px;text-indent:0in"><span style="font-size:10.0pt;font-family:"Arial","sans-serif""></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">On Mon, May 8, 2017 at 5:08 AM, Andrew
Sullivan <span dir="ltr"><<a moz-do-not-send="true" href="mailto:ajs@anvilwalrusden.com" target="_blank">ajs@anvilwalrusden.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
On Sun, May 07, 2017 at 01:31:14PM -0400, Sam Lanfranco
wrote:<br>
> solutions. The key is that it is sourced in such a
way that it is<br>
> recognized as Data of Record.<br>
<br>
</span>I think that we mostly agree, but may be quibbling
about "source".<br>
What I think is that the DoR is just what it says it is: the
data that<br>
is recorded as having come from the original source of that
data.<br>
This tells us nothing about whether the original source
lied.<br>
<br>
That any given datum is in fact part of the DoR could be
demontrated<br>
in different ways, according to the technology in
question.[1]<br>
<span class=""><br>
> Once there is agreement on what should be the Data of
Record (the DoR<br>
> fields) for (say) Thin Data, with (say) unconstrained
access, there is<br>
> then the question of which access window(s)
[locations (SoR) or<br>
> processes (blockchain)] provide DoR.<br>
<br>
</span>We agree about this, yes.<br>
<span class=""><br>
> As for "can be sure the data is<br>
> correct", that is the validity issue and separate
from the Data of<br>
> Record and Sources of Record issues.<br>
<br>
</span>What _I_ at least meant in any locution like that was
not "accurate<br>
data" but "canonically correct". That is, when you get the
data out<br>
of the system, how can you be sure that you have the DoR?
In whois,<br>
the answer is, "You can't". In RDAP, the answer is, "Did
you use<br>
HTTPS and follow the referrals in the answers you got?" In
some other<br>
possible future system, the answer might be, "Did you check
the<br>
cryptographic signatures over the data elements you
received, and do<br>
those signatures validate?" We completely agree that the
question of<br>
whether the data in the system is an accurate portrayal of
the world<br>
is a different question, and probably outside the scope of
our task.<br>
<br>
Best regards,<br>
<br>
A<br>
<br>
[1] Historically, we made the demonstration by source
repository: we<br>
asked the registry for data for which the registry had to be
the<br>
source, owing to the registry's position in the system. So,
whether a<br>
name was registered, the identity of the entity whence came
the<br>
registration (the registrar), the name servers if any
associated,<br>
certain dates, and the status of the domain came from the
registry.<br>
All other data came from the registrar, which was the source
for other<br>
such data. This was the "thin whois" model. Unfortunately,<br>
NICNAME/WHOIS predated the registry/registrar model, and the
graft<br>
onto whois was not too successful, so people decided to use
a "thick<br>
registry" model. In this model, the DoR is nominally moved
to the<br>
registry, even though registrars may maintain a private copy
of<br>
registrant data that is not necessarily linked to the DoR.
Any<br>
database geek will tell you that this is a good way to
ensure data<br>
synchronization problems, but it's what we have now.<br>
<br>
RDAP as initially designed allows either of these models to
be<br>
followed, and it also allows authentication of the data
source through<br>
the use of https. With a little ingenuity, RDAP could be
extended to<br>
provide cryptographic signatures over the data elements,
thereby<br>
permitting widespread caching without the threat of data
corruption<br>
(intentional or otherwise). It's a live question whether
the<br>
engineering effort necessary would be worth it, though I
confess I'm<br>
pretty sceptical.<br>
<div class="HOEnZb">
<div class="h5"><br>
<br>
--<br>
Andrew Sullivan<br>
<a moz-do-not-send="true" href="mailto:ajs@anvilwalrusden.com">ajs@anvilwalrusden.com</a><br>
______________________________<wbr>_________________<br>
gnso-rds-pdp-wg mailing list<br>
<a moz-do-not-send="true" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<a moz-do-not-send="true" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gnso-rds-pdp-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
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: <a class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>
Web: <a class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</a> / <a class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net">www.RRPproxy.net</a>
<a class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a class="moz-txt-link-abbreviated" href="http://www.BrandShelter.com">www.BrandShelter.com</a>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
<a class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems">www.twitter.com/key_systems</a>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
<a class="moz-txt-link-abbreviated" href="http://www.keydrive.lu">www.keydrive.lu</a>
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: <a class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>
Web: <a class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</a> / <a class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net">www.RRPproxy.net</a>
<a class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a class="moz-txt-link-abbreviated" href="http://www.BrandShelter.com">www.BrandShelter.com</a>
Follow us on Twitter or join our fan community on Facebook and stay updated:
<a class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems">www.twitter.com/key_systems</a>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
<a class="moz-txt-link-abbreviated" href="http://www.keydrive.lu">www.keydrive.lu</a>
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.
</pre>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>gnso-rds-pdp-wg mailing list</span><br><span><a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a></span><br><span><a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></span></div></blockquote></body></html>