- GNSO-Accuracy-ST - lists.icann.org

Meeting invitation | Registration Data Accuracy Scoping Team | Thursday, 31 March 2022 at 14:00 UTC
by Terri Agnew March 24, 2022

March 24, 2022

Dear all, The Registration Data Accuracy Scoping Team meeting is scheduled on Thursday, 31 March 2022 at 14:00 UTC for 90 minutes. Please click the link below to join the webinar: https://icann.zoom.us/j/94504686990?pwd=MWc2eXZENk9yN0RqOUUzaGx2eGV0QT09<https://urldefense.com/v3/__https:/icann.zoom.us/j/94504686990?pwd=MWc2eXZE…> Passcode: Vc#0B7$pu8 For Audio only: Or One tap mobile : US: +13017158592,,94504686990#,,,,*4631547480# or +13126266799,,94504686990#,,,,*4631547480# Webinar ID: 945 0468 6990 Passcode: 4631547480 International numbers available: https://icann.zoom.us/u/akRu7JTFd <https://urldefense.com/v3/__https:/icann.zoom.us/u/akRu7JTFd__;!!PtGJab4!pY…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, alternates and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/7hQiCw * Check your time zone: https://tinyurl.com/mr2usskt ONLY for Members and Alternates * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form <https://urldefense.com/v3/__https:/forms.gle/GZqMAi4kKDaVP5o66__;!!PtGJab4!…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the Team is aware at any time who is active. Alternate Assignment –wiki page<https://community.icann.org/x/-wC7Cg>. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Terri

1 0

**Starting in 15 minutes | Meeting invitation | Registration Data Accuracy Scoping Team | Thursday, 24 March 2022 at 14:00 UTC
by Terri Agnew March 24, 2022

March 24, 2022

***Starting in 15 minutes Dear all, The Registration Data Accuracy Scoping Team meeting is scheduled on Thursday, 24 March 2022 at 14:00 UTC for 90 minutes. Please click the link below to join the webinar: https://icann.zoom.us/j/94504686990?pwd=MWc2eXZENk9yN0RqOUUzaGx2eGV0QT09<https://urldefense.com/v3/__https:/icann.zoom.us/j/94504686990?pwd=MWc2eXZE…> Passcode: Vc#0B7$pu8 For Audio only: Or One tap mobile : US: +13017158592,,94504686990#,,,,*4631547480# or +13126266799,,94504686990#,,,,*4631547480# Webinar ID: 945 0468 6990 Passcode: 4631547480 International numbers available: https://icann.zoom.us/u/akRu7JTFd <https://urldefense.com/v3/__https:/icann.zoom.us/u/akRu7JTFd__;!!PtGJab4!pY…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, alternates and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/6xQiCw * Check your time zone: https://tinyurl.com/33fptavv [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/33fptavv__;!!PtGJab4!qZgMCkV…> ONLY for Members and Alternates * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form <https://urldefense.com/v3/__https:/forms.gle/GZqMAi4kKDaVP5o66__;!!PtGJab4!…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the Team is aware at any time who is active. Alternate Assignment –wiki page<https://community.icann.org/x/-wC7Cg>. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Terri

1 0

**REMINDER** Meeting invitation | Registration Data Accuracy Scoping Team | Thursday, 24 March 2022 at 14:00 UTC
by Julie Bisland March 23, 2022

March 23, 2022

Dear all, The Registration Data Accuracy Scoping Team meeting is scheduled on Thursday, 24 March 2022 at 14:00 UTC for 90 minutes. Please click the link below to join the webinar: https://icann.zoom.us/j/94504686990?pwd=MWc2eXZENk9yN0RqOUUzaGx2eGV0QT09<https://urldefense.com/v3/__https:/icann.zoom.us/j/94504686990?pwd=MWc2eXZE…> Passcode: Vc#0B7$pu8 For Audio only: Or One tap mobile : US: +13017158592,,94504686990#,,,,*4631547480# or +13126266799,,94504686990#,,,,*4631547480# Webinar ID: 945 0468 6990 Passcode: 4631547480 International numbers available: https://icann.zoom.us/u/akRu7JTFd <https://urldefense.com/v3/__https:/icann.zoom.us/u/akRu7JTFd__;!!PtGJab4!pY…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, alternates and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/6xQiCw * Check your time zone: https://tinyurl.com/33fptavv [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/33fptavv__;!!PtGJab4!qZgMCkV…> ONLY for Members and Alternates * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form <https://urldefense.com/v3/__https:/forms.gle/GZqMAi4kKDaVP5o66__;!!PtGJab4!…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the Team is aware at any time who is active. Alternate Assignment –wiki page<https://community.icann.org/x/-wC7Cg>. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Terri

