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, 7 April at 14:00 UTC.

Best regards,

Marika, Berry, and Caitlin

Action Items

1. Scoping Team to continue the deep dive review of the Gap Analysis Proposals (beginning on p. 8 of Google Doc) to identify relevant mitigation to noted downsides and next steps (by whom, by when, other considerations). Please populate additional thoughts to discuss during the next meeting by Wednesday, 6 April 2022.

2. Michael to confirm to the list if/how to proceed with a small team to work out more details for Proposal A (registrar survey) by Monday, 4 April.

3. Scoping Team Members to review the description of current accuracy requirements and enforcement, particularly the new updates, and try to resolve outstanding issues on list among the interested members/conflicting opinions. Deadline for updates is COB Wednesday, 6 April 2022.

4. STILL OUTSTANDING: IPC Reps: please respond to the comments directed to you in Proposal H in the Gap Analysis Doc.

Registration Data Accuracy Scoping Team – Meeting #23

Thursday 31 March at 14.00 UTC

1. Welcome & Chair Updates (5 minutes)
   • It would be helpful to understand how many members are anticipating attending ICANN74 physically
   • Some members are still unsure
   • What may be helpful – Support Staff will send a doodle poll to determine who will attend in person vs. who will attend virtually (or not at all). This is helpful in determining if there will be an Accuracy session at ICANN74.
   • Where is ICANN org on the communication to the DPA?
   • ICANN org is planning to engage European DPAs regarding next steps that can be taken with respect to registration data accuracy. ICANN org will consult with the Board through this process. Plan is to follow up with the European Commission soon – will likely have more information to share later this week.
   • Some updates were made to the data accuracy description prior to the call; plan to stick with the agenda for now. If time allows, members who made updates can speak to the changes later in the call.

2. Commence deep dive of Gap Analysis Data Collection Proposals (60 minutes)(see https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit [docs.google.com])

- As discussed during the last meeting, the team went through the proposals at a high-level. It is now time to go through the proposals more closely to determine the viability of the proposals, and, ultimately, to determine which proposals to pursue.

- Support Staff developed a template to synthesize the general idea behind the proposal (what is this about?), what were the noted upsides and downsides – groups may wish to consider how downsides can be mitigated, and lastly, how to drill down on next steps.

- For each proposal, there were some preliminary next steps noted. Now the group will need to see who will be responsible for the next step, expected timeframe, and what considerations should be included.

a. Proposal A – Survey Registrars

• On the downsides of this survey, not sure the extent to which these can be mitigated, but that said, there are still questions that could be worth asking registrars. The downsides are essentially caveats. This will be voluntary. So long as the data includes the relevant caveats, it still makes sense to engage with registrars. When there is a response or an indication of inaccurate data which results in suspension, how often do those suspensions result in the data being corrected and the suspension being removed? In other words, how many of these mistakes are honest mistakes?
• May be helpful to understand that, with these caveats, would other groups find this data helpful or useful?
• Historically when ICANN has done surveys, they tend to report in the aggregate (this many responses, this many domains under management, etc.) Would it be helpful to report in the aggregate and listing the registrars who voluntarily complied?
• This would provide interesting information from a voyeur point of view, and partly to understand the environment better, but not sure this will result in better recommendations. For example, there was a domain which was listed as a small bakery in France but the postal code did not exist in France – it was changed to a Russian company. Not sure this would be categorized as an honest mistake even though it would be changed.
• In terms of whether registrar names should be listed or not should remain for the registrar to decide and be optional to have name listed. It would still be valuable to have this data since registrars have this data. Note, though, there are no hard and fast rules for registrars to do when confronted with inaccurate or data that has been proven false.
• A survey would be useful – it’s always valuable to get practical information from practitioners. The survey shouldn’t necessarily be limited to gTLDs, as it would be valuable to get as many perspectives as possible.
• Need to think more about whether data from ccTLDs would be helpful – perhaps registrars could have the option of providing more information, but it would probably be more useful if we narrowly tailor our questions (for example RAA requirements)
• Not opposed to including data from ccTLDs, but do not want that data mingled with gTLD data – the value of the survey would be to see what responses are received from gTLD data
• ccTLDs are less valuable as data points since there are so many policies and rules regarding ccTLDs
• If the scoping team is trying to understand outcomes for the Whois accuracy requirements, the questions should be narrowly tailored around that
• Next step: Encourage a small group of members to start working on draft questions- It’s important to include both registrars and non-contracted party reps in this small group.
• Before engaging a small team, the group needs to agree what the goal of this survey is. Would the majority of scoping team members find this to be valuable to the work? Also, need to consider the amnesty question – could the RrSG conduct the survey, and would it be acceptable to remove IANA IDs and provide data in the aggregate, or would this not be accepted by members of the group?
• If the responses will not factor into the scoping team’s report to the council, this will be of little value. Perhaps opening up a small team would indicate interest – if no one joins, or only CPs join, that is indicative that the group does not support this.
• Cannot guarantee that data will be accepted without knowing what will be received, but BC will participate in good faith.
• Would like a confirmation that the responses are reasonably truthful even if the data is not what the group wants or expects to hear
• The verification rule only applies to domains under the 2013 RAA, so not correct to assume verification is 100% due to legacy domain names
• The number probably isn’t 100% but that is not because of legacy domains since most of those names are handled through reminders. The reason it should not be 100% because of new domains – there will always be names that are in the middle of that verification process.
• Aggregate data is fine – this at least gives the group something to think about – this is a welcome first stop.

b. Proposal B – Third Party Assessment (if time allows)

• Is this expected to generate more or better information than the registrar survey?
• A third-party assessment may slow things down and cost more money
• This is mislabeled – the numbers would still have to be extracted from a registrar, and the third party would not have the ability to audit the data. It may increase participation, but it’s not an assessment. Adding an intermediary that is paid may result in slightly more data or slightly less data. Accordingly, see very little value in pursuing this further.
• There would be better data quality if you hire an independent contractor who is skilled in data assessment, this could be easier; will have better data uniformity if you hire an independent contractor familiar with quality measurement. The goal of hiring someone would be to make it easier on registrars.
• Third party may drop the participation as some registrars may be more inclined to respond to an RrSG survey

c. Proposal D – ICANN org Registrar Audit (if time allows)

• This seems to be something that could be Assignment 3 or 4 work
• If results will not be available in a 2022 timeframe, it is likely not valuable to this group for answering assignment #2

d. Proposal E – Review of Accuracy Complaints (if time allows)

e. Confirm next steps

3. Accuracy description of current requirements and enforcements (15 minutes)
   1. Review input received on proposed description of current accuracy requirements and enforcement (seehttps://docs.google.com/document/d/1e5rUm-AFFDgNOU3OcT7ABu4InGwPiUyb/edit [docs.google.com])
   2. Confirm next steps

4. Confirm action items & next meeting (Thursday 7 April at 14.00 UTC)