October 2021 - GNSO-Accuracy-ST

Re: [GNSO-Accuracy-ST] Alt on Nov 11?
by Michael Palage Oct. 29, 2021

Oct. 29, 2021

Hello Sarah, We did get the green light for alternates and a vice-chair yesterday from the GNSO Council as well as an appointment of a GNSO Liaison. I have been informed that the call for alternates will go out next week. So the RrSG should be able to have an alternative in place by then. Best regards, Michael From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces(a)icann.org> On Behalf Of Sarah Wyld Sent: Friday, October 29, 2021 12:01 PM To: Roger D Carney via GNSO-Accuracy-ST <gnso-accuracy-st(a)icann.org> Subject: [GNSO-Accuracy-ST] Alt on Nov 11? Hi team, I will not be available for our Nov. 11 meeting. I understand that we don’t yet have formal approval to allow Alts in this Scoping Team, so I’d like to know if the group would allow me to assign one or if that’s not yet possible. If it is permitted, then Owen Smigelski will act as my Alt for that meeting. He’s already been observing the team and is up to speed on what’s happening, so he will be well able to contribute meaningfully. Thank you, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they <mailto:swyld@tucows.com> swyld(a)tucows.com +1.416 535 0123 Ext. 1392

1 0

Re: [GNSO-Accuracy-ST] Accuracy definition updates
by Steve Crocker Oct. 29, 2021

Oct. 29, 2021

I'm in agreement with Sarah's wording. The actual application of syntactic validation and operational validation depends on the specific data elements. For example, there's not much that can be done to validate the syntax of the Name or Organization data elements. We will need specific requirements for each data element. Attached is an attempt at capturing the complete set of collection, validation and sensitivity rules. V0 means no validation, V1 means syntactic validation, V2 is operational validation, and V3 is identity validation. The reason for using ranges, e.g. V1..V3, is to allow registrars to use higher levels of validation if they choose to. If we want to preclude them from doing so, it's easy to specify the precise level of validation they must do, though I doubt that's the policy we actually want. The attachment is a draft. Please do comment or ask questions. Thanks, Steve On Fri, Oct 29, 2021 at 12:09 PM Sarah Wyld <swyld(a)tucows.com> wrote: > Hello team, > > Thank you for the opportunity to consider further updates to the working > definition of registration data accuracy. > > We have reviewed Michael’s suggested text and have some notes/questions > (see below); we’re of course happy to discuss but think that the definition > we proposed, including both the bold text sentence and the explanatory > paragraphs following it, with some changes as noted below/taken from your > proposal, is more clear. > > Notes: > > - Technical contact data may not be provided by the Registrant, but > instead by the Account Holder, and accuracy requirements still apply. > > > - We have taken onboard the changes from Michael’s definition as > prompting update of our proposed definition to include the > Account-Holder-provided data > > > - The additional explanatory text (paragraphs below the bold-text > sentence) is important for explaining syntactical and operational accuracy > and should be included in the definition; this helps make the definition > clear and useful without trying to include all the information in the first > sentence. > > > - Also taken onboard the feedback re clarity of operational accuracy > and made adjustments in the relevant text > > > - Is there a singular definition of Registrar Data Directory Services > (RDDS) data elements? We think “registration data elements” is more clear > and directly relates to the RAA and so we’ve stuck to that language here. > > Our updated working definition, based on current contractual and Consensus > Policy requirements, with the updates from Michael’s proposed changes > included: > > *Accuracy shall be strictly defined as syntactical accuracy of the > registration data elements provided by the Registered Name Holder or > Account Holder as well as the operational accuracy of either the telephone > number or the email address.* > > To be determined to be *syntactically accurate*, the contact must satisfy > all requirements for validity (see Whois Accuracy Program Specification > <https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#who…> > Sections 1b-d). For example, for email addresses all characters must be > permissible, the “@” symbol is required, and there must be characters > before the “@” symbol. > > To be determined to be *operably accurate*, the contact must be operable > as defined in the Whois Accuracy Program Specification > <https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#who…> > Section f. The RAA currently requires validation of syntactical accuracy > and verification of operational accuracy including an affirmative response > from the Registered Name Holder for either email or phone. > > > > Thanks, > > > > > > -- > > *Sarah Wyld*, CIPP/E > > > > Policy & Privacy Manager > > Pronouns: she/they > > > > swyld(a)tucows.com > > +1.416 535 0123 Ext. 1392 > > > > > > *From: *Michael Palage <michael(a)palage.com> > *Sent: *October 27, 2021 4:48 PM > *To: *gnso-accuracy-st(a)icann.org > *Subject: *[GNSO-Accuracy-ST] All Aboard !!! > > > > Hello All, > > > > Per my comments yesterday during our open plenary call, I made very clear > that it is my strong desire to have our work complete by ICANN75. In order > for that to happen, there may be times that I will have to gently nudge in > a neutral fashion people to get things done. In advance of our call next > week, I want to tee up a more in-depth discussion of a working accuracy > definition. > > > > Listed below is current definition that the RrSG has extracted from the > RAA: > > > > Accuracy shall be strictly defined as syntactical accuracy of the > registration data elements provided by the Registered Name Holder as well > as the operational accuracy of either the telephone number or the email > address. > > > > Having read all the documents and listened to all of the > comments/discussion I would like to put on the table for > consideration/discussion the following friendly amendment. > > > > Accuracy encompasses both syntactical accuracy and operational accuracy of > Registration Data Directory Service (RDDS) data elements processed by > Registrars. Syntactical accuracy is imposed on all RDDS data elements > processed by Registrars, whereas operational accuracy is only required of > either email or telephone of RDDS data elements. An additional requirement > of operational accuracy is an affirmative response from the recipient to > the confirmation request. > > > > The basis of these friendly amendments are as follows: > > > > - I am proposing the definition to include syntactical and operational > accuracy for ALL data elements that are processes (including voluntary > ones) not just mandated ones. If a registrar is collecting data elements > they should apply the same standard to all elements, both mandatory and > voluntary. > - I do not believe that the operational aspect of the RrSG definition > properly encapsulated the affirmative response component set forth in the > Whois Accuracy Program Specification. > > > > Any thoughts or comments. > > > > If there are any alternative definitions, I ask that they be provided to > the group via the mailing list 24 hours prior to our next call. > > > > Best regards, > > > > Michael > > > > > > > > > > > > > _______________________________________________ > GNSO-Accuracy-ST mailing list > GNSO-Accuracy-ST(a)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.