1 0

Proposed Agenda - Registration Data Accuracy Scoping Team meeting #22 on Thursday 24 March at 14.00 UTC
by Marika Konings March 23, 2022

March 23, 2022

Dear All, Please find below the proposed agenda for the next Registration Data Accuracy Scoping Team meeting which has been scheduled for Thursday 24 March at 14.00 UTC. As a reminder: 1. RDA Scoping Team members to suggest further edits to the current accuracy description, based on the discussion from Thursday’s meeting, including, for example, updated language regarding Spec. 13: https://docs.google.com/document/d/1e5rUm-AFFDgNOU3OcT7ABu4InGwPiUyb/edit by Wednesday, 23 March. 2. Still open: In advance of the next meeting on Thursday, 24 March, RDA Scoping Team Members to review the Gap Analysis Proposal Review. Note: this document was compiled by Support Staff in an effort to distill the proposals made by Scoping Team Members, including upsides and downsides noted by either the proposer or other team members in subsequent discussions. The document is not meant to restrict the group into choosing one proposal, but rather, the group should review all proposals and see which proposals provide a viable path to forward progress. Note: IPC Reps: please respond to the comments directed to you in Proposal H. https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit) Best regards, Caitlin, Berry and Marika Registration Data Accuracy Scoping Team – Meeting #22 Thursday 24 March at 14.00 UTC 1. Welcome & Chair Updates (5 minutes) 1. Accuracy working definition / construct (30 minutes) * Consider input received on proposed description of current accuracy requirements and enforcement (see https://docs.google.com/document/d/1e5rUm-AFFDgNOU3OcT7ABu4InGwPiUyb/edit) * Review survey responses – see https://docs.google.com/forms/d/e/1FAIpQLSdL-R4Tk7pP86bMIRMX1tH1IA9-UgbHFYV… * Confirm next steps 3. Continue review of Gap Analysis Data Collection Proposals (30 minutes) (see https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit) a. Review Scoping Team input on proposals (upside, downside and possible next steps) b. Confirm next steps 1. Confirm action items & next meeting (Thursday 31 March at 14.00 UTC)

2 1

Notes and action items: RDA Scoping Team Meeting #21 - 17 March 2022
by Caitlin Tubergen March 17, 2022

March 17, 2022

