<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<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 class="moz-cite-prefix">On 2022-03-07 8:54 a.m., Steve Crocker
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CABf5zvL44ceXUDJFO7ArU=5Oo2Ew=5wdvTkKgqaOHdiLfLZZZg@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#000000">Michael,</div>
<div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#000000"><br>
</div>
<div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#000000">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:#000000">
<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:0 0 0 40px;border:none;padding:0px">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#000000">
<div>0 = accept whatever the registrant supplies</div>
</div>
</div>
</blockquote>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#000000">
<div>1 = check that the registrant's input fits
syntactically for the data element</div>
</div>
</div>
</blockquote>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#000000">
<div>2 = check that the registrant's input works
operationally</div>
</div>
</div>
</blockquote>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#000000">
<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:0 0 0 40px;border:none;padding:0px">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#000000">
<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:0 0 0 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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">GNSO-Accuracy-ST@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-accuracy-st" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">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 class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
GNSO-Accuracy-ST mailing list
<a class="moz-txt-link-abbreviated" href="mailto:GNSO-Accuracy-ST@icann.org">GNSO-Accuracy-ST@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-accuracy-st">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 class="moz-txt-link-freetext" href="https://www.icann.org/privacy/policy">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a class="moz-txt-link-freetext" href="https://www.icann.org/privacy/tos">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>
</body>
</html>