<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:x="urn:schemas-microsoft-com:office:excel" 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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
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;}
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;}
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;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal-compose;
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:754783929;
mso-list-template-ids:-1219958722;}
@list l1
{mso-list-id:1852065836;
mso-list-type:hybrid;
mso-list-template-ids:167920412 67698703 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1: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 l1: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 l1: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 l1: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 l1: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 l1: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 l1: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 l1: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 lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><a name="_MailEndCompose">Thanks, Mike. A few notes to contribute as people consider “authoritative”:<o:p></o:p></a></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">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></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">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></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">So the current situation seems to be pretty simple, and is on the path to getting even simpler:
<o:p></o:p></span></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoNormal" style="margin-left:0in;mso-list:l1 level1 lfo3"><span style="mso-bookmark:_MailEndCompose">If the registry is thick, the registry is authoritative for all data we see in WHOIS today.<o:p></o:p></span></li><li class="MsoNormal" style="margin-left:0in;mso-list:l1 level1 lfo3"><span style="mso-bookmark:_MailEndCompose">If the registry is thin, the registry is authoritative for the thin data, and the contact data held by the registrar is authoritative. The remaining
thin registries will go thick in a couple of years, which makes things simpler.<o:p></o:p></span></li></ol>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">However, the RDP WG could create complications. For example, in order to protect the personal data of natural persons, the WG could approve a model in which registrars hold back contact data from
registries. That would effectively nullify the Thick WHOIS PDP…<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">All best,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">--Greg<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose">(P.S.: the UDRP Rules say that the contact data in the “Registrar’s WHOIS” must be relied upon for proceedings (i.e. the registrar is authoritative for contact data). That was written in 1999,
back before thick gTLD registries even existed. I believe that language should eventually be changed to meet evolving reality.))<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><o:p> </o:p></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>From:</b> gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org]
<b>On Behalf Of </b>Michael D. Palage<br>
<b>Sent:</b> Tuesday, April 4, 2017 1:24 PM<br>
<b>To:</b> 'RDS PDP WG' <gnso-rds-pdp-wg@icann.org><br>
<b>Subject:</b> [gnso-rds-pdp-wg] Proposed Definition/Background for Authoritative<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hello All,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">While I will work with the smaller group on a more concise definition of “Authoritative,” I wanted to provide these broad brush strokes on my perspective of this concept to the entire group.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Authoritative Data used in the context of the RDS WG is intend to define the concept of which data shall deemed to be controlling(authoritative) when confronted with data elements that are NOT identical (i.e. are inconsistent).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Currently there are multiple parties in the domain name eco system that possess (disseminate/make available) Whois data records associated with a domain name, some under ICANN contract (registries and registrars) and those that are not
(i.e. third party proxy agents, historical whois aggregators, etc.)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The “authoritativeness” of all Whois data elements are NOT necessary treated equal. The Registry is absolutely Authoritative in connection with the name servers published in the zone file. However, inconsistencies in other data elements
can and do happen, i.e. Registrars that update domain name Whois locally without timely updating the information at the Registry, historical thin/thick registries; Registrants that provide false and inaccurate information; Registrant data that unintentional
because outdate/inaccurate, etc.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Standard Registry Agreements have legal provisions in their RRA which dictate which data will control (i.e. be authoritative). See for example the following provision from VeriSign’s RRA: “<strong><span style="font-family:"Calibri",sans-serif">2.11.
Time.</span></strong> Registrar agrees that in the event of any dispute concerning the time of the entry of a domain name registration into the registry database, the time shown in the Verisign records shall control.”<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In making a legal determination as to the “authoritativeness” of Whois data elements there are some rebuttable presumptions. Per the standard RRA, there should be a presumption of authoritativeness of the data in the Registry database.
This presumption of authoritativeness can be challenged using data residing in the Registrar database in certain circumstances.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Regarding third party aggregated historical Whois data elements, there is a widely accepted presumption within the industry that this data is historically accurate in the absent of any conflicting Registry/Registrar authoritative data.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So for those members looking for a nice neat definition of “authoritative” sorry for this rambling
<em><span style="font-family:"Calibri",sans-serif;font-style:normal">soliloquy</span></em><em><span style="font-family:"Calibri",sans-serif">.
</span></em> <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I would also encourage WG members to read this currently pending ICANN reconsideration request dealing with the “authoritativeness” of whois data elements, see
<a href="https://www.icann.org/resources/pages/reconsideration-17-1-smith-request-2017-03-16-en">
https://www.icann.org/resources/pages/reconsideration-17-1-smith-request-2017-03-16-en</a>
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Michael<o:p></o:p></p>
</div>
</body>
</html>