Dear RDA Scoping Team Members,

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

The next meeting will be Thursday, 31 March at 14:00 UTC.

Best regards,

Marika, Berry, and Caitlin

--

Action Items

1. Scoping Team members to review the updates to the Accuracy working description and propose FINAL edits by Wednesday, 30 March. Support Staff will lock the document after the deadline.
2. Scoping Team members to consider the Gap Analysis and specifically review the “next steps” column of each proposal by Wednesday, 30 March. The group will begin by discussing the potential next steps for Proposal A during the next meeting on 31 March, so please come prepared for this discussion.
3. STILL OUTSTANDING: IPC Reps to respond to the comments directed to IPC in Proposal H of the Gap Analysis.

Registration Data Accuracy Scoping Team – Meeting #22

Thursday 24 March at 14.00 UTC

1. Welcome & Chair Updates (5 minutes)

2. Accuracy working definition / construct (30 minutes)
   1. Consider input received on proposed description of current accuracy requirements and enforcement (see https://docs.google.com/document/d/1e5rUm-AFFDgNOU3OcT7ABu4InGwPiUyb/edit)

• RySG proposed edits to the definition
• First change: updating the introduction, which now includes “measured against a specified standard” – believe this inclusion is imperative for the work on Question 2
• Also proposed alternative text re: the base registry agreement (additional context was provided over the list for those who are interested on 23 March) – the new text notes that there are no explicit provisions in the base registry agreement that refer to accuracy.
• Question: is the position that Spec 13 does not apply?
• Spec 13 is about eligibility criteria – maybe the annual audits on Spec 13 could be useful
• Agree with this proposed language – only proposed edit is to include the auditing
• If this is a specific registry requirement – that does not seem to be a good analog to regular domain names; accordingly, would support these changes to the definition
• No reference to auditing here b/c consider Spec 13 is not included in the base registry agreement. The audit reference is included in the background information on the list. If we did want to include the auditing information, could include the references to Spec 11 and Spec 12
• A unique use case may not be applicable to the general standard
• It’s the view of the group that the definition should represent the baseline from which to measure. Spec 13 does not represent the baseline requirements
• Find it helpful to go back to the Council assignment, particularly: “The Scoping Team will assess the measures, including proactive measures, used by ICANN Compliance to monitor, measure, enforce and report on the accuracy obligations as specified in the Registry Agreements (RAs) and Registrar Accreditation Agreement (RAA). This assessment will include consideration of what compliance with the existing contractual data accuracy obligations means.” Find it interesting that the proposed definition is currently trying to include every possible thing a contracted party may include with respect to accuracy. This group should be focusing on the baseline obligation that is required by everyone.
• Are contracted parties required to comply with national law? CPs are required to comply with applicable law.
• Reason this question is being raised – aware of NIS2, it would be helpful for this group to look at existing accuracy requirements. If ICANN Compliance is not going to look at national law, it would be helpful to know that.
• Perhaps could include something like, “which are applicable to those TLDs” – not sure that we need to be more specific about the current requirements other than referencing that some registries may have additional requirements
• Agree with this. Have a concern with the newly-added language (during the meeting) regarding “patently inaccurate”
• The assignment is to document the current enforcement
• There seems to be in, principle agreement, to Sophie’s edits; accept the changes and then go back to other changes
• The second paragraph includes changes from Melina made during this call, and a question posed from Alan Greenberg.
• Concerned as additional paragraphs are layered on – this group is setting itself up for a contradiction. Something can be operable, but not be true – for example, if someone moves and forgets to update their address at their registrar. Believe the group should tone down the use of “accuracy of registration data” as accuracy has never applied in its pure form to registration data.
• Cannot put a pure definition of accuracy into a registration system if meeting that term will cost money and price us out of business
• The reference to “specified standard” references the later paragraphs that go into detail about what the RAA says
• Accurate, reliable, and up-to-date comes directly from the RAA
• Recommend using the mailing list to wrap up the definition discussion
• This is meant to be used to describe what accuracy currently means and how it is enforced so the group can begin assignment 2 – we will propose a firm deadline for when suggestions are due

2. Review survey responses – see https://docs.google.com/forms/d/e/1FAIpQLSdL-R4Tk7pP86bMIRMX1tH1IA9-UgbHFYVJyznlBcQjch99Pg/viewform

• 10 responses, and it is pretty 50/50 in terms of responses

3. Confirm next steps

3. Continue review of Gap Analysis Data Collection Proposals (30 minutes) (see https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit)

a. Review Scoping Team input on proposals (upside, downside and possible next steps)

• No further input has been received from groups – not sure if that means everyone is OK with what is currently in the document.
• A specific question was posed to IPC regarding proposal H
• Regarding the RDS 2 recommendations: LE.1 is included in the prioritization exercise that is currently ongoing. CC.1 was referred to the GNSO Council by the ICANN Board – one was considered addressed, but for this one specifically – the Council did indicate that further consideration needs to be given to that item. This does need to be considered, but perhaps not in the context of these proposals.
• BC wanted to make sure these recommendations were noted. Felt these recommendations would contribute to the accuracy of the data. For example, with CC.1 there is no indication why a domain name is suspended. A lot of work was done by the review team, but none of it has been implemented

b. Confirm next steps

• Too close to call an end to assignment 2 – the group has noted areas where additional gather could be gathered, but more information is needed – who needs to gather, who needs to be involved
• Once the group looks at what is in the realm of possibilities, it would be helpful to note a ranking – what should be done first or in parallel? Are there other things the group can work on in parallel?
• This document warrants more discussion
• Could start thinking through the next steps from Proposal A and work way down
• In terms of next call, would encourage the group to take a look at CC.1 recommendation – in reaction to comments not being implemented – this specific recommendation has direct implications to an existing consensus policy. Would be helpful for this group to review this in detail – would this, in fact, require additional policy development so that it can be implemented? This has been an item on the program management tool that needs to be resolved.
• There are two ways to affect this: (1) updates to consensus policy; (2) RAA updates
• The extent to which we can address this is to recommend additional action, but need to consider this in more detail

4. Confirm action items & next meeting (Thursday 31 March at 14.00 UTC)