<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)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@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:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:"Poppins Light";}
@font-face
{font-family:"Poppins SemiBold";}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
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";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.spelle
{mso-style-name:spelle;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle24
{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:287048672;
mso-list-template-ids:-742868798;}
@list l0:level1
{mso-level-start-at:3;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1
{mso-list-id:508837823;
mso-list-template-ids:1673543186;}
@list l1:level1
{mso-level-start-at:6;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2
{mso-list-id:669452780;
mso-list-template-ids:-1896424500;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3
{mso-list-id:726413741;
mso-list-template-ids:-315620192;}
@list l4
{mso-list-id:1011370163;
mso-list-template-ids:2120113962;}
@list l4:level1
{mso-level-start-at:5;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5
{mso-list-id:1259101633;
mso-list-template-ids:-219893046;}
@list l5:level1
{mso-level-start-at:4;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6
{mso-list-id:1655182069;
mso-list-template-ids:-450073090;}
@list l6:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l6:level2
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l6:level3
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l6:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l6:level5
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l6:level6
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l6:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l6:level8
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l6:level9
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l7
{mso-list-id:1992781625;
mso-list-template-ids:1438577750;}
@list l7:level1
{mso-level-start-at:2;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
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=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hello Sophie,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>While I am not attempting to answer your previous question to Lori on her behalf, I thought I would like to provide the following data points that may help answer/clarify this issue for all parties in an asynchronous manner, thus saving previous plenary time for other matters. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>In EPDP Phase 1 which the RySG fully endorsed, in Recommend 1 under “ICANN Purposes for processing gTLD Registration Data” Paragraph 7 states in relevant part “Enabling validation to confirm that Registered Name Holder meets gTLD registration policy eligibility criteria voluntarily adopted by Registry Operator and that are described or referenced in the Registry Agreement for that gTLD.” FN4 [The EPDP Team’s approval of Purpose 7 does not prevent and should not be interpreted as preventing Registry Operators from voluntarily adopting gTLD registration policy eligibility criteria that are not described or referenced in their respective Registry Agreements.]<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Additionally, Paragraph 5 of Recommendation 1 in the EPDP Phase 1 report further states that an ICANN purpose is Handle contractual compliance monitoring requests and audit activities consistent with the terms of the Registry agreement.”<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>My recollection is that the RySG fully endorses the EPDP Phase 1 report which is now consensus policy, so I am a little confused over the RySG’s concern about “belief” and “rights” since this seems to have already been asked and answered. If the RySG’s position on Recommendation regarding purpose under Paragraphs 5 and 7 have change please let me know. While reviewing or proposing changes to the EPDP-identified purposes are outside the mandate of this scoping team per the instructions of Council, we have been instructed by Council to “identify this as an area of further work” if “the scoping team finds that further review of these purposes is necessary.”<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><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Sophie Hey <sophie.hey@comlaude.com> <br><b>Sent:</b> Friday, December 3, 2021 1:01 PM<br><b>To:</b> michael@palage.com; 'Lori Schulman' <lschulman@inta.org>; 'Sarah Wyld' <swyld@tucows.com>; gnso-accuracy-st@icann.org<br><b>Subject:</b> RE: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual Construct/ Definition<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='mso-margin-top-alt:12.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:0in'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'>Hi all, </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:12.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:0in'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'>Michael, Beth, Marc and myself would appreciate further clarity about what information you are hoping to get from this question so we can pass this along to the rest of the RySG. I’m not sure we understand why you are asking or its relevance to our current work.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:12.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:0in'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:12.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:0in'><i><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'>During the next RySG call could you seek clarification from the RySG on whether Registries believe they have a right under their Registry Agreement to verify the accuracy of data elements that they process as part of domain name registrations in their respective TLDs. Additionally, what steps if any does ICANN Compliance take in connection with Registry Audits regarding this verification.</span></i><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:12.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:0in'><i><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'> </span></i><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'>In speaking with our RySG colleagues, we received feedback that answering the first part of the question which is framed around “belief” and “rights” related to the Registry Agreement is not something the RySG is in a position to respond to and probably not appropriate for them to do so.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:12.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:0in'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'>The second part of the question you posed asks about steps ICANN Compliance takes and is probably more appropriately addressed to them.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:12.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:0in'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'>While the RySG is likely not in a position to respond globally, two of our members provided responses about their individual gTLDs that we do want to share.</span><o:p></o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:12.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:0in'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'>.BANK and .INSURANCE:</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:12.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:0in'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'>Having worked at ICANN in a registry capacity and now operating fTLD for the last decade, I fully appreciate that Registry Operators’ business models can vary greatly and thus I can only share <span class=spelle>fTLD’s</span> interpretations of our rights and responsibilities for operating .BANK and .INSURANCE.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:12.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:0in'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'>From a community-based gTLD perspective and because <span class=spelle>fTLD’s</span> Registry Agreements (RAs) for .BANK and .INSURANCE include unique elements, is that we absolutely have the right, and in fact have the obligation, based upon what is in our RAs, to verify the accuracy of domain name registration information. The aforementioned unique elements include Section 2.19, Obligations of Registry Operator to TLD Community; Specification 11, Public Interest Commitments; and Specification 12, Community Registration Policies. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:12.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:0in'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'>As a part of ICANN’s audit of Registries in 2016 and 2017, our TLDs were selected (.BANK in 2016, and .INSURANCE in 2017) and ICANN requested verification information for a random list of domain registrations in their Request For Information (RFI) and their RFI cited Section 2.19 and Specification 12 as the basis of their request. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:12.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:0in'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'>In 2017, when fTLD determined we could more effectively and efficiently implement the Registrant verification process rather than continuing to outsource it, we were directed to the RSEP process by ICANN GDD Staff, despite this process being neither a Service, nor the proposed offering of an Additional Service, as defined in the Registry Agreement. As a result of ICANN’s position, fTLD submitted an RSEP </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:12.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:0in'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'>(see request 2017039 accessible here:</span><a href="https://www.icann.org/resources/pages/rsep-2014-02-19-en"><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'> </span><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#1155CC'>https://www.icann.org/resources/pages/rsep-2014-02-19-en</span></a><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'>) detailing our migration from a static to a dynamic registration verification process. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:12.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:0in'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:12.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:0in'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'>Notwithstanding <span class=spelle>fTLD’s</span> obligations to perform Registrant Verification per our RAs with ICANN, the responsibility is further enumerated in our Registry Registrar Agreement (RRA):</span><o:p></o:p></p><ul style='margin-top:0in' type=disc><li class=MsoNormal style='color:black;margin-bottom:12.0pt;mso-list:l2 level1 lfo1;vertical-align:baseline'><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>3.3.2. Obligations of Registered Name Holder. Registrar shall require all Registered Name Holders to enter into a Registration Agreement with Registrar. In such Registration Agreement, Registrar shall require such Registered Name Holder to acknowledge and agree that the Registry Operator reserves the right to deny, cancel or transfer any Registered Name registration or transaction, or place any Registered Name (s) on registry lock, hold or similar status, as it deems necessary, in its unlimited and sole discretion: (<span class=spelle>i</span>) to comply with specifications adopted by any industry group generally recognized as authoritative with respect to the Internet (e.g., RFCs), (ii) to correct mistakes made by Registry Operator, Registry Service Provider, Registry Verification Agent, Registrar and/or any other contractually obligated vendors in connection with a domain name registration, or (iii) for the <span class=spelle>nonpayment</span> of Fees to Registry Operator.</span><o:p></o:p></li></ul><p class=MsoNormal style='mso-margin-top-alt:12.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:0in'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'> </span><o:p></o:p></p><ul style='margin-top:0in' type=disc><li class=MsoNormal style='color:black;margin-bottom:12.0pt;mso-list:l6 level1 lfo2;vertical-align:baseline'><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>3.9.8. Registrant shall take all necessary action(s) as directed by Registrar or Registry Operator in relation to compliance actions, directives, or instructions from ICANN, and/or as otherwise directed by Registry Operator in its sole discretion as being reasonably necessary for the provision of Registry Services and enforcing compliance with Registry Operator’s Operational and Security Requirements and Operations Pledge, including monitoring for compliance regarding the Registered Name.</span><o:p></o:p></li></ul><p class=MsoNormal style='mso-margin-top-alt:12.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:0in'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'>.PHARMACY</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:12.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:0in'><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'>The RA for .pharmacy obligates us to verify the accuracy of the information provided by prospective registrants. To clarify, this verification is part of the preliminary application and review process, not the actual domain name registration process.</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'> </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'> </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Poppins SemiBold";color:black'>Sophie Hey<br></span><span style='font-size:9.0pt;font-family:"Poppins Light";color:#950734'>Policy Advisor</span><span style='font-size:9.0pt;color:black'><br></span><span style='font-size:9.0pt;font-family:"Poppins SemiBold";color:black'>Com Laude<br></span><b><span style='font-size:9.0pt;font-family:"Poppins Light";color:#950734'>T</span></b><span style='font-size:9.0pt;font-family:"Poppins Light";color:black'> <a href="tel:+44%20(0)%2020%207421%208250">+44 (0) 20 7421 8250</a><br></span><b><span style='font-size:9.0pt;font-family:"Poppins Light";color:#950734'>Ext</span></b><span style='font-size:9.0pt;font-family:"Poppins Light";color:black'> 252</span><span style='font-size:9.0pt;font-family:"Poppins SemiBold";color:black'><br><br></span><a href="https://comlaude.com/"><span style='font-size:9.0pt;font-family:"Poppins SemiBold";text-decoration:none'><img border=0 width=60 height=82 style='width:.625in;height:.8541in' id="Picture_x0020_1" src="cid:image001.png@01D7EE8B.95C15820"></span></a><o:p></o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> GNSO-Accuracy-ST <<a href="mailto:gnso-accuracy-st-bounces@icann.org">gnso-accuracy-st-bounces@icann.org</a>> <b>On Behalf Of </b>Michael Palage<br><b>Sent:</b> 30 November 2021 19:58<br><b>To:</b> 'Lori Schulman' <<a href="mailto:lschulman@inta.org">lschulman@inta.org</a>>; 'Sarah Wyld' <<a href="mailto:swyld@tucows.com">swyld@tucows.com</a>>; <a href="mailto:gnso-accuracy-st@icann.org">gnso-accuracy-st@icann.org</a><br><b>Subject:</b> Re: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual Construct/ Definition<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>As someone that watched the video recording twice allow me to recount the events of Nov 4<sup>th</sup>.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>In advance of the call there had been two “definitions” (contractual construction / explanations) put forth for consideration. One by the Registrars and the one put forward by myself.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>In an effort to reconcile these two definitions, I opted to mark-up the Registrar’s “definition”. The first change was replacing the phrase “shall strictly” with “is.” Specifically I cited to Background Briefing Assignment #1 which stated in relevant part that:<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='color:black'>However, if the <b>complaint is about identity</b> (e.g., the registrant is not who they say they are), Contractual Compliance may ask the registrar to provide further information. (emphasis added).</span><o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>After the group acknowledged that this excerpt from the ICANN briefing document showed a larger remit than just syntactical and operational accuracy, the “shall strictly” phrase was redlined and replaced with ‘is.”. Alan Greenburg from ALAC tired to propose an alternative wording but the redline stayed as “is”.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>The next proposed redline was inspired largely by the following excerpt from the ICANN72 GAC communique which states in relevant part:<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>The GAC gives particular importance to the verification, validation and correction of all registration data by registrars, <b>and certain registries</b>, in line with their contractual obligations, and supports rigorous monitoring and enforcement of such<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>contractual obligations by ICANN. (emphasis added)<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>These changes again were made with no substantive opposition from the group.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>As I have stated previously these agreed upon changes where lost when the document was exited at the end of the call. I have consulted with ICANN Org and they are unaware of how these changes were lost. However, I believe the video clearly shows that the deletion was NOT an intentional act because no one spoke to the text being removed, it just disappeared. Please review the video for yourself, I have provided the time stamp to help make everyone’s review easier.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Now if the RySG and RsSG are going to maintain their objection to the previous redline “definition” and instead advocate for the RrSG “definition” we will address this topic AFTER the we conclude the questions to ICANN Org, but before we begin our GAP analysis.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>I do have a specific request for Marc, Beth and Sofie. During the next RySG call could you seek clarification from the RySG on whether Registries believe they have a right under their Registry Agreement to verify the accuracy of data elements that they process as part of domain name registrations in their respective TLDs. Additionally, what steps if any does ICANN Compliance take in connection with Registry Audits regarding this verification as I do believe it is relevant to our discussion here in this Working Group.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Listed below are a non-exhaustive list of Registry Operators that involve some level of accuracy /registrant vetting beyond just email and phone accuracy (syntactical and operational) as part of their registry operations:<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><ol style='margin-top:0in' start=1 type=1><li class=MsoListParagraph style='margin-top:0in;margin-bottom:0in;mso-list:l3 level1 lfo3'>From the original 2001 proof of concept round, .AERO was one of the first TLD that required the process of registrant data prior to being able to obtain a gTLD domain name registration. If you look at the current .AERO registration website you will see the following requirement:<o:p></o:p></li></ol><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>Obtain your .aero ID, prior to registration of your chosen domain name through a .aero authorised registrar, this unique validity process screens potential domain registrants thus ensuring the integrity and the exclusivity of the .aero domain.<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>See <a href="https://information.aero/registration">https://information.aero/registration</a> and <a href="https://information.aero/node/add/request-aero-id">https://information.aero/node/add/request-aero-id</a> <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><ol style='margin-top:0in' start=2 type=1><li class=MsoListParagraph style='margin-top:0in;margin-bottom:0in;mso-list:l7 level1 lfo4'>From the 2004 Sponsored round perhaps the best example was .XXX which made the following representations:<o:p></o:p></li></ol><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>5.0 PREVENTING ABUSIVE REGISTRATIONS<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>The Registry will authenticate members of the Sponsored Community, as part of the name registration process. As part of this process, the Registry will validate contact information for the Registrant, secure the Registrant’s affirmative consent to the Registry-Registrant Agreement, and issue unique Membership Credentials. The Membership Application Process must be completed before a domain name is permitted to resolve in the TLD.<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>See <a href="https://www.icmregistry.com/about/policies/launch/#general_aval">https://www.icmregistry.com/about/policies/launch/#general_aval</a><o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><ol style='margin-top:0in' start=3 type=1><li class=MsoListParagraph style='margin-top:0in;margin-bottom:0in;mso-list:l0 level1 lfo5'>fTLD submitted an approved RSEP to ICANN for the processing of Registrant information prior to registration. The name of this RSEP is Dynamic Registration Verification and is available here, see <a href="https://www.icann.org/en/system/files/files/rsep-2017039-bank-et-al-request-11dec17-en.pdf">https://www.icann.org/en/system/files/files/rsep-2017039-bank-et-al-request-11dec17-en.pdf</a> This webpage shows the information that fTLD collects from prospective registrants as part of their verification process, see <a href="https://www.register.bank/get-started/">https://www.register.bank/get-started/</a><o:p></o:p></li></ol><p class=MsoNormal> <o:p></o:p></p><ol style='margin-top:0in' start=4 type=1><li class=MsoListParagraph style='margin-top:0in;margin-bottom:0in;mso-list:l5 level1 lfo6'>NABP, the Registry Operator of .PHARMACY, has also vetted prospective registrants as part of its registration process, see <a href="https://nabp.pharmacy/programs/accreditations-inspections/dotpharmacy/#apply">https://nabp.pharmacy/programs/accreditations-inspections/dotpharmacy/#apply</a><o:p></o:p></li></ol><p class=MsoNormal> <o:p></o:p></p><ol style='margin-top:0in' start=5 type=1><li class=MsoListParagraph style='margin-top:0in;margin-bottom:0in;mso-list:l4 level1 lfo7'>In addition, every .BRAND Registry Operator has a requirement to limit registrations in that TLD to either the Brand owner or “Trademark Licensee” so this would be a further example of where a Registry Operator is processing data about a Registrant (e.g. Trademark Licensee) that may or may not appear in the Whois/RDDS output.<o:p></o:p></li></ol><p class=MsoListParagraph style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in'> <o:p></o:p></p><ol style='margin-top:0in' start=6 type=1><li class=MsoListParagraph style='margin-top:0in;margin-bottom:0in;mso-list:l1 level1 lfo8'>There are also numerous RSEPs filed by Registry Operators seeking “Registration Validation” which clearly go above just syntactical and operational validation, e.g. Chinese Real Name Verification.<o:p></o:p></li></ol><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>I hope this removes any ambiguity as to the events of Nov 4<sup>th</sup>. If, however, the RySG and RrSG maintain their objection we will revisit prior to our GAP analysis discussion as noted above.<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><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Lori Schulman <<a href="mailto:lschulman@inta.org">lschulman@inta.org</a>> <br><b>Sent:</b> Tuesday, November 30, 2021 1:06 PM<br><b>To:</b> Sarah Wyld <<a href="mailto:swyld@tucows.com">swyld@tucows.com</a>>; <a href="mailto:michael@palage.com">michael@palage.com</a>; <a href="mailto:gnso-accuracy-st@icann.org">gnso-accuracy-st@icann.org</a><br><b>Subject:</b> RE: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual Construct/ Definition<o:p></o:p></p></div></div><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Hi,<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>The changes were definitely tracked. I was under the impression that we agreed to those changes. If so, then they should be reinserted as a compromise that we can live with for the purposes of the scoping exercise. Any binding definitions will be negotiated by the eventual PDP. <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><div><p class=MsoNormal><span style='color:#1F497D'>With kind regards,</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'>Lori S. Schulman</span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'>Senior Director, Internet Policy</span><o:p></o:p></p><p class=MsoNormal><b><span style='color:#1F497D'>International Trademark Association (INTA)</span></b><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'><a href="tel:+1-202-704-0408">+1-202-704-0408</a>, Skype: LSSchulman</span><o:p></o:p></p><p class=MsoNormal><a href="mailto:lschulman@inta.org">lschulman@inta.org</a><span style='color:#1F497D'>, </span><a href="blocked::http://www.inta.org">www.inta.org</a><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></p></div><p class=MsoNormal> <o:p></o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> GNSO-Accuracy-ST <<a href="mailto:gnso-accuracy-st-bounces@icann.org">gnso-accuracy-st-bounces@icann.org</a>> <b>On Behalf Of </b>Sarah Wyld<br><b>Sent:</b> Monday, November 29, 2021 3:27 PM<br><b>To:</b> <a href="mailto:michael@palage.com">michael@palage.com</a>; <a href="mailto:gnso-accuracy-st@icann.org">gnso-accuracy-st@icann.org</a><br><b>Subject:</b> Re: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual Construct/ Definition<o:p></o:p></p></div></div><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal><span lang=EN-CA>Hi team,</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-CA> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-CA>I (of course) can’t speak for the registries or answer this question, but I do want to say, I’m glad the text in the screenshot was not updated. The definition in that section of the document should remain as we had proposed it back on Oct 29, and any changes should be tracked elsewhere. Maybe that’s why the changes were removed?<br><br>See you tomorrow, thanks! </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-CA> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-CA>Sarah</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-CA> </span><o:p></o:p></p><pre><span lang=EN-CA> </span><o:p></o:p></pre><pre><span lang=EN-CA> </span><o:p></o:p></pre><pre><span lang=EN-CA style='font-family:"Verdana",sans-serif'>-- </span><o:p></o:p></pre><pre><b><span lang=EN-CA style='font-family:"Verdana",sans-serif'>Sarah Wyld</span></b><span lang=EN-CA style='font-family:"Verdana",sans-serif'>, CIPP/E</span><o:p></o:p></pre><pre><span lang=EN-CA style='font-family:"Verdana",sans-serif'> </span><o:p></o:p></pre><pre><span lang=EN-CA style='font-family:"Verdana",sans-serif'>Policy & Privacy Manager</span><o:p></o:p></pre><pre><span lang=EN-CA style='font-family:"Verdana",sans-serif'>Pronouns: she/they</span><o:p></o:p></pre><pre><span lang=EN-CA style='font-family:"Verdana",sans-serif'> </span><o:p></o:p></pre><pre><a href="mailto:swyld@tucows.com"><span lang=EN-CA style='font-family:"Verdana",sans-serif'>swyld@tucows.com</span></a><span style='font-family:"Verdana",sans-serif'> </span><o:p></o:p></pre><pre><span lang=EN-CA style='font-family:"Verdana",sans-serif'>+1.416 535 0123 Ext. 1392</span><o:p></o:p></pre><p class=MsoNormal><span lang=EN-CA style='font-size:10.0pt;font-family:"Courier New"'> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-CA><img border=0 width=100 height=23 style='width:1.0416in;height:.243in' id="Picture_x0020_3" src="cid:image002.png@01D7EE8B.95C15820"></span><o:p></o:p></p><p class=MsoNormal><span lang=EN-CA> </span><o:p></o:p></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span lang=EN-CA>From: </span></b><a href="mailto:michael@palage.com"><span lang=EN-CA>Michael Palage</span></a><span lang=EN-CA><br><b>Sent: </b>November 26, 2021 12:02 PM<br><b>To: </b></span><a href="mailto:gnso-accuracy-st@icann.org"><span lang=EN-CA>gnso-accuracy-st@icann.org</span></a><span lang=EN-CA><br><b>Subject: </b>[GNSO-Accuracy-ST] Update - Working Accuracy Contractual Construct/ Definition</span><o:p></o:p></p></div><p class=MsoNormal><span lang=EN-CA> </span><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>For those colleagues that celebrated the Thanksgiving holiday yesterday, I hope you had an enjoyable time with your family and friends and did not eat too much. I would also like to thanks those team members that showed up for our brief Administrative Call yesterday.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>In preparing for the call yesterday I noted some of the new additions added by the RySG to the questions for ICANN staff. Thank you for these additions Roger. This flagged a previous issue which I had raised with our ICANN colleagues last weekend and it involves the current working contractual construct / definition.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>In the RySG questions they cited to the proposed RrSG accuracy “definition” (aka contractual construct):<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>"Accuracy shall be strictly defined as syntactical accuracy of the registration data elements provided by the Registered Name Holder as well as the operational accuracy of either the telephone number or the email address."<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Last week when I was looking for the latest and greatest contractual construct/definition I noted that there was a technical glitch when reviewing the Zoom recording which I will summarize below.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>If you go to the Zoom recording from the Nov 4<sup>th</sup> call you will see that the red lined version of the contractual construct/definition which was agreed to during the call and which is reflected below. <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal> However, at the conclusion of the call as we were wrapping up the session, these edits were lost <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Therefore, I would like clarification from the RySG do they wish to cite the group’s current working contractual construct/definition that was agreed to during the Nov 4<sup>th</sup> call, or do they intend to cite to the RrSG pre November 4<sup>th</sup> call contractual construct/definition?<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>I know these technical glitches, e.g. delta in Google Doc, Alan receiving emails, and the unavailability email archives makes things a little more challenging. However, I know our ICANN colleagues are working on the email issues, and I am sure we will be able to achieve most of our work asynchronously if we put our minds to it. <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><p class=MsoNormal><span lang=EN-CA style='font-size:12.0pt'> </span><o:p></o:p></p><div class=MsoNormal align=center style='text-align:center'><hr size=2 width="100%" align=center></div><p class=MsoNormal>The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see <a href="https://comlaude.com" target="_blank">www.comlaude.com</a> <o:p></o:p></p></div></body></html>