[GNSO-Accuracy-ST] Level Setting

[Volker Greimann]

Hi Michael,

until I have more data on the actual numbers of registrations with patently
false data such as Mickey Mouse, I cannot help but think those are edge
cases based on anecdotal evidence. Ultimately Mickey Mouse is a catchy
example that serves only to get people excited about the question of
accuracy, but without actual number and details, this could have been a
one-off case that is paraded in front of various parties to achieve an
impression that is ultimately not representative of the real issues.

Best,

-- 
Volker A. Greimann
General Counsel and Policy Manager
*KEY-SYSTEMS GMBH*

T: +49 6894 9396901
M: +49 6894 9396851
F: +49 6894 9396851
W: www.key-systems.net

Key-Systems GmbH is a company registered at the local court of
Saarbruecken, Germany with the registration no. HR B 18835
CEO: Oliver Fries and Robert Birkner

Part of the CentralNic Group PLC (LON: CNIC) a company registered in
England and Wales with company number 8576358.

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.


On Wed, Mar 16, 2022 at 2:20 PM Michael Palage <michael at palage.com> wrote:

> Sarah,
>
>
>
> I agree that a data subject notifying their Registrar to timely update
> their registration data is an important consideration in determining the
> accuracy of that data set. Likewise I think getting an affirmative response
> from a Registrant regarding the accuracy of the data in response to a
> legitimate inquiry is also an another important data point in any
> analysis.  Additionally, as we have heard from ICANN Compliance the
> provision of patently false data, e.g. Mickey Mouse, is problematic
> regardless of what the data subject represents.
>
>
>
> Best regards,
>
>
>
> Michael
>
>
>
>
>
>
>
> *From:* Sarah Wyld <swyld at tucows.com>
> *Sent:* Wednesday, March 16, 2022 8:18 AM
> *To:* Alan Greenberg <alan.greenberg at mcgill.ca>; Volker Greimann <
> volker.greimann at centralnic.com>; Michael Palage <michael at palage.com>
> *Cc:* Roger D Carney via GNSO-Accuracy-ST <gnso-accuracy-st at icann.org>
> *Subject:* RE: [GNSO-Accuracy-ST] Level Setting
>
>
>
> Hi all,
>
>
>
> Alan – yes, wouldn’t the registrant (data subject) be the authority on
> whether the data is accurate? And so the registrar must update (rectify)
> the registration data as soon as the registrant informs them of the
> inaccuracy.
>
>
>
>
>
>
>
> --
>
> *Sarah Wyld*, CIPP/E
>
>
>
> Policy & Privacy Manager
>
> Pronouns: she/they
>
>
>
> swyld at tucows.com
>
>
>
>
>
> *From: *Alan Greenberg <alan.greenberg at mcgill.ca>
> *Sent: *March 15, 2022 11:21 PM
> *To: *Volker Greimann <volker.greimann at centralnic.com>; Michael Palage
> <michael at palage.com>
> *Cc: *Roger D Carney via GNSO-Accuracy-ST <gnso-accuracy-st at icann.org>
> *Subject: *Re: [GNSO-Accuracy-ST] Level Setting
>
>
>
> "Under the GDPR, as the other extreme, data is fully 100% accurate if it
> "accurately" reflects the data provided by the registrant."
>
> GDPR (Article 5, Section 1(d)) says that "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"
>
> Alan
>
> At 2022-03-07 08:26 AM, Volker Greimann wrote:
>
> Hi Michael,
>
> 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?
>
> 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.
>
> 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.
>
>  So to answer your Question #1:
> I feel that option (b) "Degree of correctness" is a better reflection of
> the facts on the ground than a binary choice.
>
>
>
> --
> Volker A. Greimann
> General Counsel and Policy Manager
> *KEY-SYSTEMS GMBH*
>
> T: +49 6894 9396901
> M: +49 6894 9396851
> F: +49 6894 9396851
> W: www.key-systems.net
>
> Key-Systems GmbH is a company registered at the local court of
> Saarbruecken, Germany with the registration no. HR B 18835
> CEO: Oliver Fries and Robert Birkner
>
> Part of the CentralNic Group PLC (LON: CNIC) a company registered in
> England and Wales with company number 8576358.
>
> 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.
>
>
> On Sun, Mar 6, 2022 at 8:32 PM Michael Palage <michael at palage.com> wrote:
>
> Hello All,
>
>
>
> I am looking forward to a productive ICANN73 public session tomorrow.
>
>
>
> 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.
>
>
>
> 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
> https://community.icann.org/display/AST/2.+Council+Instructions+to+Scoping+Team
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> noun, plural
>
> 1.           the condition or quality of being true, correct, or exact;
> freedom from error or defect; precision or exactness; correctness.
>
> 2.           Chemistry, Physics. the extent to which a given measurement
> agrees with the standard value for that measurement. Compare precision
> (def. 6).
>
> 3.           Mathematics. the degree of correctness of a quantity,
> expression, etc. Compare precision (def. 5).
>
>
>
> Source Dictionary.com
>
>
>
> 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.
>
>
>
> 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:
>
>
>
> Question #1
>
>
>
> For purposes of our Working Group the term accuracy should be defined as:
>
>
>
> [  ] true, correct and free from error; or
>
>
>
> [  ] degree of correctness;
>
>
>
> (PICK ONE)
>
>
>
> 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.
>
>
>
> Best regards,
>
>
>
> Michael
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> GNSO-Accuracy-ST mailing list
>
> GNSO-Accuracy-ST at icann.org
>
> https://mm.icann.org/mailman/listinfo/gnso-accuracy-st
>
> _______________________________________________
>
> 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 ( https://www.icann.org/privacy/policy) and
> the website Terms of Service ( https://www.icann.org/privacy/tos). 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.
>
> _______________________________________________
> GNSO-Accuracy-ST mailing list
> GNSO-Accuracy-ST at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-accuracy-st
>
> _______________________________________________
> 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 ( https://www.icann.org/privacy/policy) and
> the website Terms of Service ( https://www.icann.org/privacy/tos). 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-accuracy-st/attachments/20220316/7b89446f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 15054 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/gnso-accuracy-st/attachments/20220316/7b89446f/image001-0001.png>