The Registration Data Accuracy Scoping Team call will take place on Thursday, 03 February 2022 at 14:00 UTC for 90 minutes.

For other places see:


  1. Welcome & Chair Updates (5 minutes)
  2. Measurement of accuracy (60 minutes)
    1. Review of existing data sources - role in assessing current situation & identifying possible gaps
    2. Review input received on google doc [], see page 25 - How and by whom can it be measured whether current goal(s) of existing accuracy requirements are met?
    3. Confirm next steps
  3. Confirm action items & next meeting (Thursday 10 February at 14.00 UTC)




CRM Attendance

Apologies: Manju Chen, Thomas Rickert

Alternate: none

Notes/ Action Items

Action Items:

  1. Still Outstanding: By Wednesday,9 February, Scoping Team members who have not yet completed the assignment to consider what is needed and from whom to obtain information identified as necessary to measure whether current goals are met. Additionally, scoping team members to begin identifying specific ways in which measurement can be undertaken. (see []. *For groups that referenced ARS, please consider ICANN org’s recent memo in your response:*

 Registration Data Accuracy Scoping Team – Meeting #16

Thursday 3 February at 14.00 UTC

  1. Welcome & Chair Updates (5 minutes)
    • There are some groups that have yet to complete the assignments. Thus far, only Rrs and Rys have completed the assignment in advance of today’s meeting. Please complete the assignment as soon as possible if you have not.

       2. Measurement of accuracy (60 minutes)

            a.Review of existing data sources - role in assessing current situation & identifying possible gaps

    • A lot of what was provided in the gap analysis were broad statements or requests to incorporate different parts of the RAA. In short, some input was fact-based, and that input was the core of what problems exist related to accuracy. Would it be possible for the staff support team to group the fact-based input into a document for the group to review?
    • The only objective data is some of the reports from the UDRP panelists who have cited inaccurate data.
    • Support Staff picked out references from the gap analysis and identified five different pieces, all of which were referenced in the index of resources, the most recent being the InterIsle report. A question from staff – what would the group like to do next with this information?
    • It is important to understand the current landscape. If no group has provided factual information, it’s unclear what the group is doing or how it can productively move forward.
    • Confused that CPs are asking for other constituencies to provide data on inaccuracy, but how can these groups go about doing so when very little data, if any, is public. The most recent report seems to be the NORC study. How are these groups realistically expected to provide the requested factual data?
    • The homework assignment is about having this conversation: everyone identified what they believed the current accuracy requirements are, and how accuracy can be measured with the current requirements. Rrs and Rys have provided additional ideas. Other groups have suggested that ARS should be restarted, but it would be helpful if the groups that suggested this would look at this suggestion in the context of the memo ICANN org recently provided. If it should be done, what hurdles would need to be overcome? Then the next step would be to identify gaps. Many members mention problems, but the problems need to be documented and then suggestions of how to move forward need to be suggested – for example, is further policy work necessary? Is there an approach to get data to show that current accuracy requirements are being met or not being met.
    • Not aware of post-2018 data, but some are asserting that there is a problem. Is there, for example, a tracking of how many times you have unsuccessfully contacted someone and could not because of inaccurate data. The problem needs to be quantified rather than a general feeling that Whois data is inaccurate.
    • There have been a number of instances in UDRP decisions where the panelist has cited inaccurate data. If we show data points, is that enough? There is data that shows that there were issues prior to GDPR. That data became inaccessible, and prior to GDPR, ICANN compliance reported inaccuracy being the number one source of complaints. It is a heavy lift to discover inaccurate data.
    • This is a classic chicken/egg scenario. INTA or IPC members may provide reports of inaccuracy, but other members have expressed that anecdotal evidence is unwelcome in this group. Additionally, some parties do not want to disclose their identities publicly due to exposure. This is a very finite, targeted problem that we have.
    • This is an accuracy scoping team, but getting access to data is very hard. There is an inextricable link b/w access and accuracy. There is a three-part process. If someone has a problem and needs to make contact with someone, can they get access to information. Yes or no? If yes, and they receive no response, is it b/c someone chooses not to respond or b/c the data is inaccurate? What percentage of the challenges to reach someone are b/c you cannot get any access to info? What percentage of non-response is because of no response vs. inaccurate data? Some partitioning of this data would be helpful.
    • What homework have certain groups not completed?
    • Cannot demonstrate that there are certain problems because the data is no longer publicly available – not sure how this can be proven. In terms of the reasons why someone may not respond – there is an InterIsle study that demonstrates that in a significant number of cases, there is contact information problems. Asking these groups to verify that there is a problem sounds like a Catch-22.
    • Sympathize with other members – the task of a scoping team is to identify a problem, and if there is a problem, a PDP can be launched to address the issue. It’s impossible to create a solution to a problem that may or may not exist based on outdated data. Without data that corroborates that there is a problem, we cannot move forward.
    • May be helpful to provide examples without identifying companies. Can you provide dates that you requested the info, did the CP respond, was there a bounce back, etc. This would help understand the scope of the problem on the requester side. This is private personal data, and CPs are complying with the Temp Spec and the law.
    • The disconnect here is that fraudulent data is being labelled as accurate. Facts of many UDRP cases center around fraud, phishing, etc. The system currently allows fraudulent registration of inaccurate data. The system encourages the submission of fraudulent data.
    • Cannot readily assume that fraudulent information that is technically accurate has gone away post-GDPR. Whois is no longer public – there is no Whois. Saying there is no problem because it can’t be proven when it was problem prior to GDPR is a problem. The company that does provide proof is often dismissed.
    • All action items are posted on the wiki and available for the group to review – these are sent out on in the notes and agenda reminders. On p. 25 of the gap analysis doc, on the left-hand side, Support Staff has filled in the group’s responses to Q2. Groups now need to drill down on the previous suggestions they made and provide this info in the right-hand column. Please also review the memo provided by ICANN org on ARS and consider this in your response.
    • The question should be asked re: controllership to have an answer that is useful to the team.

               b. Review input received on google doc [], see page 25 - How and by whom can it be measured whether current goal(s) of existing accuracy requirements are met?

    • RrSG: Registrars could report on accuracy measurements – difficulties – there is no requirement for registrars to track this and put the data together in this kind of manner. Will this group accept data provided by registrars? Another option could be to have a third party measure data, but this would necessitate a data protection agreement. Could also look at number of complaints processed by ICANN compliance, but based on others’ comments, it appears these complaints are not submitted.
    • Even if RAA provisions are followed scrupulously, there is a still a substantial amount of inaccurate data.
    • Hope to see the evidence supporting this claim in the homework response.

               c. Confirm next steps

     3. Confirm action items & next meeting (Thursday 10 February at 14.00 UTC)

  • No labels