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+T... 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
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@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+T...
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@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.
If defining "accuracy" for the purpose of contact details, I'd claim that the word is the wrong one to use - the right one is "fitness for purpose" - if you try to contact the registrant using those details, will you be able to contact them? Unfortunately, some of the usages envisaged for WHOIS data (such as trying to find out whether or not two domains are registered to the same entity) place requirements on "accuracy" that go beyond the able-to-contact usage. Anyway, that's not terribly relevant to the question. My vote (if I have one, as a non-voting observer) is option (b): Degree of correctness. On Mon, Mar 7, 2022 at 1:27 PM Volker Greimann < volker.greimann@centralnic.com> 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@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+T...
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@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@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.
-- Me in the role of IETF liaison to the ICANN board.
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@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+T...
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@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.
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. 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? 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. 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. kind regards, Stephanie Perrin On 2022-03-07 8:54 a.m., Steve Crocker 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@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+T...
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@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@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.
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? J. Beckwith Burr HARRIS, WILTSHIRE & GRANNIS LLP 1919 M Street NW/8th Floor Washington DC 20036 202.730.1316 (P) 202.352.6367 (M) ________________________________ From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces@icann.org> on behalf of Stephanie E Perrin <stephanie.perrin@mail.utoronto.ca> Sent: Monday, March 7, 2022 11:18:11 AM To: gnso-accuracy-st@icann.org Subject: Re: [GNSO-Accuracy-ST] Level Setting 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 [https://alert-dg01.redatatech.com/onprem_security_warning_fetch?r=1&dep=ZmrsSr%2BLmSDIYp4DHo9PNA%3D%3DMrbzsxSFtHoJsgAW64ankya67seCB4AMCoj0rIvxsy0GPdU43G2S2XXhjxVpjERWdJnk5EcfyhIS1mTi6EfcxcHauRfUKMyMfS2wzyOQ8qcNRlr%2FQKqrZA2YjXG4Xx%2BcUPKFaVBdQ7pkZ8qjgFs1imPau67xcz2RFTuJMDQLfM3zFOR%2Bw4NzYJtOFPA9HQXvJa54m2VloCfQViQW6o%2Bdwu9V%2BRuiRrjrb4aNT9z83Xkh8jLZFgnTA76YV00MTRpB0ajAVaDJMXsaGJ7PW%2BM9ljqDxcP59Reur68gT%2BNCNRhz1j5nrSH8sTEWyGBhNSxowPIAH8sfmWPmZnKucJzCjxMNtUPNgeg2QNPzEOAzGx2QvH8S8KFWKlTVysBW9siSn8nuEScGef4pyf5w%2BOaCpYQVkp10agXeOZ69qzurSKaKoXyBr%2F6r%2BALnWqYGSYHHoVfNqrTb5O9kPlUr8%2BNFUUcVQeeA0aEaAwL743ZlENae5gU1wPYQJ2EZ8wUbZwqBthS9LbDG3c4pkRSYLmB1%2BEG02BS6WKY3AzzrWc%2BnW9QREmrtVGIyCuaJGts6bt5pfRklDeX%2FxGKvEPLm0aKwb2aQAfrIojrwesmBBUnvP5tDMzPQiIRSMNnpDwT67IA0K2g83oX%2B7HqhTiRcCOZSUQn%2BmSMtD6dxQRWtMmpAny2CMAPclKxDjxvx3i3mIYygFMzC8zJqZgdzWPES%2FwtBjaVMnlmCbWveBM%2Fv2cJ%2FxOA%3D]<https://us.report.cybergraph.mimecast.com/alert-details/?dep=ZmrsSr%2BLmSDIYp4DHo9PNA%3D%3DMrbzsxSFtHoJsgAW64ankya67seCB4AMCoj0rIvxsy0GPdU43G2S2XXhjxVpjERWdJnk5EcfyhIS1mTi6EfcxcHauRfUKMyMfS2wzyOQ8qcNRlr%2FQKqrZA2YjXG4Xx%2BcUPKFaVBdQ7pkZ8qjgFs1imPau67xcz2RFTuJMDQLfM3zFOR%2Bw4NzYJtOFPA9HQXvJa54m2VloCfQViQW6o%2Bdwu9V%2BRuiRrjrb4aNT9z83Xkh8jLZFgnTA76YV00MTRpB0ajAVaDJMXsaGJ7PW%2BM9ljqDxcP59Reur68gT%2BNCNRhz1j5nrSH8sTEWyGBhNSxowPIAH8sfmWPmZnKucJzCjxMNtUPNgeg2QNPzEOAzGx2QvH8S8KFWKlTVysBW9siSn8nuEScGef4pyf5w%2BOaCpYQVkp10agXeOZ69qzurSKaKoXyBr%2F6r%2BALnWqYGSYHHoVfNqrTb5O9kPlUr8%2BNFUUcVQeeA0aEaAwL743ZlENae5gU1wPYQJ2EZ8wUbZwqBthS9LbDG3c4pkRSYLmB1%2BEG02BS6WKY3AzzrWc%2BnW9QREmrtVGIyCuaJGts6bt5pfRklDeX%2FxGKvEPLm0aKwb2aQAfrIojrwesmBBUnvP5tDMzPQiIRSMNnpDwT67IA0K2g83oX%2B7HqhTiRcCOZSUQn%2BmSMtD6dxQRWtMmpAny2CMAPclKxDjxvx3i3mIYygFMzC8zJqZgdzWPES%2FwtBjaVMnlmCbWveBM%2Fv2cJ%2FxOA%3D> 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. 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? 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. 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. kind regards, Stephanie Perrin On 2022-03-07 8:54 a.m., Steve Crocker 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@palage.com<mailto:michael@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+T... 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@icann.org<mailto:GNSO-Accuracy-ST@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@icann.org<mailto:GNSO-Accuracy-ST@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.
Hi Becky, 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. 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 Mon, Mar 7, 2022 at 5:25 PM Becky Burr via GNSO-Accuracy-ST < gnso-accuracy-st@icann.org> wrote:
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?
*J. Beckwith Burr*
HARRIS, WILTSHIRE & GRANNIS LLP
1919 M Street NW/8th Floor
Washington DC 20036
202.730.1316 (P) 202.352.6367 (M)
------------------------------ *From:* GNSO-Accuracy-ST <gnso-accuracy-st-bounces@icann.org> on behalf of Stephanie E Perrin <stephanie.perrin@mail.utoronto.ca> *Sent:* Monday, March 7, 2022 11:18:11 AM *To:* gnso-accuracy-st@icann.org *Subject:* Re: [GNSO-Accuracy-ST] Level Setting
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.
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?
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.
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.
kind regards,
Stephanie Perrin On 2022-03-07 8:54 a.m., Steve Crocker 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@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+T...
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@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 listGNSO-Accuracy-ST@icann.orghttps://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@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.
and I suppose that the law already anticipates non-responsiveness, e.g., default judgments J. Beckwith Burr HARRIS, WILTSHIRE & GRANNIS LLP 1919 M Street NW/8th Floor Washington DC 20036 202.730.1316 (P) 202.352.6367 (M) ________________________________ From: Volker Greimann <volker.greimann@centralnic.com> Sent: Monday, March 7, 2022 11:33:46 AM To: Becky Burr Cc: Stephanie E Perrin; gnso-accuracy-st@icann.org Subject: Re: [GNSO-Accuracy-ST] Level Setting Hi Becky,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. Best,-- Volker A. GreimannGeneral Counsel and Policy ManagerKEY-SYSTEMS GMBHT: +49 6 [https://alert-dg01.redatatech.com/onprem_security_warning_fetch?r=1&dep=AKJv38vyFhEecVaJ%2B6VUCw%3D%3DiWGkaWx%2Fekvv5h7VozXAlPZht2qodDnWlPGhUYXfsq6cdMYgJtYd%2BE2YDiOXXetwHCEZMekfzjbn7WFDJx%2F1rOEoC09uxMcbobYvl%2FqKNBFmdzwnVPvL6rU3APVcES6jN3xAP80LmgM8PhKI%2FTgQAzjBIhHXaexyNt9ZAaca%2BPK2%2FoKcKpS7BNYkXSF%2F957aHc1HtgvWuKGVF8rgmBgGqeQMRcmDdXS%2BgzT447zTUVnZ3t%2Bdoezg9AbbXR7gb4uwPacsErIw7oD4E0qJnsBO7vsWd9KK5vl5CABCkyrtDWO4kH3J1eeltJJVgXwKoKbHB0CY43Q7TM4cPG60TqHJ3N0g3B1Bxwc2Y8fIHv3SU3ddeNhPdd3q9T43cYyBuPanSt%2B2BBuhLTVlj73ZtvAmGI8yosEuts1rYpX8M6jogIrt0EgHBXuTZGf6od4Bk1QnPKdcXNppPmfE%2F6JejpVcHgdIOOUX97L4jv3rH9SANLN%2BmyOAkMz8FRjQV8558Jl%2FTO5E2C0eh9%2BR47LKY6pobFNFrS4yPsdgb1lS%2BYBetU4o%2FXAzT%2Fg1Oi%2BKjMyrU3fV0HTjeXFm9V1aBcATYtQ9rW%2BLXROCGcEfpvqB64uJex%2FNGXaTV9PDajjc7WQw2nN2kQsJLlxh9uUGayn1JIEjxw%3D%3D]<https://us.report.cybergraph.mimecast.com/alert-details/?dep=AKJv38vyFhEecVaJ%2B6VUCw%3D%3DiWGkaWx%2Fekvv5h7VozXAlPZht2qodDnWlPGhUYXfsq6cdMYgJtYd%2BE2YDiOXXetwHCEZMekfzjbn7WFDJx%2F1rOEoC09uxMcbobYvl%2FqKNBFmdzwnVPvL6rU3APVcES6jN3xAP80LmgM8PhKI%2FTgQAzjBIhHXaexyNt9ZAaca%2BPK2%2FoKcKpS7BNYkXSF%2F957aHc1HtgvWuKGVF8rgmBgGqeQMRcmDdXS%2BgzT447zTUVnZ3t%2Bdoezg9AbbXR7gb4uwPacsErIw7oD4E0qJnsBO7vsWd9KK5vl5CABCkyrtDWO4kH3J1eeltJJVgXwKoKbHB0CY43Q7TM4cPG60TqHJ3N0g3B1Bxwc2Y8fIHv3SU3ddeNhPdd3q9T43cYyBuPanSt%2B2BBuhLTVlj73ZtvAmGI8yosEuts1rYpX8M6jogIrt0EgHBXuTZGf6od4Bk1QnPKdcXNppPmfE%2F6JejpVcHgdIOOUX97L4jv3rH9SANLN%2BmyOAkMz8FRjQV8558Jl%2FTO5E2C0eh9%2BR47LKY6pobFNFrS4yPsdgb1lS%2BYBetU4o%2FXAzT%2Fg1Oi%2BKjMyrU3fV0HTjeXFm9V1aBcATYtQ9rW%2BLXROCGcEfpvqB64uJex%2FNGXaTV9PDajjc7WQw2nN2kQsJLlxh9uUGayn1JIEjxw%3D%3D> Hi Becky, 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. 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<http://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 5:25 PM Becky Burr via GNSO-Accuracy-ST <gnso-accuracy-st@icann.org<mailto:gnso-accuracy-st@icann.org>> wrote: 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? J. Beckwith Burr HARRIS, WILTSHIRE & GRANNIS LLP 1919 M Street NW/8th Floor Washington DC 20036 202.730.1316 (P) 202.352.6367 (M) ________________________________ From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces@icann.org<mailto:gnso-accuracy-st-bounces@icann.org>> on behalf of Stephanie E Perrin <stephanie.perrin@mail.utoronto.ca<mailto:stephanie.perrin@mail.utoronto.ca>> Sent: Monday, March 7, 2022 11:18:11 AM To: gnso-accuracy-st@icann.org<mailto:gnso-accuracy-st@icann.org> Subject: Re: [GNSO-Accuracy-ST] Level Setting 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. 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? 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. 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. kind regards, Stephanie Perrin On 2022-03-07 8:54 a.m., Steve Crocker 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@palage.com<mailto:michael@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+T... 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@icann.org<mailto:GNSO-Accuracy-ST@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@icann.org<mailto:GNSO-Accuracy-ST@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@icann.org<mailto:GNSO-Accuracy-ST@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.
Hi Becky. In a way,it does although I doubt you can get a default judgement for failing to respond to an email. I see it more akin to pleading the fifth. -- 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. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Mon, Mar 7, 2022 at 6:04 PM Becky Burr <BBurr@hwglaw.com> wrote:
and I suppose that the law already anticipates non-responsiveness, e.g., default judgments
*J. Beckwith Burr*
HARRIS, WILTSHIRE & GRANNIS LLP
1919 M Street NW/8th Floor
Washington DC 20036
202.730.1316 (P) 202.352.6367 (M)
------------------------------ *From:* Volker Greimann <volker.greimann@centralnic.com> *Sent:* Monday, March 7, 2022 11:33:46 AM *To:* Becky Burr *Cc:* Stephanie E Perrin; gnso-accuracy-st@icann.org *Subject:* Re: [GNSO-Accuracy-ST] Level Setting
Hi Becky,
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.
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 Mon, Mar 7, 2022 at 5:25 PM Becky Burr via GNSO-Accuracy-ST < gnso-accuracy-st@icann.org> wrote:
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?
*J. Beckwith Burr*
HARRIS, WILTSHIRE & GRANNIS LLP
1919 M Street NW/8th Floor
Washington DC 20036
202.730.1316 (P) 202.352.6367 (M)
------------------------------ *From:* GNSO-Accuracy-ST <gnso-accuracy-st-bounces@icann.org> on behalf of Stephanie E Perrin <stephanie.perrin@mail.utoronto.ca> *Sent:* Monday, March 7, 2022 11:18:11 AM *To:* gnso-accuracy-st@icann.org *Subject:* Re: [GNSO-Accuracy-ST] Level Setting
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.
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?
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.
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.
kind regards,
Stephanie Perrin On 2022-03-07 8:54 a.m., Steve Crocker 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@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+T...
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@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 listGNSO-Accuracy-ST@icann.orghttps://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@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.
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
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@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@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+T...
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@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@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.
Michael: Stephanie’s reference earlier to data quality reminded me that when I started looking at the assignments here on accuracy scoping and definitions back in November, I too hit the books but I choose the online library of Wikipedia for a quick study. I ended up at a page on data quality which considered accuracy as an element. I share the link now because it provides some useful context to further this stage of discussion and the information also shows that the determination of data quality varies depending on the perspective of who is using it and who is managing it, etc. Among the definitions they provide: from a standards based perspective "the usefulness, accuracy, and correctness of data for its application" so I guess I will I will go with your correctness option as that appears the closer of your two options. They also provide from a business perspective: quality data exhibits "'conformance to standards' that have been set, so that fitness for use is achieved” https://en.wikipedia.org/wiki/Data_quality For those who suggest that a registrant’s data quality submitted is good enough so long as we can contact them I think we still fall short of an important element of quality, accuracy or correctness: reliability. What if we contact the wrong “them”. What if the registrant’s name submitted by the submerged account holder is yours, mine or any member on this list but its none of us who submitted it? Is that data accurate ? Is that the quality of data that we should accept as “good enough”? That ICANN and its global user constituency should rely on? And as for costs, what about the costs to rightsholders, who now have to sue even to obtain the true name and jurisdiction of the one who abuses the rightsholder’s identity, embodied in their business name or mark. But those are just the secondary costs. Lets not overlook the primary costs, often incurred even before the rightsholder has been alerted to the bad actor’s abuse: 1) damages to business reputation, 2) fake substandard goods or services, and 3)phished identities and financial data of unsuspecting customers. Privacy should be protected; fabricated anonymity to encourage identity impersonation, fraud and phishing and assist in evading detection and liability for abuse should not. Best regards, Scott Please click on a link below to calendar a 15, 30, or 60 minute call with me: a 15-minute call<calendly.com/saustin2/15min> a 30-minute call<calendly.com/saustin2/30min> a 60-minute call<calendly.com/saustin2/60min> [cid:image001.png@01D8323E.03EFFBD0][IntellectualPropertyLaw 100] [microbadge[1]] <http://www.avvo.com/attorneys/33308-fl-scott-austin-1261914.html> Scott R. Austin | Board Certified Intellectual Property Attorney | VLP Law Group LLP 101 NE Third Avenue, Suite 1500, Fort Lauderdale, FL 33301 Phone: (954) 204-3744 | Fax: (954) 320-0233 | SAustin@VLPLawGroup.com<mailto:SAustin@VLPLawGroup.com> From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces@icann.org> On Behalf Of Michael Palage Sent: Sunday, March 6, 2022 2:32 PM To: gnso-accuracy-st@icann.org Subject: [GNSO-Accuracy-ST] Level Setting 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<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 This message contains information which may be confidential and legally privileged. Unless you are the addressee, you may not use, copy or disclose to anyone this message or any information contained in the message. If you have received this message in error, please send me an email and delete this message. Any tax advice provided by VLP is for your use only and cannot be used to avoid tax penalties or for promotional or marketing purposes.
Hi Scott, we cannot apply a general definition to the term accuracy as it must be framed in the purposes that the data is collected from the registrant for. As you say, a standards based perspective of "the usefulness, accuracy, and correctness of data for its application may apply but only to the purposes that have been clearly outlined in the prior PDP work, e.g. the EPDP. As such, for the general public, contactibility comes into play, e.g. can you contact the registrant of record using this data. In your specific case of what amounts to identity theft, e.g. a third party pretending to be someone else, the essential question is who actually is the registrant of record in these cases. Is it the shadowy figure behind the curtain refusing to reveal itself or is it the entity listed as the registrant. In the past, we have always held the registrant of record to the the legitimate owner of a domain name, regardless of whether he/she/it has triggered the registration as this means that they can assert full control over the domain and its use when they notice or are notified of the situation, including ordering its deletion or transfer to a complainant. In that context, the contactibility of the registrant would be maintained even if the data is not actually that of the entity that executed the registration. It is essentially a case of agency without authority. 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. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Mon, Mar 7, 2022 at 11:24 PM Scott Austin <saustin@vlplawgroup.com> wrote:
Michael:
Stephanie’s reference earlier to data quality reminded me that when I started looking at the assignments here on accuracy scoping and definitions back in November, I too hit the books but I choose the online library of Wikipedia for a quick study. I ended up at a page on data quality which considered accuracy as an element. I share the link now because it provides some useful context to further this stage of discussion and the information also shows that the determination of data quality varies depending on the perspective of who is using it and who is managing it, etc. Among the definitions they provide: from a standards based perspective "the usefulness, accuracy, and correctness of data for its application" so I guess I will I will go with your correctness option as that appears the closer of your two options. They also provide from a business perspective: quality data exhibits "'conformance to standards' that have been set, so that fitness for use is achieved”
https://en.wikipedia.org/wiki/Data_quality
For those who suggest that a registrant’s data quality submitted is good enough so long as we can contact them I think we still fall short of an important element of quality, accuracy or correctness: reliability.
What if we contact the wrong “them”.
What if the registrant’s name submitted by the submerged account holder is yours, mine or any member on this list but its none of us who submitted it?
Is that data accurate ?
Is that the quality of data that we should accept as “good enough”?
That ICANN and its global user constituency should rely on?
And as for costs, what about the costs to rightsholders, who now have to sue even to obtain the true name and jurisdiction of the one who abuses the rightsholder’s identity, embodied in their business name or mark. But those are just the secondary costs. Lets not overlook the primary costs, often incurred even before the rightsholder has been alerted to the bad actor’s abuse: 1) damages to business reputation, 2) fake substandard goods or services, and 3)phished identities and financial data of unsuspecting customers.
Privacy should be protected; fabricated anonymity to encourage identity impersonation, fraud and phishing and assist in evading detection and liability for abuse should not.
Best regards,
Scott
*Please click on a link below to calendar a 15, 30, or 60 minute call with me:*
* a 15-minute call <http://calendly.com/saustin2/15min> * a 30-minute call <http://calendly.com/saustin2/30min> a 60-minute call <http://calendly.com/saustin2/60min>
*[image: IntellectualPropertyLaw 100] **[image: microbadge[1]]* <http://www.avvo.com/attorneys/33308-fl-scott-austin-1261914.html>
Scott R. Austin | Board Certified Intellectual Property Attorney | VLP Law Group LLP
101 NE Third Avenue, Suite 1500, Fort Lauderdale, FL 33301
Phone: (954) 204-3744 | Fax: (954) 320-0233 | SAustin@VLPLawGroup.com
*From:* GNSO-Accuracy-ST <gnso-accuracy-st-bounces@icann.org> *On Behalf Of *Michael Palage *Sent:* Sunday, March 6, 2022 2:32 PM *To:* gnso-accuracy-st@icann.org *Subject:* [GNSO-Accuracy-ST] Level Setting
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+T...
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
This message contains information which may be confidential and legally privileged. Unless you are the addressee, you may not use, copy or disclose to anyone this message or any information contained in the message. If you have received this message in error, please send me an email and delete this message. Any tax advice provided by VLP is for your use only and cannot be used to avoid tax penalties or for promotional or marketing purposes. _______________________________________________ GNSO-Accuracy-ST mailing list GNSO-Accuracy-ST@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.
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
participants (7)
-
Becky Burr -
Harald Alvestrand -
Michael Palage -
Scott Austin -
Stephanie E Perrin -
Steve Crocker -
Volker Greimann