Page History

Notes/ Action Items

Action Items

1. Brian Gutterman (ICANN org liaison) to transmit questions 3 - 7 (https://docs.google.com/document/d/1arlKdQkbRkE1LuurmDdd-PZP184_AdFm/edit?pli=1) 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)
   1. Brief recap from ICANN73 session [icann.zoom.us] – 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.

         2. Accuracy working definition / construct (30 minutes)

1. 1. 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

            b. If staff proposal is not supported under a), review input received (seehttps://docs.google.com/document/d/1JGdNLjOjhmJnj-iDaGvcVnv1gZ5tQu5C/edit [docs.google.com]) 

            c. Review survey responses (see https://docs.google.com/forms/d/e/1FAIpQLSdL-R4Tk7pP86bMIRMX1tH1IA9-UgbHFYVJyznlBcQjch99Pg/viewform [docs.google.com])

            d.  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])

           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

     4.Additional questions for ICANN Compliance (20 minutes) (see https://docs.google.com/document/d/1arlKdQkbRkE1LuurmDdd-PZP184_AdFm/edit?pli=1 [docs.google.com]) 

1. 1. 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

            b.EPDP Team input

            c.Confirm next steps

     5. Confirm action items & next meeting (Thursday 24 March at 14.00 UTC)