Dear RDA Scoping Team Members,

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

The next RDA Scoping Team meeting will be on Thursday, 9 December at 14:00 UTC.

Best regards,

Marika, Berry, and Caitlin

--

Action Items

1. Still open: Team to add any additional proposed questions for ICANN org to the google doc [docs.google.com] as soon as possible, but no later than Wednesday 1 December to allow for finalization during next week’s meeting. *NOTE: if your group has not submitted questions yet, please do so ASAP as the deadline has already passed.*
2. Still open: Team to complete the gap analysis document [docs.google.com] prior to the next meeting on Thursday, 9 December.
3. RDA Support Staff to circulate a doodle poll for alternate meetings time for the week of 13 December.
4. Individuals or groups that proposed questions for ICANN org to review questions and determine if updates are necessary in light of the team’s discussions by Wednesday, 8 December.

Registration Data Accuracy Scoping Team – Meeting #8

Thursday 2 December at 14.00 UTC

1. Welcome & Chair Updates (5 minutes)
   • The Thursday, 16 December meeting conflicts with a GNSO Council meeting; there are a few options available for alternate times.
   • The options are: Wednesday, 15 December at 14:00 UTC, Thursday, 16 December 13:00UTC, or Thursday, 16 December at 16:00 UTC.
   • Following the call, ICANN Support Staff to send a doodle poll to the Team so that members may indicate preferences. Leadership will make the decision following the doodle poll results.
   • Most of mailing list archive issues seem to have been resolved; some members, Michael included, occasionally do not receive emails. Members should periodically check the archive list to ensure no emails are missed.

2. Follow up questions to ICANN org regarding enforcement and Accuracy Reporting System (60 minutes)
   1. Input received from scoping team to date: https://docs.google.com/document/d/1arlKdQkbRkE1LuurmDdd-PZP184_AdFm/edit[docs.google.com]

