Dear All,

As discussed, the staff support team has created proposed language for section C.2.2.” Measurement of whether current goals are met” which can be found here: https://docs.google.com/document/d/1CYs9mLHsKcZevmZtFrQBDXbv_nkQ5PKe/edit. This is for the moment a standalone document, but once review has been finalized it will be integrated into the write up for assignments #1 and #2. Please include any comments or proposed edits you may have IN COMMENT FORM ONLY.

Thanks,

Caitlin, Berry and Marika

From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces@icann.org> on behalf of Caitlin Tubergen <caitlin.tubergen@icann.org>
Date: Thursday, 12 May 2022 at 19:37
To: "gnso-accuracy-st@icann.org" <gnso-accuracy-st@icann.org>
Subject: [GNSO-Accuracy-ST] Notes and action items - RDA Scoping Team Meeting #29 - 12 May 2022

Dear RDA Scoping Team members,

Please find below the notes and action items from today’s meeting.

Best regards,

Marika, Berry, and Caitlin

--

1. Support Staff to translate today’s discussion of proposals into text for the write-up.

2. Support Staff to convert the draft message to the EDPB into a Google Doc [docs.google.com] for further feedback from the group. Support Staff to include the feedback already provided by individuals. (Note: ideally, the group can provide a unified response to ICANN org regarding how this communication to the EPDB could assist in the Scoping Team's work.)

3. 🚨🚨 Important note: Scoping Team members to provide feedback to the draft write-up [docs.google.com] IN COMMENTS FORM ONLY. 🚨🚨

Registration Data Accuracy Scoping Team – Meeting #29

Thursday 12 May at 14.00 UTC

1. Welcome & Chair Updates (5 minutes)
   1. Project Change Request submitted to the GNSO Council (see https://mm.icann.org/pipermail/council/2022-May/025662.html)

- For those interested, please review the link above.

2. ICANN74 session scheduled for Tuesday 14 June from 11.15 – 12.30 UTC (13.15 – 14.30 local time)

- Pre-registration is required, and details regarding this will be published shortly.

2. Gap Analysis Data Collection Proposals that do not involve access to registration data (30 minutes)(see https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit [docs.google.com])

- The work is currently focused on proposals that do not involve access to non-public registration data.

- One proposal being explored is to do an ICANN compliance audit – with that in mind, the group posed some initial questions to compliance

- Two colleagues from compliance have joined the call today to answer the group’s questions

- At the end of the review of these proposals, the group should consider if there is a recommendation for a consideration of the proposal and why or why not.

a. Proposal D - Registrar Audit

• Opportunity to discuss further with ICANN Compliance

· Compliance developed a written response, which includes multiple options:

· Auditing without personal information – this would be limited to requesting information regarding the processes registrars use for the verification and validation requirement

· Based on input from the EDPB or similar authorities, Compliance would be more certain what it is allowed to do. It is correct that you can get redacted data in response to a complaint or inquiry (3.4) but not related to a compliance audit. Further information is necessary in terms of what could be asked for in an audit.

· If Compliance sends an inquiry or questionnaire, this is not a true audit. A true audit is when data is verified against substantive information.

· Based on this information from Compliance, would an audit like this be helpful for the group in Assignments 3 and 4?

· In doing these audits, does ICANN send tailored questions based on the respective business model that the registrar is operating (retail, wholesale, etc.)? If there is only one template, how are differences accounted for?

· When audit questions are sent to contracted parties, the questions are not tailored to specific business models.

· Follow-up questions may be sent based on the registrar’s initial responses. For example, if there is an obligation to send a reminder to a registrant regarding the expiration of a domain, and a registrar says, “our resellers do this,” Compliance would say – please show examples of this. Compliance would not contact the reseller directly since ICANN does not have a contractual relationship with the reseller.

· Does Compliance attempt any verification that the registrar is indeed telling the truth?

· Under the current scenario, compliance is not in a position to measure the accuracy of data; what they could do is audit registrars to confirm if their obligations are being followed under the Accuracy Spec. Not sure how this would be helpful for assignments 3 and 4 – the measurement of accuracy. At most, this seems tangential to the task at hand.

· If a DPA is asked whether ICANN has the authority to measure accuracy, then you have to follow the purpose you have stated. Data commissioners have been clear that ICANN does not have a mandate to do criminal investigation. It seems that this group is attempting to get greater accuracy in the data – it will be difficult to find a purpose here.

· Just because a name has been taken out of the zone, the harmed individual may still want to seek redress and seek the underlying information

· This group has not discussed criminal investigation. Registrars have made it clear that they have no need for the information in RDDS. It is clear that under the current understanding of GDPR regulations and the contract, ICANN does not have the authority to ask for information other than in pursuing a complaint.

· In the course of Compliance doing its work, does Compliance end up in a dead end – is there something that would position compliance to do its job better?

· During audits, prior to GDPR, Compliance would validate and verify every field in the RDDS b/c Compliance had access to it – phone number, mailing address, etc.

· As auditors, Compliance audits the data it has access to.

· What the group is talking about is what suggestions the group can make – the previous question from the chair was a leading question. The group hasn’t identified gaps yet. 

· In the previous era, during an audit, ICANN might choose to verify data it had access to. Would like to presume that ICANN was not frivolously wasting time by verifying data – if they used to audit data and now they cannot, that is a substantive change. This is important information to this group.

· ICANN was previously in denial of all data protection law, so past procedures cannot be presumed to have been justified.

· GDPR does not prevent ICANN from doing its job, but the job is not impossible.

· Do any members believe there is value in pursuing this proposal further?

· Interpreting silence as no interest in moving forward with this proposal

1. Proposal A - Registrar Survey

• Went into this thinking it could be a useless endeavor, but after working with the small team, think this could produce value. Maybe it would not be the highest value, but believe it should be considered
• This is really dependent on the quality of responses – would need to be one person per company
• Is there a way to create uniform clear messages for registrars to respond to?
• Could the survey focus on the steps registrars take to ensure the data is accurate? Perhaps it’s a two-part survey, where questions from the first round could help inform the second round of questions.

2. Proposal E – Review of Accuracy Complaints

• Looking at existing complaints is only a small piece of the puzzle; however, do not have a suggestion of what data the group could get out of this
• If there some notation that could be put in the report to put a pin in this and come back after assignments 3 and 4
• There does not appear to be strong support to move forward with these initiatives
• The group can indicate that these are proposals that were considered, but the group is not sure if these proposals would produce valuable data for assignments 3 and 4. If the group, based on all of the proposals, is not sure if this is worth the effort, the Council could say – there is nothing to move forward with at this stage. How can the group get to assignment 3 since it was designed to be informed by a factual analysis that includes data.
• There is nothing to say the group cannot bring something back to the table, but as of right now, it seems like review of accuracy complaints is a dead end.

3. Confirm next steps

• Support Staff will translate today’s discussion into text for the write-up.

3. Scenarios for EDPB

1. See update from ICANN org (https://mm.icann.org/pipermail/gnso-accuracy-st/2022-May/000444.html)
2. Scoping Team feedback by 23 May

• There have been some individual responses; is there interest for the group to work on a common response? That would be ideal from org’s perspective.
• Have a hard time understanding why we would ask European data authorities about scenarios 1 and 4. Everyone has access to public data, and 4 does not require access to PII.

3. Confirm next steps

• Support Staff to put email up in Google doc and include comments that were added in the Google doc and encourage everyone to come to a common conclusion. If anyone is willing to take up the pen to draft a response from the group’s perspective, that would also be welcome.

4. Write up for assignments #1 & #2 (see https://docs.google.com/document/d/13sP-2z7rusEYrDyntrgm-tcIavPMJndU/edit[docs.google.com]) (15 minutes)
   1. Review input received
   2. Consider possible recommendations
   3. Confirm next steps

5. ICANN org responses to recent set of questions (see https://mm.icann.org/pipermail/gnso-accuracy-st/2022-April/000398.html) (If follow up questions are identified prior to the meeting)
   1. Reactions / follow up questions
   2. Confirm next steps

6. Confirm action items & next meeting (Thursday 19 May at 14.00 UTC)