[GNSO-Accuracy-ST] Level Setting

Mon Mar 7 16:32:22 UTC 2022

Actually, there is an unofficial (outside ICANN) process in place of
checking the identity of the registrant:
SSL certificates

If you want a certain quality of SSL certificate on your domain, you will
have to participate in verification processes of varying strictness.

Sadly, browser publishers have decided they do no longer like these
certificates and seem to be working hard to eliminate them.

-- 
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 Mon, Mar 7, 2022 at 2:54 PM Steve Crocker <steve at shinkuro.com> wrote:

> Michael,
>
> 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.
>
>    1. 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.
>
>    2. 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.
>
>    3. 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.
>
> 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
>
> 0 = accept whatever the registrant supplies
>
> 1 = check that the registrant's input fits syntactically for the data
> element
>
> 2 = check that the registrant's input works operationally
>
> 3 = check that the registrant's input is indeed correctly associated with
> the registrant
>
> 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.
>
> With respect to recency, possible values are
>
>
>    - checked when the domain was registered
>    - checked annually
>    - etc.
>
> 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.
>
> Thanks,
>
> Steve
>
> On Sun, Mar 6, 2022 at 2: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/20220307/111303be/attachment-0001.html>