Dear RDA Scoping Team Members, Please find below the notes and action items from today’s call. The next call will be Thursday, 24 February at 14:30 UTC. Best regards, Marika, Berry, and Caitlin -- Action Items 1. RDA Scoping Team Members to review the definition/document provided by Staff Support (https://docs.google.com/document/d/1JGdNLjOjhmJnj-iDaGvcVnv1gZ5tQu5C/edit), which includes the Rr-provided accuracy definition augmented by the feedback from Contractual Compliance. Groups to include proposed edits or suggestions into the Google Doc by Wednesday, 23 February. 2. Still outstanding for ISPCP reps: 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 page 25 at https://docs.google.com/document/d/11msexuoqWSUsFj8ZjVvWF-XHpcMJntWH/edit?pl... [docs.google.com] [docs.google.com]. For groups that referenced ARS, please consider ICANN org’s recent memo in your response: https://mm.icann.org/pipermail/gnso-accuracy-st/2022-January/000236.html. Registration Data Accuracy Scoping Team – Meeting #18 Thursday 17 February at 14.00 UTC 1. Welcome & Chair Updates (5 minutes) * ICANN73 Session – proposed approach * Proposal to make this a working meeting, much like ICANN72 * Think it may be helpful to have at least a 10-minute readout for the benefit of the community * Meeting is scheduled for Monday, 7 March at 16:30 UTC (no regularly-scheduled meeting that week) * Make sure all have registered for ICANN73 * Participation Links: Zoom participation links will be published 24 hours before the session starts. For more information on how to participate, visit: https://73.schedule.icann.org/attend * Review/input of working definition / construct (see google doc -https://docs.google.com/document/d/1JGdNLjOjhmJnj-iDaGvcVnv1gZ5tQu5C/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1JGdNLjOjhmJnj...>) * Support Staff compiled the working construct of accuracy, augmented with Compliance’s feedback * Thank you for putting together the definition doc – this information does not prompt a new definition – it’s important to keep in mind the difference between a definition and how the definition is actualized. The first paragraph of the registrars’ definition is the actual definition. The second and third paragraphs explain how the definition is actualized. 1. Measurement of accuracy (60 minutes) * Review of existing data sources - role in existing current situation & identifying possible gaps * NCSG: Since the title of this form is “for and by whom”, NCSG is unclear on how answering the question answers the question of measurement. Need to discuss what accuracy means first. In terms of who to get the info from – voluntarily from registrars, though Rrs are not contractually obligated to provide this information to ICANN. If there are other requirements in the controllership arrangement b/w ICANN and CPs, the results should be published. * Having clarity on controllership arrangement could be a decision predicate for this group’s work – other groups have expressed concerns regarding this gap as well * GAC: CPs are in a position to provide data and demonstrate that there are procedures in place. Also, there could be a one-off study or reimplementation of the ARS phases 1 and 2. Consider starting Phase 3 of the ARS. There is currently a lack of data available to measure accuracy. Support the importance of agreeing to a definition of accuracy and how to measure that definition. ICANN should overcome obstacles of measuring CPs accuracy. At the very least, GAC supports what are the legal and financial constraints to measure accuracy and brainstorm ways to overcome the constraints. * SSAC agrees with GAC’s suggestions * In terms of holding CPs accountable for the RAA – CPs refers to Rys and Rrs, but the RAA only applies to Rrs. In terms of demonstrating procedures in place, wondering if there are some examples regarding what that would look like – how could CPs demonstrate this? * Does the GAC have a suggestion as to how ICANN should overcome obstacles to access? * Is there a reason why ICANN cannot use legitimate interest to access the data? * The background docs the group started with noted that the current requirements only apply to Rrs and not Rys * Tracking whether a bounce back occurs from the WDRP notice, Rrs are already required to re-verify the accuracy * There is no requirement to track or report on these rates; however, there is the assumption that all active domain names have gone through this process * On the issue of bounce checking, will be formulating a question to ICANN compliance regarding this – some registrars have noted they do not proactively respond to bounced WDRP notices * If there are certain requirements you do not want to offer from a registrar, you do not sell that TLD * There is no requirement for Rrs to demonstrate a positive – it is only in responding to evidence that the Rr is NOT in compliance. There is no obligation to collect extra data * Procedural plea from ICANN org – if SOs and ACs are putting together questions for org, please do so in writing. * In narrowly defining future studies, in looking at OCTO’s reports, that could represent the high ground of undertaking a legitimate interest study. The point that was raised by Owen and other participants is that framing the question in this way, it could skew the results in the initial pool of data. If legitimate interest is the reason ICANN is exercising its controllership, legitimate interest is probably the best legal argument. * What basis other than legitimate interests would ICANN have? * Do not understand how checking accuracy impinges on privacy in any material way * The GDPR mentions not just disclosure by processing – even if there is no disclosure of the data, that still does give rise to GDPR concerns * The degree of exposure involved is extremely constrained in accuracy checking – it is very narrowly defined * The mere fact that data is processed and transferred to another country can be contrary to European data protection legislation. In looking at past data, it shows that the solution to the problem has caused the data accuracy to increase – contactability was over 90%. * GAC reps have taken into account the recent ARS memo – trying to understand why ICANN org believes what it believes and what guidance it has received on this topic * OCTO produces lists of domain names – is possible for a domain name to contain, in and of itself, PII * Happy to work with GAC reps on formulating that question. Becoming increasingly annoyed that any future requirements have to be compliant with data protection law. Legal person data may still contain personal information of employees. * It is possible to find guidance on any GDPR position one would like to take * BC: the ICANN community lacks the necessary data – continue to push the RDS recommendations and push Rrs to proactively review the data for accuracy * These comments do not help in measuring accuracy and are off target for this assignment * This includes a lot of unsubstantiated statements. * If ICANN takes on a verification role, what responsibility does ICANN have with respect to investigating or further processing criminals’ behavior? * Not all criminals use fake data; the point is – regulation does not necessarily deal with phishing when there is no website and no active domain name * How is there phishing without a domain name? * Review remaining input received on google doc [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/11msexuoqWSUsF...>, see page 25 - How and by whom can it be measured whether current goal(s) of existing accuracy requirements are met? * Confirm next steps 1. Confirm action items & next meeting (Thursday 24 February at 14.00 UTC)