Sarah, et al, With respect to focusing on just the definition of accuracy, is our focus solely on the accuracy of email and phone numbers, or do we anticipate the PDP will be setting rules for the accuracy of the myriad of other data elements? Further, are we providing a single level of accuracy or choices for different levels of accuracy? If our work is aimed at setting a single standard for accuracy, which I assume will be operational validation, and it's intended to apply only to email and phone numbers, then the path forward is easy. We can converge on the wording that defines operational validation, and the PDP will not have any work to do regarding setting the requirements. The implication, of course, is the PDP will say nothing about the accuracy of the other data elements, and the only purposes that can be supported will have to depend solely on operational validation of email and/or phone numbers. Thanks, Steve On Thu, Nov 18, 2021 at 8:19 AM Sarah Wyld <swyld@tucows.com> wrote:
Hello all,
It seems to me that listing the agreed-upon purposes that registration data is supposed to serve may not be part of our instructions, or if we do need to do so it would be in service of answering Instruction #3:
“3. Effectiveness: The Scoping Team will, on the basis of its assessment under 1. and data resulting from 2., undertake an analysis of the accuracy levels measured to assess whether the contractual data accuracy obligations are effective at ensuring that Registered Name Holders provide “accurate and reliable” contact information.”
I could see that we can’t assess if obligations are effective without having an understanding of what effective means, which could relate to the purpose for collecting registration data.
That said, I don’t think these purposes are related to the work we need to do for Instructions #1 and #2, which have us assessing how accuracy is monitored, considering if there is a definition of accuracy (I think there is), and providing suggestions for how to measure accuracy.
I think we’ll get through this work the most efficiently if we stick to the plan and follow the schedule we’ve already agreed on, which means starting with instructions 1 and 2.
Looking forward to discussing!
Thanks,
--
*Sarah Wyld*, CIPP/E
Policy & Privacy Manager
Pronouns: she/they
swyld@tucows.com
+1.416 535 0123 Ext. 1392
*From: *Steve Crocker <steve@shinkuro.com> *Sent: *November 17, 2021 7:59 PM *To: *Marika Konings <marika.konings@icann.org> *Cc: *gnso-accuracy-st@icann.org *Subject: *[GNSO-Accuracy-ST] Purposes vs Requirements
Folks,
Attached is a short note on purposes, requirements, etc.
In my view, the work for this scoping group is to:
- List the agreed upon purposes that registration data is supposed to serve. This is presumably just a matter of copying what's been previously decided, but I've heard some contradictory views, one of which is there are no acceptable third party uses of registration data. - Agree on definitions for the various levels of accuracy validation that might be applied to individual data elements.
It will then be up to the PDP WG to set the specific accuracy requirements for individual data elements.
The natural questions along the way are:
- whether the requirements are sufficient to meet the intended purposes, - whether the actual practices achieve the requirements, and - whether discrepancies between requirements and practice are actually detected, and, if so, what remedial actions take place.
See you all on the call tomorrow.
Thanks,
Steve
