<html>
<body>
"Under the GDPR, as the other extreme, data is fully 100% accurate
if it "accurately" reflects the data provided by the
registrant."<br><br>
GDPR <font face="Courier New, Courier">(Article 5, Section 1(d))</font>
says that "<font face="Courier New, Courier">every reasonable step
must be taken to ensure that personal data that are inaccurate, having
regard to the purposes for which they are processed, are erased or
rectified without delay" <br><br>
</font>Alan<br><br>
At 2022-03-07 08:26 AM, Volker Greimann wrote:<br>
<blockquote type=cite class=cite cite="">Hi Michael,<br><br>
I do not understand your hesitation to call it a definition, or even a
working definition as that is the exact terminology that the council has
tasked us with. If we cannot even agree on a definition, how are we
supposed to make progress on the more complicated issues?<br><br>
As to the question of the term of accuracy, I believe we have already
established that there are varying interpretations, and ultimately, our
definition within the ICANN context has to flow from the definition.
Looking at dictionaries may be helpful, but does not solve the conundrum
of context. I disagree with Stephanie that accuracy needs to be a binary
choice as there can be various levels of accuracy in our context.
<br><br>
For example, a data set that just uses the wrong formatting may not be
100% accurate in the dictionary sense, but is still accurate enough to
qualify for "sufficiently accurate to meet the purposes", even
if it is not fully accurate in the meaning of the 2013 RAA, which may
need some revision to be more generous towards registrants in some cases.
Under the GDPR, as the other extreme, data is fully 100% accurate if it
"accurately" reflects the data provided by the registrant.
<br><br>
So to answer your Question #1:<br>
I feel that option (b) "Degree of correctness" is a better
reflection of the facts on the ground than a binary choice. <br><br>
<br><br>
-- <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: <a href="http://www.key-systems.net/">www.key-systems.net</a><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>
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.<br><br>
<br>
On Sun, Mar 6, 2022 at 8:32 PM Michael Palage
<<a href="mailto:michael@palage.com">michael@palage.com</a>>
wrote:<br>
<dl><br>
<dd>Hello All,<br><br>
<dd> <br><br>
<dd>I am looking forward to a productive ICANN73 public session
tomorrow. <br><br>
<dd> <br><br>
<dd>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. <br><br>
<dd> <br><br>
<dd>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">
https://community.icann.org/display/AST/2.+Council+Instructions+to+Scoping+Team</a>
<br><br>
<dd> <br><br>
<dd>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.<br><br>
<dd> <br><br>
<dd>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.<br><br>
<dd> <br><br>
<dd>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.<br><br>
<dd> <br><br>
<dd>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. <br><br>
<dd> <br><br>
<dd>noun, plural <br><br>
<dd>1. the
condition or quality of being true, correct, or exact; freedom from error
or defect; precision or exactness; correctness.<br><br>
<dd>2.
Chemistry, Physics. the extent to which a given measurement agrees with
the standard value for that measurement. Compare precision (def.
6).<br><br>
<dd>3.
Mathematics. the degree of correctness of a quantity, expression, etc.
Compare precision (def. 5).<br><br>
<dd> <br><br>
<dd>Source Dictionary.com<br><br>
<dd> <br><br>
<dd>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. <br><br>
<dd> <br><br>
<dd>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:<br><br>
<dd> <br><br>
<dd>Question #1<br><br>
<dd> <br><br>
<dd>For purposes of our Working Group the term accuracy should be defined
as: <br><br>
<dd> <br><br>
<dd>[ ] true, correct and free from error; or<br><br>
<dd> <br><br>
<dd>[ ] degree of correctness;<br><br>
<dd> <br><br>
<dd>(PICK ONE)<br><br>
<dd> <br><br>
<dd>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.<br><br>
<dd> <br><br>
<dd>Best regards,<br><br>
<dd> <br><br>
<dd>Michael<br><br>
<dd> <br><br>
<dd> <br><br>
<dd> <br><br>
<dd> <br><br>
<dd>_______________________________________________<br>
<dd>GNSO-Accuracy-ST mailing list<br>
<dd><a href="mailto:GNSO-Accuracy-ST@icann.org">
GNSO-Accuracy-ST@icann.org</a><br>
<dd>
<a href="https://mm.icann.org/mailman/listinfo/gnso-accuracy-st" eudora="autourl">
https://mm.icann.org/mailman/listinfo/gnso-accuracy-st</a><br><br>
<dd>_______________________________________________<br>
<dd>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">
https://www.icann.org/privacy/policy</a>) and the website Terms of
Service
(<a 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.<br><br>
</dl>_______________________________________________<br>
GNSO-Accuracy-ST mailing list<br>
GNSO-Accuracy-ST@icann.org<br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-accuracy-st" eudora="autourl">
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" eudora="autourl">
https://www.icann.org/privacy/policy</a>) and the website Terms of
Service
(<a href="https://www.icann.org/privacy/tos" eudora="autourl">
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></body>
</html>