1 0

All Aboard !!!
by Michael Palage Oct. 29, 2021

Oct. 29, 2021

Hello All, Per my comments yesterday during our open plenary call, I made very clear that it is my strong desire to have our work complete by ICANN75. In order for that to happen, there may be times that I will have to gently nudge in a neutral fashion people to get things done. In advance of our call next week, I want to tee up a more in-depth discussion of a working accuracy definition. Listed below is current definition that the RrSG has extracted from the RAA: Accuracy shall be strictly defined as syntactical accuracy of the registration data elements provided by the Registered Name Holder as well as the operational accuracy of either the telephone number or the email address. Having read all the documents and listened to all of the comments/discussion I would like to put on the table for consideration/discussion the following friendly amendment. Accuracy encompasses both syntactical accuracy and operational accuracy of Registration Data Directory Service (RDDS) data elements processed by Registrars. Syntactical accuracy is imposed on all RDDS data elements processed by Registrars, whereas operational accuracy is only required of either email or telephone of RDDS data elements. An additional requirement of operational accuracy is an affirmative response from the recipient to the confirmation request. The basis of these friendly amendments are as follows: * I am proposing the definition to include syntactical and operational accuracy for ALL data elements that are processes (including voluntary ones) not just mandated ones. If a registrar is collecting data elements they should apply the same standard to all elements, both mandatory and voluntary. * I do not believe that the operational aspect of the RrSG definition properly encapsulated the affirmative response component set forth in the Whois Accuracy Program Specification. Any thoughts or comments. If there are any alternative definitions, I ask that they be provided to the group via the mailing list 24 hours prior to our next call. Best regards, Michael

