<div dir="ltr">Hi,<div><br></div><div>I think we need to differentiate between mandatory accuracy requirements and those accuracy processes adopted voluntarily by selected contracted parties for their very particular, specific purposes. Most of these TLDs have some form of eligibility requirement, something that simply is not the case for most TLDs.</div><div><br></div><div>For example, just because registrar A may have chosen to only accept registrations after verifying fingerprints and DNA of each customer, this does not make such a requirement relevant for our discussions. If we venture down this rabbit hole of voluntary measures intended to achieve very specific goals that do not apply to all TLDs equally, I dare predict we will still be here months from now. </div><div><br></div><div>Like Roger, I do not recall agreeing to the proposed changes, in fact, I think we need to object to most of them as they do not reflect a position we can support.</div><div><br></div><div>Best,<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span lang="EN-US">-- <br>Volker A. Greimann<br>General Counsel and Policy Manager<br><b>KEY-SYSTEMS GMBH</b><br><br>T: +49 6894 9396901<br>M: +49 6894 9396851<br>F: +49 6894 9396851<br>W: </span><a href="http://www.key-systems.net/" style="color:rgb(17,85,204)" target="_blank"><span lang="EN-US">www.key-systems.net</span></a><span lang="EN-US"><br><br>Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835<br>CEO: Oliver Fries and Robert Birkner<br><br>Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.<br><br></span><span style="font-family:Roboto,sans-serif;font-size:14px;white-space:pre-wrap;background-color:rgb(248,249,250)">This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached.</span></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 30, 2021 at 8:58 PM Michael Palage <<a href="mailto:michael@palage.com">michael@palage.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-4812646053945770916WordSection1"><p class="MsoNormal">Hello All,<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">As someone that watched the video recording twice allow me to recount the events of Nov 4^th.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></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:<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal" style="margin-left:0.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><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></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”.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></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:<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal" style="margin-left:0.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<u></u><u></u></p><p class="MsoNormal" style="margin-left:0.5in">contractual obligations by ICANN. (emphasis added)<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">These changes again were made with no substantive opposition from the group.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></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:<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><ol style="margin-top:0in" start="1" type="1"><li class="gmail-m_-4812646053945770916MsoListParagraph" style="margin-left:0in">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:<u></u><u></u></li></ol><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal" style="margin-left:0.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.<u></u><u></u></p><p class="MsoNormal" style="margin-left:0.5in">See <a href="https://information.aero/registration" target="_blank">https://information.aero/registration</a> and <a href="https://information.aero/node/add/request-aero-id" target="_blank">https://information.aero/node/add/request-aero-id</a> <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><ol style="margin-top:0in" start="2" type="1"><li class="gmail-m_-4812646053945770916MsoListParagraph" style="margin-left:0in">From the 2004 Sponsored round perhaps the best example was .XXX which made the following representations:<u></u><u></u></li></ol><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal" style="margin-left:0.5in">5.0  PREVENTING ABUSIVE REGISTRATIONS<u></u><u></u></p><p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p><p class="MsoNormal" style="margin-left:0.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.<u></u><u></u></p><p class="MsoNormal" style="margin-left:0.5in">See <a href="https://www.icmregistry.com/about/policies/launch/#general_aval" target="_blank">https://www.icmregistry.com/about/policies/launch/#general_aval</a><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><ol style="margin-top:0in" start="3" type="1"><li class="gmail-m_-4812646053945770916MsoListParagraph" style="margin-left:0in">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" target="_blank">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/" target="_blank">https://www.register.bank/get-started/</a><u></u><u></u></li></ol><p class="MsoNormal"><u></u> <u></u></p><ol style="margin-top:0in" start="4" type="1"><li class="gmail-m_-4812646053945770916MsoListParagraph" style="margin-left:0in">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" target="_blank">https://nabp.pharmacy/programs/accreditations-inspections/dotpharmacy/#apply</a><u></u><u></u></li></ol><p class="MsoNormal"><u></u> <u></u></p><ol style="margin-top:0in" start="5" type="1"><li class="gmail-m_-4812646053945770916MsoListParagraph" style="margin-left:0in">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.<u></u><u></u></li></ol><p class="gmail-m_-4812646053945770916MsoListParagraph"><u></u> <u></u></p><ol style="margin-top:0in" start="6" type="1"><li class="gmail-m_-4812646053945770916MsoListParagraph" style="margin-left:0in">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.<u></u><u></u></li></ol><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I hope this removes any ambiguity as to the events of Nov 4^th.  If, however, the RySG and RrSG maintain their objection we will revisit prior to our GAP analysis discussion as noted above.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Best regards,<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Michael<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><div><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in"><p class="MsoNormal"><b>From:</b> Lori Schulman <<a href="mailto:lschulman@inta.org" target="_blank">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" target="_blank">swyld@tucows.com</a>>; <a href="mailto:michael@palage.com" target="_blank">michael@palage.com</a>; <a href="mailto:gnso-accuracy-st@icann.org" target="_blank">gnso-accuracy-st@icann.org</a><br><b>Subject:</b> RE: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual Construct/ Definition<u></u><u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Hi,<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></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. <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal"><span style="color:rgb(31,73,125)">With kind regards,</span><u></u><u></u></p><p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p><p class="MsoNormal"><span style="color:rgb(31,73,125)">Lori S. Schulman</span><u></u><u></u></p><p class="MsoNormal"><span style="color:rgb(31,73,125)">Senior Director, Internet Policy</span><u></u><u></u></p><p class="MsoNormal"><b><span style="color:rgb(31,73,125)">International Trademark Association (INTA)</span></b><u></u><u></u></p><p class="MsoNormal"><span style="color:rgb(31,73,125)">+1-202-704-0408, Skype:  LSSchulman</span><u></u><u></u></p><p class="MsoNormal"><a href="mailto:lschulman@inta.org" target="_blank">lschulman@inta.org</a><span style="color:rgb(31,73,125)">, </span><a>www.inta.org</a><u></u><u></u></p><p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p></div><p class="MsoNormal"><u></u> <u></u></p><div><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in"><p class="MsoNormal"><b>From:</b> GNSO-Accuracy-ST <<a href="mailto:gnso-accuracy-st-bounces@icann.org" target="_blank">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" target="_blank">michael@palage.com</a>; <a href="mailto:gnso-accuracy-st@icann.org" target="_blank">gnso-accuracy-st@icann.org</a><br><b>Subject:</b> Re: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual Construct/ Definition<u></u><u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><span lang="EN-CA">Hi team,<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-CA"><u></u> <u></u></span></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! <u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-CA"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-CA">Sarah<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-CA"><u></u> <u></u></span></p><pre><span lang="EN-CA"><u></u> <u></u></span></pre><pre><span lang="EN-CA"><u></u> <u></u></span></pre><pre><span lang="EN-CA" style="font-family:Verdana,sans-serif">-- <u></u><u></u></span></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<u></u><u></u></span></pre><pre><span lang="EN-CA" style="font-family:Verdana,sans-serif"><u></u> <u></u></span></pre><pre><span lang="EN-CA" style="font-family:Verdana,sans-serif">Policy & Privacy Manager<u></u><u></u></span></pre><pre><span lang="EN-CA" style="font-family:Verdana,sans-serif">Pronouns: she/they<u></u><u></u></span></pre><pre><span lang="EN-CA" style="font-family:Verdana,sans-serif"><u></u> <u></u></span></pre><pre><a href="mailto:swyld@tucows.com" target="_blank"><span lang="EN-CA" style="font-family:Verdana,sans-serif">swyld@tucows.com</span></a><span style="font-family:Verdana,sans-serif"> <span lang="EN-CA"><u></u><u></u></span></span></pre><pre><span lang="EN-CA" style="font-family:Verdana,sans-serif">+1.416 535 0123 Ext. 1392<u></u><u></u></span></pre><p class="MsoNormal"><span lang="EN-CA" style="font-size:10pt;font-family:"Courier New""><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-CA"><img border="0" width="100" height="23" style="width: 1.0416in; height: 0.243in;" id="gmail-m_-4812646053945770916Picture_x0020_3" src="cid:17d760a42ab4cff311"></span><span lang="EN-CA"><u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-CA"><u></u> <u></u></span></p><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in"><p class="MsoNormal"><b><span lang="EN-CA">From: </span></b><a href="mailto:michael@palage.com" target="_blank"><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" target="_blank"><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<u></u><u></u></span></p></div><p class="MsoNormal"><span lang="EN-CA"><u></u> <u></u></span></p><p class="MsoNormal">Hello All,<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">In the RySG questions they cited to the proposed RrSG accuracy “definition” (aka contractual construct):<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></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."<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">If you go to the Zoom recording from the Nov 4^th 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.  <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><span style="font-size:12pt"><img border="0" width="802" height="465" style="width: 8.3541in; height: 4.8472in;" id="gmail-m_-4812646053945770916_x0000_i1026"></span><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"> However, at the conclusion of the call as we were wrapping up the session, these edits were lost <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><span style="font-size:12pt"><img border="0" width="809" height="455" style="width: 8.4236in; height: 4.743in;" id="gmail-m_-4812646053945770916_x0000_i1025"></span><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></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^th call, or do they intend to cite to the RrSG pre November 4^th call  contractual construct/definition?<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></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. <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Best regards,<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Michael<u></u><u></u></p><p class="MsoNormal"><span lang="EN-CA" style="font-size:12pt"><u></u> <u></u></span></p></div></div>_______________________________________________<br>
GNSO-Accuracy-ST mailing list<br>
<a href="mailto:GNSO-Accuracy-ST@icann.org" target="_blank">GNSO-Accuracy-ST@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-accuracy-st" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-accuracy-st</a><br>
<br>
_______________________________________________<br>
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy" rel="noreferrer" target="_blank">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" rel="noreferrer" target="_blank">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.</blockquote></div>