Dear RDA Scoping Team Members, Please find below the notes and action items from today’s meeting. As a reminder, the next meeting will be Thursday, 24 March at 14:00 UTC. Best regards, Marika, Berry, and Caitlin -- Action Items 1. Brian Gutterman (ICANN org liaison) to transmit questions 3 - 7 (https://docs.google.com/document/d/1arlKdQkbRkE1LuurmDdd-PZP184_AdFm/edit?p…) to internal ICANN org colleagues for further guidance. 2. Support Staff to provide further information on where the RDS WHOIS-2 Review Team recommendations listed in the Data Analysis Proposals (e.g., R 4.2, R 5.1, LE.1, CC.1) stand. (https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit) 3. RDA Scoping Team members to suggest further edits to the current accuracy description, based on the discussion from today's meeting, including, for example, updated language regarding Spec. 13: https://docs.google.com/document/d/1e5rUm-AFFDgNOU3OcT7ABu4InGwPiUyb/edit by Wednesday, 23 March. 4. Still open: In advance of the next meeting on Thursday, 24 March, RDA Scoping Team Members to review the Gap Analysis Proposal Review. Note: this document was compiled by Support Staff in an effort to distill the proposals made by Scoping Team Members, including upsides and downsides noted by either the proposer or other team members in subsequent discussions. The document is not meant to restrict the group into choosing one proposal, but rather, the group should review all proposals and see which proposals provide a viable path to forward progress. Note: IPC Reps: please respond to the comments directed to you in Proposal H. (https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit) -------- Registration Data Accuracy Scoping Team – Meeting #21 Thursday 17 March at 14.00 UTC 1. Welcome & Chair Updates (10 minutes) * Brief recap from ICANN73 session [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/rec/share/05G-ap9lx75HHcPz…> – see also https://mm.icann.org/pipermail/gnso-accuracy-st/2022-March/000336.html * Becky Burr, board liaison, shared information about ICANN org reaching out to the EDPB to gain clarity on what data could be processed in conjunction with accuracy * There will be a variety of scenarios that will most likely be shared with this group; however, one consideration is how this can be done without prolonging the process. If scoping team members have specific scenarios in mind, they can consider proactively sharing them. An example of a scenario: ICANN engages an independent third-party analyst who has access to the full dataset to see what kind of inaccuracies are present in the dataset and how prevalent these issues are. Another scenario could be that ICANN org conducts this study using the ARS or something similar. Another scenario: ICANN engages a professional statistician to understand what portion of the data set would need to be analyzed to get meaningful numbers. * Is the Board going to be involved in this, or is this done through ICANN org? Specifically, should scenarios and questions be funneled through the board liaison or the org liaison? * The group is welcome to come up with scenarios and send them to org liaison * Two different questions: with regard to accuracy, some fraction of the people who need the data need high levels of assurance of the data – how will that be taken into account with accuracy? Second question – GDPR is only one privacy regime among a growing number of privacy regimes. Is the inquiry structured in a way that considers the existing regulations or also other privacy regimes? * Can ICANN do a proactive ARS rather than a reactive ARS – always helpful to start with the data and getting the baseline of what can we look at and when will benefit from this. 1. Accuracy working definition / construct (30 minutes) * See staff support team proposal (see https://mm.icann.org/pipermail/gnso-accuracy-st/2022-March/000354.html) * This was circulated earlier in the week, and has one minor redline proposed by Lori * Support staff looked at the input provided by the Rrs, ICANN Compliance, and the subsequent discussions that flowed therefrom. This definition is about what current requirements and enforcement looks like so that everyone is clear what that means in practice. This does not preclude changes to the requirements or enforcement in the future – this is about describing the here and now. * With respect to the last paragraph (beginning with furthermore) – the call out to specific registry operators is concerning to registries. The specific contractual language is set out in the base registry agreement in section 2.19. Also disagree that .brand Spec 13 operators count as verified TLDs – Spec 13 operates to restrict eligibility and restricts how many registrars can be used by an RO and it’s not about making these names available to others. It’s about having an internal resource. In terms of measurement, how can we determine how to measure based on this definition? We are looking at saying something is accurate – but accurate compared to what? These are really the standard against which we judge accuracy – this is what it means for a data element to be accurate against a certain standard. * Each year, ROs need to make certain certifications to ICANN – the RO, its affiliates, or trademark licensees. If trademark licensees are permitted to register under Spec 13, it’s more than an internal registration in the company. * The latitude that is implied in checking either the email or telephone number – it needs to be clear to the requestor which data element was verified – in other words, if the phone number is verified, the phone number needs to be provided (rather than the unverified email) * In talking about accuracy, it is not sufficient to only discuss syntactical and operational accuracy. According to Compliance, this group has heard that accuracy is not limited to syntactical and operational accuracy – identity could be “patently inaccurate”. * In Spec 13, there can’t be registrations done by licensees for the primary purpose – this should be looked at as different categories. Recommend looking at Spec 3 that mentions the different niche verification requirements * Hoping this write-up gets to closing out Assignment 1. Suggest taking this one step further. Take this text and put it in a response to the GNSO Council on Assignment #1. * Support Staff has already been working on a write-up on assignments 1 and 2, which will obviously be updated. Regarding a previous point, there is no current requirement regarding noting which field was verified – that could be an identified gap, but it is not a current requirement. There is also a note about when further checks are applied – as provided by compliance. Regarding the last paragraph, if there are certain contractional provisions that should be added, please provide examples to Support Staff. * In most cases, it’s not a check of accuracy, it is a check of eligibility. It does not matter if the data is accurate, it is whether the registrant is eligible for a Spec 13 registration. * Support removing last paragraph entirely or accepting edits from Rys. Rr needs to keep logs of how the verification was completed, but this does not need to be disclosed to a third party. Processes which arise after an inaccuracy is identified is not properly within the definition of accuracy. It is also difficult to respond to comments that do not propose concrete changes. * This may be helpful to consider in the policy discussion: When storing the data for the first time, the person responsible must check with the usual care whether there are any arguments against the correctness of the data collected. If inaccuracies become known later, the data must be corrected. If there are indications of inaccuracy, the person responsible must not turn a blind eye but must investigate them. In addition, Art. 5 Para. 1 lit. d GDPR (and Art. 4 Para. 1 lit takes notice. – think it will be helpful to further study the legal literature on this topic * If staff proposal is not supported under a), review input received (seehttps://docs.google.com/document/d/1JGdNLjOjhmJnj-iDaGvcVnv1gZ5tQu5C/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1JGdNLjOjhmJn…>) * Review survey responses (see https://docs.google.com/forms/d/e/1FAIpQLSdL-R4Tk7pP86bMIRMX1tH1IA9-UgbHFYV… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLSdL-R4T…>) * Confirm next steps 3. Continue review of Gap Analysis Data Collection Proposals (30 minutes)(see https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1sScP8MwgDCg4…>) a. Review Scoping Team input on proposals (upside, downside and possible next steps) * As a reminder, there were proposals made as part of a gap analysis – in terms of how informative data could be gathered – upsides and downsides were also added * Also, the discussion from ICANN73 was added to this document. * Is more time needed to review what is here, or, alternatively, is the group ready to discuss next steps and how to move forward on these? * Made a reference to implemented RDS review team recommendations – it was requested that the specific recommendations be included. For background, the recommendations from RDS review team would have provided helpful data had these recommendations be implemented – even after the GDPR went into effect. * The CC1 recommendation refers to the GNSO Council, and the Council still has it on its list to consider – it may be helpful to see where all of these recommendations stand. * Would be helpful to hear from groups other than registrars on the survey – if it’s ultimately just registrars asking themselves a handful of questions – it may not be beneficial – would be helpful to hear from other groups. * There are other questions not listed here – such as many registrars are obliged to verify email or telephone numbers, but some registrars verify both – it would be helpful to know this. Also, could ask questions about tracking bounced emails. The survey has merit; the real question is will we receive answers from a significant number of registrars. * There seems to be a concern about registrars not doing what they’re supposed to. * Because the accuracy spec makes reference to a bounce being a reason to recheck, other registrars have said that bounce tracking is difficult and they do not do it. * There is a difference b/w an email bouncing as part of a WDRP notice and a bouncing notification from a requestor b. Confirm next steps 1. Additional questions for ICANN Compliance (20 minutes) (see https://docs.google.com/document/d/1arlKdQkbRkE1LuurmDdd-PZP184_AdFm/edit?p… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1arlKdQkbRkE1…>) * Introduce questions (Alan, Michael) * Are any of the questions concerning or confusing to the team? * ICANN org liaison can take questions 3-7 back to ICANN org colleagues for a response * EPDP Team input * Confirm next steps 1. Confirm action items & next meeting (Thursday 24 March at 14.00 UTC)

1 0

Registration Data Accuracy Scoping Team | Thursday, 17 March 2022
by Terri Agnew March 17, 2022

March 17, 2022

Dear all, All recordings for the Registration Data Accuracy Scoping Team held on Thursday, 17 March 2022 can be found on the agenda wiki page <https://community.icann.org/x/6RQiCw> (attendance included) and the GNSO Master Calendar <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

Meeting invitation | Registration Data Accuracy Scoping Team | Thursday, 24 March 2022 at 14:00 UTC
by Terri Agnew March 17, 2022

March 17, 2022

Dear all, The Registration Data Accuracy Scoping Team meeting is scheduled on Thursday, 24 March 2022 at 14:00 UTC for 90 minutes. Please click the link below to join the webinar: https://icann.zoom.us/j/94504686990?pwd=MWc2eXZENk9yN0RqOUUzaGx2eGV0QT09<https://urldefense.com/v3/__https:/icann.zoom.us/j/94504686990?pwd=MWc2eXZE…> Passcode: Vc#0B7$pu8 For Audio only: Or One tap mobile : US: +13017158592,,94504686990#,,,,*4631547480# or +13126266799,,94504686990#,,,,*4631547480# Webinar ID: 945 0468 6990 Passcode: 4631547480 International numbers available: https://icann.zoom.us/u/akRu7JTFd <https://urldefense.com/v3/__https:/icann.zoom.us/u/akRu7JTFd__;!!PtGJab4!pY…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, alternates and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/6xQiCw * Check your time zone: https://tinyurl.com/33fptavv ONLY for Members and Alternates * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form <https://urldefense.com/v3/__https:/forms.gle/GZqMAi4kKDaVP5o66__;!!PtGJab4!…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the Team is aware at any time who is active. Alternate Assignment –wiki page<https://community.icann.org/x/-wC7Cg>. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Terri

1 0

**starts in 15 minutes | Meeting invitation | Registration Data Accuracy Scoping Team | Thursday, 17 March 2022 at 14:00 UTC
by Terri Agnew March 17, 2022

March 17, 2022

**Starting in 15 minutes Dear all, The Registration Data Accuracy Scoping Team meeting is scheduled on Thursday, 17 March 2022 at 14:00 UTC for 90 minutes. Please click the link below to join the webinar: https://icann.zoom.us/j/94504686990?pwd=MWc2eXZENk9yN0RqOUUzaGx2eGV0QT09<https://urldefense.com/v3/__https:/icann.zoom.us/j/94504686990?pwd=MWc2eXZE…> Passcode: Vc#0B7$pu8 For Audio only: Or One tap mobile : US: +13017158592,,94504686990#,,,,*4631547480# or +13126266799,,94504686990#,,,,*4631547480# Webinar ID: 945 0468 6990 Passcode: 4631547480 International numbers available: https://icann.zoom.us/u/akRu7JTFd <https://urldefense.com/v3/__https:/icann.zoom.us/u/akRu7JTFd__;!!PtGJab4!pY…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, alternates and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/6RQiCw * Check your time zone: https://tinyurl.com/3sse849u <https://urldefense.com/v3/__https:/tinyurl.com/3sse849u__;!!PtGJab4!tGngcAI…> ONLY for Members and Alternates * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form <https://urldefense.com/v3/__https:/forms.gle/GZqMAi4kKDaVP5o66__;!!PtGJab4!…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the Team is aware at any time who is active. Alternate Assignment –wiki page<https://community.icann.org/x/-wC7Cg>. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Terri

1 0

Description of current accuracy requirements and enforcements - staff support team suggestion
by Marika Konings March 16, 2022

March 16, 2022

Dear All, Based on the discussions to date, the staff support team would like to put forward a suggestion in the hope that this conversation around the ‘working definition’ can be considered complete for now so that the group can focus on other pertinent issues. As we have explained previously, our understanding of the reference to a ‘working definition’ as part of assignment #1 was to ensure that whenever there would be a reference to ‘accuracy requirements’, there would be a common understanding of what these entail today. That does NOT preclude future discussion and/or consideration of what these should be, but that conversation needs to be informed by the findings of assignment #1 and #2. As such, we would like to propose the following: Instead of using the term ‘working definition’ which has led to confusion, the Accuracy Scoping Team instead confirms that the following is its understanding of CURRENT accuracy requirements and enforcements. This understanding does not preclude in any way possible changes to these requirements and enforcement in the future based on the work of the scoping team and/or subsequent efforts. Accuracy under the current requirements, as spelled out in the Registrar Accreditation Agreement (RAA) as well as Consensus Policies, is understood as syntactic 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 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 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. In addition, upon notification of an alleged inaccuracy or if the Registrar learns of inaccurate contact information, the Registrar must take reasonable steps to investigate that claimed inaccuracy and correct inaccuracy. Additional verification procedures apply if the registrar has any information suggesting that contact information is incorrect. If a Registered Name Holder willfully provides inaccurate or unreliable registration data information, the registrar will take additional action to terminate, suspend or place a registration on hold. Furthermore, in addition to the requirements in the RAA and Consensus Policies, a number of Registry Agreements also contain some specific requirements in relation to accuracy that apply to that specific TLD, such as, for example, .AERO, .BANK or any spec 13 Registry operator (see for further details https://newgtlds.icann.org/en/applicants/agb/base-agreement-contracting/spe…) Again, agreeing on this description of what is currently required and enforced, does not preclude a conversation about what the different parties think it should evolve to (or not) based on data that is gathered as part of assignment #2, but that conversation needs to be informed by that data in order to be productive. We hope this is helpful. We look forward to receiving your feedback. Caitlin, Berry and Marika

3 2

Re: [GNSO-Accuracy-ST] Level Setting
by Michael Palage March 16, 2022

March 16, 2022

Hello Sarah, I was listening to the first 45 minutes of the Phase 2 Small Team call this morning and you made an interesting point about Registrars doing their own verification of Requestors, and not necessarily relying on the authentication of a third party as envisioned by SSAD. I just had a couple of follow-up questions which I think would be enlightening to the work we are doing here in this Working Group. 1. Can you confirm the scope/number of registrars that you have spoken with that do not intend to rely upon any third party authentication, but will instead rely upon their own internal verification/authentication? 2. Could you please shed any light on the validation that TUCOWS does in connection with TACO requestors. Specifically does TUCOWS have a heightened verification / authentication / accuracy check for requestors, or is it using the same guidelines as set forth in the 2013 RAA. My apologizes in advance if this question got answered in the last 45 min of the call. Best regards, Michael From: Sarah Wyld <swyld(a)tucows.com> Sent: Wednesday, March 16, 2022 8:18 AM To: Alan Greenberg <alan.greenberg(a)mcgill.ca>; Volker Greimann <volker.greimann(a)centralnic.com>; Michael Palage <michael(a)palage.com> Cc: Roger D Carney via GNSO-Accuracy-ST <gnso-accuracy-st(a)icann.org> Subject: RE: [GNSO-Accuracy-ST] Level Setting Hi all, Alan – yes, wouldn’t the registrant (data subject) be the authority on whether the data is accurate? And so the registrar must update (rectify) the registration data as soon as the registrant informs them of the inaccuracy. -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they <mailto:swyld@tucows.com> swyld(a)tucows.com From: Alan Greenberg <mailto:alan.greenberg@mcgill.ca> Sent: March 15, 2022 11:21 PM To: Volker Greimann <mailto:volker.greimann@centralnic.com> ; Michael Palage <mailto:michael@palage.com> Cc: Roger D Carney via GNSO-Accuracy-ST <mailto:gnso-accuracy-st@icann.org> Subject: Re: [GNSO-Accuracy-ST] Level Setting "Under the GDPR, as the other extreme, data is fully 100% accurate if it "accurately" reflects the data provided by the registrant." GDPR (Article 5, Section 1(d)) says that "every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay" Alan At 2022-03-07 08:26 AM, Volker Greimann wrote: Hi Michael, I do not understand your hesitation to call it a definition, or even a working definition as that is the exact terminology that the council has tasked us with. If we cannot even agree on a definition, how are we supposed to make progress on the more complicated issues? As to the question of the term of accuracy, I believe we have already established that there are varying interpretations, and ultimately, our definition within the ICANN context has to flow from the definition. Looking at dictionaries may be helpful, but does not solve the conundrum of context. I disagree with Stephanie that accuracy needs to be a binary choice as there can be various levels of accuracy in our context. For example, a data set that just uses the wrong formatting may not be 100% accurate in the dictionary sense, but is still accurate enough to qualify for "sufficiently accurate to meet the purposes", even if it is not fully accurate in the meaning of the 2013 RAA, which may need some revision to be more generous towards registrants in some cases. Under the GDPR, as the other extreme, data is fully 100% accurate if it "accurately" reflects the data provided by the registrant. So to answer your Question #1: I feel that option (b) "Degree of correctness" is a better reflection of the facts on the ground than a binary choice. -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net <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 Sun, Mar 6, 2022 at 8:32 PM Michael Palage <michael(a)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+… 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(a)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 <https://www.icann.org/privacy/policy> ) and the website Terms of Service ( https://www.icann.org/privacy/tos <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(a)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 <https://www.icann.org/privacy/policy> ) and the website Terms of Service ( https://www.icann.org/privacy/tos <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.

2 2