3 3

Alt on Nov 11?
by Sarah Wyld Oct. 29, 2021

Oct. 29, 2021

Hi team, I will not be available for our Nov. 11 meeting. I understand that we don’t yet have formal approval to allow Alts in this Scoping Team, so I’d like to know if the group would allow me to assign one or if that’s not yet possible. If it is permitted, then Owen Smigelski will act as my Alt for that meeting. He’s already been observing the team and is up to speed on what’s happening, so he will be well able to contribute meaningfully. Thank you, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld(a)tucows.com +1.416 535 0123 Ext. 1392

1 0

Alt on Nov 11?
by Sarah Wyld Oct. 29, 2021

Oct. 29, 2021

Hi team, I will not be available for our Nov. 11 meeting. I understand that we don’t yet have formal approval to allow Alts in this Scoping Team, so I’d like to know if the group would allow me to assign one or if that’s not yet possible. If it is permitted, then Owen Smigelski will act as my Alt for that meeting. He’s already been observing the team and is up to speed on what’s happening, so he will be well able to contribute meaningfully. Thank you, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld(a)tucows.com +1.416 535 0123 Ext. 1392

1 0

Proposed agenda and documents for ICANN72 meeting on Tuesday 26 October at 17.30 UTC
by Marika Konings Oct. 28, 2021

Oct. 28, 2021