• What does the team believe should be the threshold for having questions included on this list going forward?
• During the previous call, Alan G. noted he would make updates to certain questions. Additionally, in response to Question 4, Support Staff noted that it would be up to the contracted party whether to disclose all or part of the information in a request.
• These are not questions from the entire team; individual stakeholder groups are called out in these questions. However, it will be important to assess whether these questions have already been answered (in the briefing documents, for example). Also, team members may have suggestions on how to clarify or improve the questions, but if the questions get submitted should ultimately fall to the submitter of the question. In other words, the barrier to entry should be low.
• The questions note they are put forward by a specific stakeholder group; will leave it up to individuals if the question has the sign-off of the stakeholder group or if it should be submitted on behalf of an individual. Support Staff will organize the questions and group them, which the team can review before submission to ICANN org.
• Previously Whois accuracy complaints were clear, but what kind of complaints is Compliance seeing now? – this would be helpful to understand in light of GDPR
• What is the main cause for complaints being rejected before being passed on to registrars? – this would also be helpful to understand since contracted parties have no visibility into this
• RySG believes it would be important to understand ICANN org’s interpretation of the difference between verification and validation requirements
• RySG – Question 10 – get at answering the question from GNSO Council – does ICANN compliance agree with the definition put forward by the registrars?
• There are multiple levels of accuracy, so the term accuracy unadorned is not sufficient – for example, is it operational accuracy, is it syntactic accuracy, or is it something else?
• In terms of Rr definition re: what is currently monitored under the RAA, RySG is not disputing what Rrs have previously noted.
• There are many ifs, buts, and ands in the Whois Accuracy Program Specification description of accuracy that are not included here.
• There is an open issue on the definition.
• Would prefer to use contractual construct rather than definition. Do not understand the value of asking ICANN compliance if they agree with this definition. What would the impact be of a yes or a no reply from ICANN compliance?
• Assignments 3 and 4 will look at where potential changes or shortcomings may be identified.
• RrSG is not proposing any definition; the RrSG just described what registrars are contractually obligated to do. If other members don’t like it as a definition, it’s irrelevant.
• In terms of operational accuracy, this is very important under the UDRP to provide proper notice to the complainant and respondent. The postal address is very important in terms of providing proper notice. Is there a reason the postal address is specifically omitted from this list?
• The answer to this question is that postal address is part of the syntactical accuracy requirement, but not the operational accuracy requirement. There is no requirement to verify a registrant’s postal address.
• Not asking if someone is actually there, but does this address exist?
• Some of this concern is addressed in the across field address validation work from ICANN org.
• In listening to the feedback, one thing that could make sense – when registrars submitted this, they included additional context around it. It may be helpful to also include the additional context with this definition to quell some of the concerns. Registrars proposed the definition to capture what the current state is. It’s important to understand the current accuracy situation before recommending new requirements.
• Discussing data quality here – this is important to keep in mind. The 2013 RAA was not constructed with data protection in mind. This needs to be reviewed along with the new policy. Some of the accuracy requirements may not be justifiable anymore. Cannot turn back to an archaic contract that needs to be revised to ensure requirements are lawful under a data protection lens.
• This may be more relevant for the next assignment, i.e., the gap analysis.
• This requires a paper, not just a paragraph. Analyze the contract, the new policy and if it passes legal scrutiny. After finding out what can stand in the RAA, then start from scratch in terms of what ICANN compliance can do in terms of accuracy review.
• Is what this group using as its current understanding of what accuracy is corresponding properly to ICANN Compliance’s view?
• This group is not here to make up things that would be nice; the group is to look at current requirements and purposes and see if purposes match the current requirements. The second question re: what ICANN Compliance thinks presumes ICANN Compliance is the ultimate arbiter of the contract and policy; they are not and are not infallible – they have stood corrected in their interpretation of the policy.
• The real world is showing this group that changes need to be made. For UDRP respondents, DHL couriers are rarely able to send notice to postal addresses b/c so many are inaccurate.
• If there is a concern with postal addresses, it is important to pursue that in the gap analysis along with any supporting references that could be documented.
• Question 12 – the term “usually” should be quantified into a percentage.
• Question 13 – there are multiple terms that almost say the same thing – for example – reasonable and commercially practicable, commercially reasonable, etc. Is there a standard that this is being judged against?
• This is an interesting question, but what is the connection to the accuracy scoping team’s work? This question should be adjusted to include this.
• The RAA notes that AFAV is subject to technical and commercial feasibility – knowing how ICANN interprets that is relevant to this group’s work. Support Staff pointed to a document that says “we hope to come to an agreement on what that means”, and that document is four years old – that does not bode well for this group’s work.
• Do not think the question is relevant at all because it does not speak to accuracy, it talks about pre-conditions for accuracy requirements; this is irrelevant for the team’s work.
• What is the upside of not asking the question now and asking it later?
• Should address questions 1 and 2 first, which deal with the current status quo. The status quo does not include across field address validation.
• It is important to see this exercise as holistically as possible. The commercial reasonable phrase is very important because it appears in multiple instances in multiple documents.
• Do not object to the question, but it should be asked in the right phase. Also, have concerns with trying to define generic contractual terms.
• Not trying to determine what reasonableness is in a philosophical way. The team has been asked to put together definitions – need to look at this holistically. What are the things that affect accuracy? There are many moving parts, including commercially practicable and commercially reasonable.
• There are currently 20 questions in this document; it’s not possible to go through the remaining 7 questions in the remaining time. Hope to conclude the questions during the next call.
• ISPCP does not anticipate submitting any questions.
• BC is unsure if it will submit questions.
• NCSG will get back to the group soon on if it will submit questions.
• GAC needs additional time to coordinate questions.
• It appears the group is falling behind its stated objective. Have advocated for asynchronous activity on the list; however, thus far, the group has only made progress on plenary calls. At a certain point, the team may have to start increasing the cadence if the work continues to fall behind.

2. Scoping team input
3. Confirm final questions for submission to ICANN org

3. Gap Analysis (25 minutes)
   1. Review input received from scoping team: https://docs.google.com/document/d/11msexuoqWSUsFj8ZjVvWF-XHpcMJntWH/edit[docs.google.com]
   2. Scoping team input
   3. Confirm next steps

4. Confirm action items & next meeting (Thursday 9 December at 14.00 UTC)