<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"><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"></p><div><p style="text-indent:0in"><span style="font-size:12.8px"><a 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 color="#000000" face="Arial, sans-serif"><span style="font-size:13.3333px"><br></span></font><a 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 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 href="mailto:ajs@anvilwalrusden.com">ajs@anvilwalrusden.com</a><br>
______________________________<wbr>_________________<br>
gnso-rds-pdp-wg mailing list<br>
<a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<a 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>