Dear All, As a reminder, the Registration Data Accuracy Scoping Team will meet at ICANN72 on Tuesday 26 October at 17.30 UTC (see https://72.schedule.icann.org/meetings/LfJ22fzQsPhhFMPDD for further details). The proposed agenda for this meeting is as follows: 1. Welcome & Introduction 2. High level overview of workplan 3. Open microphone 4. Confirm action items & next meeting (Thursday 4 November at 13.00 UTC) For agenda item #2, we’ll be using the attached working draft. We’ll be sharing a live version during the session, but for your convenience you may also want to have the attached version handy so it may be easier to view. In addition, the slides that will be used for this session have been posted on the wiki page: https://community.icann.org/x/WAZyCg. Best regards, Caitlin, Berry and Marika

3 2

Further information added to Index of Relevant Resources
by Marika Konings Oct. 27, 2021

Oct. 27, 2021

Dear All, Thanks to Stephanie, we have added to the Index of Relevant resources (see https://docs.google.com/document/d/1oxVNpCU5YjkHDnxsbA7NZPs6cCVc6vU_/edit) the responses that ICANN Compliance provided to the RDS-WHOIS2 RT in response to accuracy related questions. This information can be found on page 11 of the google doc. The RDS-WHOIS2 RT wiki page also provides links to a number of webinars that were conducted on ARS for each of the reports published from 2015-2017, see https://community.icann.org/x/6plEB. Please review this information as you consider further questions that you would like to see put forward to ICANN org. As a reminder, the following google doc is available to enter your proposed questions: https://docs.google.com/document/d/1arlKdQkbRkE1LuurmDdd-PZP184_AdFm/edit. Best regards, Caitlin, Berry and Marika

1 0

Identity Proofing Clarity - Follow Up Homework
by Michael Palage Oct. 22, 2021

Oct. 22, 2021

Hello All, I was reviewing my notes from yesterday's meeting as well as reviewing some of the previous email list exchanges between and I was hoping that my Registrar colleagues could provide a little clarity, especially Volker given his participation in the 2013 RAA negotiations. I believe what I have heard and read from my Registrar colleagues is that there is no "identity proofing" requirements in their contracts - accuracy is merely syntactical and operational. I apologizes in advance if I am mischaracterizing this and welcome any corrections. However, in Assignment #1, the follow excerpt from ICANN Organization Enforcement of Registration Data Accuracy Obligations Before and After GDPR states: [I]f the complaint is about identity (e.g., the registrant is not who they say they are), Contractual Compliance may ask the registrar to provide further information concerning their findings and the results of their investigation specific to the facts of the complaint. So it appears based on this excerpt that ICANN Contractual Compliance does reserve some right to inquiry about the "identity" of the Registrant. Therefore, I believe potential clarifying questions to ICANN Org could might include: does ICANN Compliance believe that it has the ability to inquiry about the "identity" of a registrant? If so, what is the contractual basis of this authority. Finally, what are the numbers associated with these types of inquiries, e.g. percentage of overall accuracy complaints and raw numbers. Thoughts? Comments? Best regards, Michael

6 7

Notes and action items - RDA Scoping Team Meeting #3 - 21 Oct 2021
by Caitlin Tubergen Oct. 21, 2021

Oct. 21, 2021

Dear Scoping Team Members, Below, please find the notes and action items from today’s meeting. Our next meeting will be during ICANN72 on Tuesday, 26 October from 19.30 – 21.00 UTC. Best regards, Marika, Berry, and Caitlin Action Items 1. Policy Support Staff to set up email list similar to SSAD ODP mailing list, which can be used by non-members to submit suggestions regarding accuracy. (Note: the mailing list will be test for one month. At the conclusion of one month, Leadership will choose to retain or discontinue the mailing list based on use.) 2. Michael to notify GNSO Council that the Scoping Team plans to allow alternates to participate in the Scoping Team. The use of alternates will be similar to how other GNSO efforts have used alternates; in other words, alternates would be available to step in if a member is unavailable. 3. Reminder that all Scoping Team members are requested to comprehensively review the briefing materials, and, if questions to ICANN org arise after having read the materials, Scoping Team members to populate questions into the dedicated Google Doc<https://docs.google.com/document/d/1lRiuyCMg2lxkMDJEuAroUht_pgv2Nw9e/edit>. Following receipt of questions, Leadership will determine if a briefing is warranted. 4. Scoping Team members to review new input provided in Assignments #1 - #2 and consider how this needs to be translated into a work plan and timeline by COB Monday, 25 October Registration Data Accuracy Scoping Team – Meeting #3 Thursday 21 October at 13.00 UTC 1. Welcome & Chair Updates (10 minutes) * Miscellaneous administrative issues * With respect to the email list for third parties, we will set up the email address (similar to the SSAD ODP email list), and we will try it for one month. If it proves successful, we will keep it; if not, we will terminate the email address. * Action: ICANN Support Staff to set up email list for third parties. * With respect to the use of alternates, the charter does not foresee the use of alternates but it does allow for additional expertise. It may be worth notifying the GNSO Council of the proposed use of alternates as this was not specifically foreseen. There is, however, some flexibility in the Council instructions. This could work in the same way that alternates work in other settings; in other words, alternates would step in for members when members are not available. * Michael to notify GNSO Council of Scoping Team’s proposed use of alternates. * ICANN72 session – Tuesday 26 October (19.30 – 21.00 UTC). Proposed agenda: · Welcome & Introduction · High level overview of workplan · Open microphone · Confirm action items & next meeting (Thursday 4 November at 13.00 UTC) * Many members will be available for this session * No objections to the proposed agenda for the ICANN session * There have been some questions about Google Docs; Support Staff will review determine if there is an instructional video on how to use Google Docs * It works very similarly to other word processing tools; however, contributors can include comments, but cannot delete others’ comments * One issue members have is locating links to the documents * Some members are having issues getting to the google drive via email * Note: please find additional helpful links here: https://community.icann.org/display/AST/Google+folder 1. Background briefing assignment #2 – see https://docs.google.c‌om/document/d/1OyzzAjZgvNkfZ5EekUvJ7PQg80vNZvJ3/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1OyzzAjZgvNkf…> * Review assignment #2 * Staff Support team collected information on how accuracy levels have been measured so that the group could consider the questions below * There is now input from both the RrSG and IPC * Note: background briefing #1 includes the proposed working definition of accuracy from the RrSG in this briefing * Consider questions and team input received: · What information, if any, is missing to support the team’s deliberations on whether ARS needs a revamp or whether there are other ways in which accuracy levels can/should be measured? * IPC: The question, as worded, is confusing. A better question may be - how do we restart ARS in a GDPR-compliant world? For example, how does the ARS function? Did ARS scrape WHOIS? If so, that will not work anymore, and the group can consider how to make it function. * There may be value in reviewing publicly-available registration data – it would show that there is redacted data (due to data protection law) but also show that some data is not redacted and could be checked for syntactical accuracy * There are some problems in the ARS that are not obvious from the data, including time delays. It may be helpful to receive a briefing from ICANN org re: how the ARS worked. * Question: would it be possible to reach out to relevant staff in ICANN org re: the gaps that are present in the publicly available data? * Action: Alan G. to synthesize questions to ICANN org in the Google Doc, and Brian G. will relay these questions to ICANN org. * Some of the questions IPC is asking are contained in the background documents. Action: As part of the team’s homework, comprehensively review all background information, and if there are follow-up questions, please reflect the questions in the Google Doc. * The following communication is helpful in understanding the current status: https://www.icann.org/en/system/files/correspondence/swinehart-to-fouquart-…. * Documents are helpful, but believe it would be well worth the group’s time to receive a briefing from ICANN org. ARS could be run today – all domains today have a public Whois response; it’s just that some data is redacted that wasn’t previously. That, in ICANN org’s mind, skews the results. * Before requesting a briefing, please document questions for ICANN org. The other concern being articulated is – can the ARS be done in the current climate? * There is so much material and unlike other stakeholders who have had to review these documents because of contractual requirements, other stakeholders are not as familiar with these documents. The IPC responses endeavor to go to the heart of the matter. What kind of data is available, and what is possible in a GDPR compliant world? * There is a lack of understanding of what the ARS is, and what the current status is. A lot of the documents include many footnotes that link to many other pages, and not all have the stamina to review all of these documents and links. This is why a briefing has been suggested. * The index of relevant resources is the long list of documents in ICANN’s history. The list is long, but it provides helpful context. The background briefing documents pinpoint the most relevant excerpts from documents – such as excerpts regarding ARS, for assignment 2. * The Whois Accuracy Specification is being characterized as optional or discretionary, and that is incorrect. The Whois Accuracy Specification is mandatory. * There is some confusion around data that is collected and data that is disclosed. The data that is collected must be accurate whether it is disclosed or not. There is ambiguity that came out of the dialogue yesterday – there is a minimum level of validation on the data, but registrars may choose to apply a higher level of discretionary validation. The policy question is – should this become mandatory across all registrars. * Footnote 9 alludes to the problem of ARS even when it was in operation. If there is no ARS, but data is still being collected, how is accuracy being tested? * With respect to registrars choosing to impose a higher level of validation, that would be the registrar’s business decision. That is not relevant to this discussion. It may be helpful to review the accuracy requirements under the Whois Accuracy Specification. * What the registrars put forward is not a proposed definition of accuracy; this is the detail of what the working definition is today based on the RAA. * If the registrar validated the email but not the phone number, that is sufficient. Allowing registrars to check either one, but not necessarily give you both is a problem. * If you drill down the Whois Accuracy Program Specification Section f, the language seems to suggest a higher level of validation than just an operable email of phone number. * “In either case, if Registrar does not receive an affirmative response from the Registered Name Holder, Registrar shall either verify the applicable contact information manually or suspend the registration, until such time as Registrar has verified the applicable contact information. If Registrar does not receive an affirmative response from the Account Holder, Registrar shall verify the applicable contact information manually, but is not required to suspend any registration.” – this seems to suggest a higher level of accuracy. * Have a different understanding of this higher level of accuracy. Why are the current requirements not suitable? Accuracy is not the same thing as access to the data. The controller determines the accuracy. The ability for a person to look up data on the internet is not the same as accuracy. In terms of higher level of validation, important to not conflate the registered name holder and the account holder. Instead of using an automated email, it could mean that someone from customer service calls or emails rather than an automated system – this has never been interpreted as an ID check. * ICANN had the opinion that failure to verify would result in suspension; this language was added by request of registrars. With this option, registrars can reach out to important customers and avoid the automatic de-activation. * Qualitative review of data is outside the scope of what ICANN needs to do; it may be something registrars want to do, but should not be required by ICANN * Does this baseline definition seem correct to everyone? * The working assumption is that this is the definition today and the scoping team is reviewing what needs to be changed (if anything). * There is a notion of improving accuracy in ICANN’s bylaws; this is important to consider as continue to discuss this definition. * If there are problems, how can this be investigated? If there is agreement that the definition of today is not where it should be, how can the community get to where it should be? · What approach should the team take to develop these recommendations? · How much time and resources are expected to be needed to either revamp ARS or implement other ways in which accuracy levels can/should be measured? * Confirm next steps 1. Background briefing assignment #3 – see https://docs.google.com/document/‌d/1NiwMk6qHOQRn7VdcW0Paj5OoC3tWAQpm/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1NiwMk6qHOQRn…> * Review assignment #3 * Work needs to be completed on assignments 1 and 2 before work can be considered on 3 * This is broken down in two pieces – Part 2 looks at the analysis of the accuracy levels measured to see if the contractual requirements are effective. * Consider questions and team input received: · What is necessary to undertake such an analysis? · What is the definition of “effective”? · How are “accurate and reliable” to be interpreted (see also assignment #1 re. working definitions)? * What next steps and approach should the team take to address this assignment? * Confirm next steps 1. Background briefing assignment #4 - see https://docs.google.com/document/d/1Z8t-uH4gRqXytHOGnIkZ2qMSJctgR_kD/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1Z8t-uH4gRqXy…> * Review assignment #4 * Assignment #4 is the conclusion of the group’s work and focused on impacts and improvements. * If changes are recommended to existing contractual requirements, a PDP or contractual negotiation is necessary to implement the changes. * There is currently no input or comments yet. * As the group works through 1 and 2, the answers to 3 and 4 may change. For example, a survey or study may change, so it may have to be readministered. * It may be a stretch to do anything on 4 at this time. Similarly, the group can discuss 3 but it may not be possible to do anything on 3 at this time. * With respect to the work plan, this is not a PDP, but it is still a group that is beholden to the GNSO Council. At some point, this group owes the Council a work plan or target date for when the work will be completed. It’s important for the group to review all of the assignments so that the work can be properly scoped – can the assignments be worked on in parallel, or is it iterative? The group needs to think about these key aspects that the group thinks must be included as part of the deliberations. The group needs to come up with a reasonable date and work towards it diligently. This has been decided by the community as an important topic to be discussed; accordingly, there has to be some sense of urgency to work that is assigned for homework and productivity in plenary calls. * Consider questions and team input received: · When & how are estimates of benefits and costs expected to be developed? · In addition to outcome of assignment #1-3 and cost/benefit analysis, is there anything further that is needed for the scoping team to deliberate on whether any changes are needed to improve accuracy levels? · Based on response to previous question, what are the options the team can consider for how and by whom these changes would need to be developed? * What next steps and approach should the team take to address this assignment? * Confirm next steps 1. Confirm action items & next meeting (ICANN72 session on Tuesday 26 October at 19.30 UTC)

1 0

Registration Data Accuracy Scoping Team | Thursday, 21 October 2021
by Terri Agnew Oct. 21, 2021

Oct. 21, 2021

Dear all, All recordings for the Registration Data Accuracy Scoping Team held on Thursday, 21 October 2021 can be found on the agenda wiki page <https://community.icann.org/x/Kg2HCg> (attendance included) and the GNSO Master Calendar [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-accuracy-st/> and the main wiki page<https://community.icann.org/x/hQIuCg>. Thank you! Kind Regards, Terri

1 0