<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1256">
</head>
<body>
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p>and I suppose that the law already anticipates non-responsiveness, e.g., default judgments</p>
<p><br>
</p>
<div id="Signature">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, Helvetica, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;">
<p><b></b><span style="font-family:"Franklin Gothic Medium","Avenir Next Condensed Medium",sans-serif"><b><span style="color:rgb(0,111,201)">J. Beckwith Burr</span></b></span></p>
<p><span style="font-family:"Franklin Gothic Medium","Avenir Next Condensed Medium",sans-serif; color:rgb(0,111,201)">HARRIS, WILTSHIRE & GRANNIS </span><span style="font-size:9pt; font-family:"Franklin Gothic Medium","Avenir Next Condensed Medium",sans-serif; color:rgb(0,111,201)">LLP</span></p>
<p><span style="font-size:11pt; font-family:"Franklin Gothic Medium","Avenir Next Condensed Medium",sans-serif; color:rgb(0,111,201)">1919 M Street NW/8th Floor</span></p>
<p><span style="font-size:11pt; font-family:"Franklin Gothic Medium","Avenir Next Condensed Medium",sans-serif; color:rgb(0,111,201)">Washington DC 20036</span></p>
<p><span style="font-size:11pt; font-family:"Franklin Gothic Medium","Avenir Next Condensed Medium",sans-serif; color:rgb(0,111,201)">202.730.1316 (P) 202.352.6367 (M)</span></p>
<p><br>
</p>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Volker Greimann <volker.greimann@centralnic.com><br>
<b>Sent:</b> Monday, March 7, 2022 11:33:46 AM<br>
<b>To:</b> Becky Burr<br>
<b>Cc:</b> Stephanie E Perrin; gnso-accuracy-st@icann.org<br>
<b>Subject:</b> Re: [GNSO-Accuracy-ST] Level Setting</font>
<div> </div>
</div>
<div>
<div dir="ltr">Hi Becky,
<div><br>
</div>
<div>I do not think we should make a response or confirmation from the recipient a requirement. It is the prerogative of the registrant to decide whether to respond to anyone contacting them. </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 Mon, Mar 7, 2022 at 5:25 PM Becky Burr via GNSO-Accuracy-ST <<a href="mailto:gnso-accuracy-st@icann.org">gnso-accuracy-st@icann.org</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>
<div id="gmail-m_8512450102161742763divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p>I am comfortable with "data quality" and "contact." But don't we also need to agree on what "contactability" means? Is it enough to be able to send an email? Are users with legitimate interests entitled to know whether their communication has been received? <br>
</p>
<p><br>
</p>
<div id="gmail-m_8512450102161742763Signature">
<div id="gmail-m_8512450102161742763divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,Helvetica,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<p><b></b><span style="font-family:"Franklin Gothic Medium","Avenir Next Condensed Medium",sans-serif"><b><span style="color:rgb(0,111,201)">J. Beckwith Burr</span></b></span></p>
<p><span style="font-family:"Franklin Gothic Medium","Avenir Next Condensed Medium",sans-serif;color:rgb(0,111,201)">HARRIS, WILTSHIRE & GRANNIS </span><span style="font-size:9pt;font-family:"Franklin Gothic Medium","Avenir Next Condensed Medium",sans-serif;color:rgb(0,111,201)">LLP</span></p>
<p><span style="font-size:11pt;font-family:"Franklin Gothic Medium","Avenir Next Condensed Medium",sans-serif;color:rgb(0,111,201)">1919 M Street NW/8th Floor</span></p>
<p><span style="font-size:11pt;font-family:"Franklin Gothic Medium","Avenir Next Condensed Medium",sans-serif;color:rgb(0,111,201)">Washington DC 20036</span></p>
<p><span style="font-size:11pt;font-family:"Franklin Gothic Medium","Avenir Next Condensed Medium",sans-serif;color:rgb(0,111,201)">202.730.1316 (P) 202.352.6367 (M)</span></p>
<p><br>
</p>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_8512450102161742763divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> GNSO-Accuracy-ST <<a href="mailto:gnso-accuracy-st-bounces@icann.org" target="_blank">gnso-accuracy-st-bounces@icann.org</a>>
on behalf of Stephanie E Perrin <<a href="mailto:stephanie.perrin@mail.utoronto.ca" target="_blank">stephanie.perrin@mail.utoronto.ca</a>><br>
<b>Sent:</b> Monday, March 7, 2022 11:18:11 AM<br>
<b>To:</b> <a href="mailto:gnso-accuracy-st@icann.org" target="_blank">gnso-accuracy-st@icann.org</a><br>
<b>Subject:</b> Re: [GNSO-Accuracy-ST] Level Setting</font>
<div> </div>
</div>
<div>
<p>I think Steve's comments are very helpful here. Let me be clear....I do not disagree with Volker, who objects to my characterization of the word "accuracy" as binary. I prefer to use the expression "data quality" because it more exactly describes the decisions
we need to make regarding the work threshold imposed on contracted parties, and the intrusion on the RNH with respect to fulfilling the data demands that are imposed on him/her/it as a condition of registration.</p>
<p>The key question here is not the needs/wants/desires of third parties to determine precisely who the RNH is. It is what demands for data precision, revision, timeliness are imposed on the RNH in the context of getting access to the limited resource that
ICANN is tasked to manage. The key criterion has always been contactability. Obviously the CPs have a keen interest that the financial data provided actually works, so they need to leave no margin of error in such matters as credit card information, expiry
dates etc. However, that is "below the waterline" as I like to put it, it is none of ICANN's business. If the CPs can contact the registrant, all other processes can flow. If the RNH chooses not to be available for a private sector dispute, is the remedy
for this situation not already provided for in the contract with the RNH?</p>
<p>Use of the term "accuracy" in my view perpetuates this infinite desire for updating, verifying and amplifying the information collected from the RNH. We in the NCSG have resisted this on many grounds, not just the intrusion into personal information, the
failure to comply with the data limitation principle that is one of the key foundations of privacy law. It is also a response burden on the individual or company, something governments are acutely aware of in their own public policy initiatives. It is a
cost burden on the CPS, and we wish to maintain the low cost web that we all have known and loved for the past couple of decades.</p>
<p>The key question here is, when is the data "good enough". The answer is "when you can contact them". I think the proposed language from the Rys is confusing to someone not immersed up to his/her/their neck in this debate, and I hope we can come up with
something better.</p>
<p>kind regards, <br>
</p>
<p>Stephanie Perrin<br>
</p>
<div>On 2022-03-07 8:54 a.m., Steve Crocker wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">
Michael,</div>
<div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">
<br>
</div>
<div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">
Thanks for your thoughtful email. IMO, the touchstone question is whether the data elements serve the *needs* of the parties who receive the data. This statement includes some important implications.</div>
<div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">
<ol>
<li>The focus of attention is on the parties who get the data. Not the registrant, not the registrar, not the registry and not ICANN. The registrant, registrar, registry and ICANN also have interests in this process, but if the needs of the parties receiving
the data aren't met, the rest are irrelevant.<br>
<br>
</li><li>My phrase "parties who receive the data" includes recognition there may be conditions controlling whether a party does or does not receive the data. The question of whether a party requesting the data is allowed to receive the data, i.e., the access question,
is separate.<br>
<br>
</li><li>My choice of the word "needs" is related to what the receiving party does with the data. This is related to but distinct from "purposes" which has become a reserved word in our setting. The list of purposes in the EPDP reports is a rough attempt to capture
the same notion but forecloses any future discussions regarding whether the overall system is actually serving the needs of the community.
</li></ol>
<div>I have always understood the work of an "accuracy scoping team" is to lay the foundation for future policy development work. Accordingly, the definition of accuracy must include one or more dimensions of variability, with future policies setting the required
levels of accuracy in each dimension for the various circumstances. Two of the obvious dimensions are (1) the degree of certainty that the data is correct when it is supplied and (2) how recently it has been checked. The certainty dimension is</div>
</div>
</div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">
<div>0 = accept whatever the registrant supplies</div>
</div>
</div>
</blockquote>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">
<div>1 = check that the registrant's input fits syntactically for the data element</div>
</div>
</div>
</blockquote>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">
<div>2 = check that the registrant's input works operationally</div>
</div>
</div>
</blockquote>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">
<div>3 = check that the registrant's input is indeed correctly associated with the registrant</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">
<div>These degrees of certainty apply to *each* of the data elements provided by the registrant. For example, it is entirely plausible for a policy to require level 2 or 3 for the email address provided by the registrant but perhaps to permit level 0 for the
registrant's name or organization.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<font face="arial, sans-serif" color="#000000"><span class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">With respect to recency, possible values are</span></font>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<ul>
<li><font face="arial, sans-serif" color="#000000"><span class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">checked when the domain was registered</span></font>
</li><li><font face="arial, sans-serif" color="#000000"><span class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">checked annually</span></font>
</li><li><font face="arial, sans-serif" color="#000000"><span class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">etc.</span></font>
</li></ul>
</blockquote>
<font face="arial, sans-serif" color="#000000"><span class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">Much of what I've said here does not fit cleanly into the binary choice you've presented, but I'm clearly much closer
to the "degree of correctness" than the other choice. The other choice will lead to burying all of the distinctions and shortchange any discussion of the needs of the receiving parties.</span></font>
<div><font face="arial, sans-serif" color="#000000"><br>
</font></div>
<div><font face="arial, sans-serif" color="#000000"><span class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">Thanks,</span></font></div>
<div><font face="arial, sans-serif" color="#000000"><span class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)"><br>
</span></font></div>
<div><font face="arial, sans-serif" color="#000000"><span class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)">Steve</span></font></div>
<div><font face="arial, sans-serif" color="#000000"><span class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:rgb(0,0,0)"></span></font>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, Mar 6, 2022 at 2:32 PM Michael Palage <<a href="mailto:michael@palage.com" target="_blank">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">
<div>
<p class="MsoNormal"><span style="font-size:11pt">Hello All,</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">I am looking forward to a productive ICANN73 public session tomorrow.
</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">I spent the past several days trying to digest all of the exchanges that took place last Thursday. While I think we are close to wrapping up our work on Assignments 1 & 2, I think it would be constructive to
quickly level set and make sure we are all on the same page to minimize potential future confusion.
</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">Part of my level setting involved going back to the original GNSO Council’s charge to the Scoping Team which asked is there “an agreed definition of registration data accuracy and, if not, consider what working
definitions should be used in the context of the Scoping Team's deliberations.” See
<a href="https://community.icann.org/display/AST/2.+Council+Instructions+to+Scoping+Team" target="_blank">
https://community.icann.org/display/AST/2.+Council+Instructions+to+Scoping+Team</a>
</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">This task at first blush seems simple enough, but as we have learned there have been several concerns raised in connection with the use of the term “definition” and the meaning of “accuracy.” Therefore, instead
of using the term “definition” as proposed by the GNSO Council I propose that we use the phrase “current contractual requirements and enforcement construct.” I believe this should meet the concerns of the RrSG that have repeatedly raised concerns about “providing
a definition” and the concerns of the GAC and others about how a definition might bias future discussions.</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">Is there any objection to us using the phrase “current contractual requirements and enforcement construct?” If so please explain your objection and proposed alternative suggestion.</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">Next we need to tackle what I have deemed the accuracy conundrum. The intervention by Stephanie this past week reminded me of some previous research that I was doing which I decided to revisit. I think Stephanie
hit the nail on the head when she talked about how “accuracy” to most people conveys a binary choice, e.g. the data is accurate or is the data inaccurate. It is a black or white answer with no room for grey. In fact this seemed to align closely with the RrSG
proposed “current contractual requirements and enforcement construct.” If the data collected meets syntactical validation and either the email or phone number was operationally verified, then the data provided by the Registrant was “accurate” per their interpretation
of the 2013 RAA.</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">So I decided to spend a couple of hours researching the definition and origins of the word “accuracy” online and with an old school trip to the local library. I believe this definition of the word “accuracy”
best describes the conundrum that we as a group find ourselves. </span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">noun, plural </span></p>
<p class="MsoNormal"><span style="font-size:11pt">1. the condition or quality of being true, correct, or exact; freedom from error or defect; precision or exactness; correctness.</span></p>
<p class="MsoNormal"><span style="font-size:11pt">2. Chemistry, Physics. the extent to which a given measurement agrees with the standard value for that measurement. Compare precision (def. 6).</span></p>
<p class="MsoNormal"><span style="font-size:11pt">3. Mathematics. the degree of correctness of a quantity, expression, etc. Compare precision (def. 5).</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">Source Dictionary.com</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">Now the first definition “being true, correct, or exact; freedom from error or defect” is a rather high bar, particularly if you are applying this bar to all registration data elements processed like some working
group members have advocated. However, that bar is substantially lower if free from defect simply means that the data collected by the Registrar was syntactically correct and a Registrar at a point in time got an affirmative response from either telephone
number or an email. </span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">Alternatively, the third definition of a “degree of correctness” suggests something other than a binary accurate or inaccurate response. Therefore to help steer our future discussions I would like everyone
to answer the following question:</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">Question #1</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">For purposes of our Working Group the term accuracy should be defined as:
</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">[ ] true, correct and free from error; or</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">[ ] degree of correctness;</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">(PICK ONE)</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">I think once we get clarity and/or agreement on these points, we should have a more clearly defined path forward for our post ICANN73 call.</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">Best regards,</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt">Michael</span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt"></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>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
GNSO-Accuracy-ST mailing list
<a href="mailto:GNSO-Accuracy-ST@icann.org" target="_blank">GNSO-Accuracy-ST@icann.org</a>
<a href="https://mm.icann.org/mailman/listinfo/gnso-accuracy-st" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-accuracy-st</a>
_______________________________________________
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" target="_blank">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" 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.</pre>
</blockquote>
</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>
</div>
</body>
</html>