<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:"Lucida Grande";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle25
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle26
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#993366;}
span.EmailStyle27
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:275137229;
mso-list-template-ids:-143099444;}
@list l1
{mso-list-id:667564438;
mso-list-type:hybrid;
mso-list-template-ids:1408894184 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2
{mso-list-id:671419306;
mso-list-template-ids:966700692;}
@list l3
{mso-list-id:730228335;
mso-list-type:hybrid;
mso-list-template-ids:1084114470 -257669616 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l3:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;}
@list l3:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.25in;
text-indent:-.25in;}
@list l3:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:1.75in;
text-indent:-9.0pt;}
@list l3:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.25in;
text-indent:-.25in;}
@list l3:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.75in;
text-indent:-.25in;}
@list l3:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:3.25in;
text-indent:-9.0pt;}
@list l3:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.75in;
text-indent:-.25in;}
@list l3:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:4.25in;
text-indent:-.25in;}
@list l3:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:4.75in;
text-indent:-9.0pt;}
@list l4
{mso-list-id:1829862033;
mso-list-template-ids:-715196192;}
@list l5
{mso-list-id:1852065836;
mso-list-type:hybrid;
mso-list-template-ids:167920412 67698703 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l5:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l5:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l5:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l5:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l5:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l5:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l5:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l5:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><a name="_MailEndCompose"><span style="color:windowtext">Dear Scott:<o:p></o:p></span></a></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span style="color:windowtext"><o:p> </o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span style="color:windowtext">My point was: where was the EWG’s RDDS going to get data? From the registries, not directly from registrars.<o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span style="color:windowtext"><o:p> </o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span style="color:windowtext">The “Registrar Registration Expiration Date” field is mention is relevant to just the three thin gTLD registries (.COM, .NET, .JOBS) -- the thin model that’s going
away (and has been for years). In the other 1,200+ gTLD registries, the expiration date is not provisioned by registrars, it’s generated by the registries (as you know).<o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span style="color:windowtext"><o:p> </o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span style="color:windowtext">So anyway, you’re advocating that in the future, contact data should remain at registrars and never go to registries, and that ICANN should send all gTLDs to the
thin model? After the community decided to go to an all-thick model in 2013, and Verisign just recently agreed to the thick implementation plan for .COM and .NET?
<o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span style="color:windowtext"><o:p> </o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span style="color:windowtext">To better understand, I would like your views on these questions:<o:p></o:p></span></span></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoNormal" style="color:windowtext;margin-left:.25in;mso-list:l3 level1 lfo3">
<span style="mso-bookmark:_MailEndCompose">How the thin registry model is required under privacy law.
<o:p></o:p></span></li><li class="MsoNormal" style="color:windowtext;margin-left:.25in;mso-list:l3 level1 lfo3">
<span style="mso-bookmark:_MailEndCompose">An issue is personal data crossing from (being collected from) one jurisdiction to another. Under the evolving privacy laws you are concerned about, won’t a registrar sometimes be barred from accepting domain registrations
from registrants outside its jurisdiction? For example, how could GoDaddy, a U.S. registrar, accept registrations (and the accompanying contact data) from registrants in Europe? Could GoDaddy serve that contact data via an RDS under any circumstances?
<o:p></o:p></span></li><li class="MsoNormal" style="color:windowtext;margin-left:.25in;mso-list:l3 level1 lfo3">
<span style="mso-bookmark:_MailEndCompose">What has changed in privacy law recently that overrides the considerations of privacy law that the EWG and the Thick PDP WG made?
<o:p></o:p></span></li></ol>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span style="color:windowtext"><o:p> </o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span style="color:windowtext">All best,<o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span style="color:windowtext">--Greg<o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span style="font-size:10.0pt;color:windowtext"><o:p> </o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span style="color:windowtext"><o:p> </o:p></span></span></p>
<span style="mso-bookmark:_MailEndCompose"></span>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="color:windowtext">From:</span></b><span style="color:windowtext"> Hollenbeck, Scott [mailto:shollenbeck@verisign.com]
<br>
<b>Sent:</b> Wednesday, April 5, 2017 12:37 PM<br>
<b>To:</b> Greg Aaron <gca@icginc.com>; 'stephanie.perrin@mail.utoronto.ca' <stephanie.perrin@mail.utoronto.ca>; 'gnso-rds-pdp-wg@icann.org' <gnso-rds-pdp-wg@icann.org><br>
<b>Subject:</b> RE: [gnso-rds-pdp-wg] Proposed Definition/Background for Authoritative<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#993366">Greg,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#993366"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#993366">I was a member of the EWG. It’s important to recall the context of the recommendations that you refer to below. The EWG recommended development of a single, centralized RDDS, *<b>not</b>* multiple thick registries.
In that environment, there is only one source for public access, and it is, by definition, the only possible source. It’s described as authoritative because there are no other options. Note that this recommendation was largely rejected by the community.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#993366"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#993366">The one example I provided was just that – one example, and it’s not the one you expanded on in your “PS” below. I wasn’t referring to the expiration date derived from the specified registration period. As the
author of EPP, I know how that works very well. I was referring to the “Registrar Registration Expiration Date” as described in the CL&D policy:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#993366"><o:p> </o:p></span></p>
<p class="MsoNormal"><a href="https://www.icann.org/resources/pages/rdds-labeling-policy-2017-02-01-en">https://www.icann.org/resources/pages/rdds-labeling-policy-2017-02-01-en</a><span style="color:#993366"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#993366"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#993366">This is a data element produced by the registrar and pushed to the registry solely for inclusion in a registry’s RDDS. There are multiple mainstream examples where the registrar is the original creator or collector
and the registry is just the last link in the chain of custody:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#993366"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#993366">Registrant contact information<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#993366">Admin contact information<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#993366">Billing contact information<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#993366">Technical contact information<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#993366">Registrar reseller information<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#993366"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#993366">Is my view of “authoritative” counter to the direction of the thick WHOIS policy? Yes, it is. It recognizes that the data privacy landscape is changing and thick registries might not be viable in the future due
to evolving data protection laws.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#993366"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:#993366">Scott<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="color:#993366"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="color:windowtext">From:</span></b><span style="color:windowtext">
</span><a href="mailto:gnso-rds-pdp-wg-bounces@icann.org">gnso-rds-pdp-wg-bounces@icann.org</a><span style="color:windowtext"> [</span><a href="mailto:gnso-rds-pdp-wg-bounces@icann.org">mailto:gnso-rds-pdp-wg-bounces@icann.org</a><span style="color:windowtext">]
<b>On Behalf Of </b>Greg Aaron<br>
<b>Sent:</b> Wednesday, April 05, 2017 11:41 AM<br>
<b>To:</b> Stephanie Perrin <</span><a href="mailto:stephanie.perrin@mail.utoronto.ca">stephanie.perrin@mail.utoronto.ca</a><span style="color:windowtext">>;
</span><a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><span style="color:windowtext"><br>
<b>Subject:</b> [EXTERNAL] Re: [gnso-rds-pdp-wg] Proposed Definition/Background for Authoritative<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:windowtext">There are two different definitions of “authoritative” being used here. One is “where does the data come from,” i.e. what is the original source. Stephanie and Scott are using this first definition. The
second definition is “what is the data of record, which should be relied upon.” I am using that second definition. I think the first concept is important to understand, but it cannot be used as the standard for a variety of legal, technical, and practical
reasons. The history at ICANN, and recent policy-making, has been toward relying on thick registry data as the data of record, to be relied upon. My view was used by both the EWG and the Thick WHOIS PDP.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext">Stephanie, I think you’re wrong about what the EWG said. It did not use your definition, it used mine. The EWG said: “Requestors must be able to obtain authoritative data from the RDS in real-time when needed.”
And the EWG said: “the RDS is the authoritative data source and provides authoritative access.” The EWG did not recommend that people be able to obtain certain kinds of data directly from registrars via RDS. Instead, the EWG said that RDS was to provide
data from (thick) registries. The data in the registries is authoritative, and the RDS is the authoritative way to get that data held in the registries.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The Thick WHOIS PDP WG recently looked at the issue of authoritativeness, and our WG should consider it carefully. That PDP WG used my definition, not Scott’s. That PDP WG said that a thick registry is the authoritative repository of
all data currently displayed in WHOIS. Quote below, with my notes in square brackets:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">“Here is the working definition used by the WG while analysing this issue: ‘Authoritative, with respect to provision of Whois services, shall be interpreted as to signify the single database within a hierarchical database structure holding
the data that is assumed to be the final authority regarding the question of which record shall be considered accurate and reliable in case of conflicting records; administered by a single administrative (agent) and consisting of data provided by the registrants
of record through their registrars.’ A proposed shorter version is ‘the data set to be relied upon in case of doubt’. [In other words, the REGISTRY is the ultimate authority, not registrars.]<o:p></o:p></p>
<p class="MsoNormal">Authoritativeness in a Thin Whois Environment<o:p></o:p></p>
<p class="MsoNormal">Since the registrar alone holds most Whois data, its data is necessarily authoritative as to those data elements (e.g., name of registrant). For that data held by both registrar and registry (e.g., name of<o:p></o:p></p>
<p class="MsoNormal">registrar), it appears that registry data is generally treated as authoritative, but the WG is not aware of any official ICANN policy statement on this. The WG observes that in the case of the Uniform Dispute Resolution Policy (UDRP), UDRP
Providers treat the registrar Whois information as authoritative, which may be the result of the UDRP having been adopted prior to the emergence of thick gTLD registries.<o:p></o:p></p>
<p class="MsoNormal">Authoritativeness in a Thick Whois Environment<o:p></o:p></p>
<p class="MsoNormal">Most comments that addressed this question stated that registry data is considered authoritative in the thick environment. Only one stated that the registrar data was authoritative. Again, the WG is<o:p></o:p></p>
<p class="MsoNormal">not aware of any official ICANN policy statement on this question. The WG notes that the registrar remains responsible for the accuracy of the data under either the thick or thin model, as the relationship with the registrant remains with
the registrar. ..<i>the WG assumes that any data collected by the registrar becomes authoritative only after it is incorporated in the registry database</i>.” [emphasis added]<o:p></o:p></p>
<p class="MsoNormal"><span style="color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext">If anyone wants the registrars to remain the source of record for any data available throrugh an RDS, then:<o:p></o:p></span></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoNormal" style="color:windowtext;margin-left:0in;mso-list:l1 level1 lfo6">
That will sink the entire purpose of the thick registry effort,<o:p></o:p></li><li class="MsoNormal" style="color:windowtext;margin-left:0in;mso-list:l1 level1 lfo6">
It will make solving domain disputes harder than they are now, and<o:p></o:p></li><li class="MsoNormal" style="color:windowtext;margin-left:0in;mso-list:l1 level1 lfo6">
Registrars should be contractually required to serve RDS indefinitely. That’s contrary to the thick policy, a goal of which was to get registrars out of the business of serving their own WHOIS (or RDAP, or whatever).
<o:p></o:p></li></ol>
<p class="MsoNormal"><span style="color:windowtext">All of which would be completely unnecessary and wasteful.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext">All best,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext">--Greg<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext">P.S.: Scott is using a corner case to support his argument.
</span>In 99.999% of cases, registrars do not ”push expiration dates to registries”. Registrars send in EPP Create commands and indicate a registration term in years. The registry time-stamps the create and expiration date based on the time the Create command
is received. The registrar does not hold those dates authoritatively – the registry does. The only exception I know of is Verisign’s obscure “ConsoliDate” product, which is available in .COM and .NET and is used infrequently by a small number of corporata
cleints to add days to expiration dates. In any case, the Create date in a registry may not correspond to the date/time the registrant entered into the contract with the registrar. What really matters is the date recorded in the registry.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="color:windowtext">From:</span></b><span style="color:windowtext">
</span><a href="mailto:gnso-rds-pdp-wg-bounces@icann.org">gnso-rds-pdp-wg-bounces@icann.org</a><span style="color:windowtext"> [</span><a href="mailto:gnso-rds-pdp-wg-bounces@icann.org">mailto:gnso-rds-pdp-wg-bounces@icann.org</a><span style="color:windowtext">]
<b>On Behalf Of </b>Stephanie Perrin<br>
<b>Sent:</b> Wednesday, April 5, 2017 10:05 AM<br>
<b>To:</b> </span><a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><span style="color:windowtext"><br>
<b>Subject:</b> Re: [gnso-rds-pdp-wg] Proposed Definition/Background for Authoritative<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p><span style="font-size:13.5pt;font-family:"Lucida Grande",serif">+1</span><o:p></o:p></p>
<p><span style="font-size:13.5pt;font-family:"Lucida Grande",serif">It is not every day that I quote the EWG conclusions, as there are quite a few with which I disagree. In this case though, it does seem to me we discussed this exhaustively, and reached the
conclusion that the registrars were the authoritative source. From a data protection perspective, this is consistent. I believe it would be the common view that the entity closest to the individual on the data map would be the authority on the data, not
the entity further down the chain of control, and not the data controller (in this case ICANN). I realize I am mixing technical perspectives with legal perspectives here but I believe it is useful to flesh out how the matter is analyzed from each point of
view.</span><o:p></o:p></p>
<p><span style="font-size:13.5pt;font-family:"Lucida Grande",serif">cheers Stephanie P</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 2017-04-05 07:10, Hollenbeck, Scott via gnso-rds-pdp-wg wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><b>From:</b> <a href="mailto:gnso-rds-pdp-wg-bounces@icann.org">
gnso-rds-pdp-wg-bounces@icann.org</a> [<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org">mailto:gnso-rds-pdp-wg-bounces@icann.org</a>]
<b>On Behalf Of </b>Greg Aaron<br>
<b>Sent:</b> Tuesday, April 04, 2017 5:18 PM<br>
<b>To:</b> Michael D. Palage <a href="mailto:michael@palage.com"><michael@palage.com></a>; 'RDS PDP WG'
<a href="mailto:gnso-rds-pdp-wg@icann.org"><gnso-rds-pdp-wg@icann.org></a><br>
<b>Subject:</b> [EXTERNAL] Re: [gnso-rds-pdp-wg] Proposed Definition/Background for Authoritative<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Thanks, Mike. A few notes to contribute as people consider “authoritative”:<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Registries exist to be authoritative repositories of data; that’s what they are designed to do. (So, for example, two different people can’t register the same domain name, or so a domain won’t resolve to the wrong nameservers.) Domain
registries are generally considered authoritative for at least the thin data. (Domain, sponsoring registrar, dates, statuses, nameservers.) The registry creates or is the original recorder of record for most of those fields (domain, sponsoring registrar,
dates). And the registry is authoritative for status and nameserver data, using them to enable and control resolution, or to prevent certain actions from taking place in the registry (such as deletions, and registrar-to-registrar transfers).<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">The Thick WHOIS PDP decided that all gTLD registries should be thick. One reason was to ensure that there won’t be any more disagreements (discrepancies) between what the registrar says the data is and what the registry says it is (and
as seen via WHOIS or a successor system). Another reason was to hold contact data in one place reliably, so it could be served from one (authoritative) place; as a consequence registrar port 43 service will eventually go away. In other words, all registries
should become authoritative for all the data we see in WHOIS, if they are not already. That was the desired policy and operational outcome.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">So the current situation seems to be pretty simple, and is on the path to getting even simpler:
<o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoNormal" style="margin-left:0in;mso-list:l5 level1 lfo9">If the registry is thick, the registry is authoritative for all data we see in WHOIS today.<o:p></o:p></li></ol>
<p class="MsoNormal"><b><i><span style="color:#1F497D"> </span></i></b><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">I can’t agree with the conclusion that thick registries are authoritative for all the data they possess. Being the last holder in a chain of custody makes them a *<b>convenient</b>* source of access to certain
data elements, but they are not the original, authoritative* (able to be trusted as being accurate or true; reliable) source. An example:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">A registrar creates an agreement with a registrant. That agreement has an expiration date. The registrar pushes this expiration date to the registry for publication in an RDDS. The registry has no direct contact
or relationship with the registrant or the agreement between the registrant and the registrar.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">In this and similar indirect data collection situations, the registry is just the last holder in the chain of custody. The registrar is the original source of the data, and is thus a more accurate and reliable
source of information.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Scott</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:5.25pt"><span style="color:#1F497D">* I think it’s very important for us to agree on a definition of “authoritative”, and that doesn’t mean that we get to make one up. I’ve included mine (taken from the Oxford English
dictionary) here.</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>gnso-rds-pdp-wg mailing list<o:p></o:p></pre>
<pre><a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><o:p></o:p></pre>
<pre><a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
</div>
</div>
</body>
</html>