Dear RDA Scoping Team members, Please find below the notes and action items from today’s call. The next meeting will be Thursday, 20 January at 14:00 UTC. Best regards, Marika, Berry, and Caitlin -- Action Items 1. Scoping Team Members to review ICANN org responses to questions and provide follow-up questions (if any) in writing to the mailing list by COB Wednesday, 19 January. (Support Staff will then add all questions received to the wiki page: https://community.icann.org/pages/viewpage.action?pageId=184996761.) 2. Scoping Team Members to review follow-up questions from today's meeting (as captured in the meeting notes and flag if these questions need to be updated by COB Friday, 14 January. 3. STILL OUTSTANDING: By Wednesday, 19 January, Scoping Team 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. As noted during today’s meeting, Support Staff has begun inputting the responses received from the Gap Analysis here: https://docs.google.com/document/d/11msexuoqWSUsFj8ZjVvWF-XHpcMJntWH/edit?pl... 4. STILL OUTSTANDING: BC colleagues to input feedback into Gap Analysis as soon as possible. Registration Data Accuracy Scoping Team – Meeting #13 Thursday 13 January at 14.00 UTC 1. Welcome & Chair Updates (5 minutes) * Vice-chair – volunteers? Proposed deadline for expressions of interest Wednesday 19 January. * This is currently an open item. If a member and would like to serve in the capacity of vice-chair, please express your interest by COB Wednesday, 19 January. 1. ICANN org responses to Scoping Team questions (30 minutes) * High level overview * This is an opportunity to provide a high-level overview of the content of ICANN org’s response to the questions; however, given that these answers were distributed less than 24 hours ago, members are welcome to digest the answers and ask follow-up questions after reading the questions. * The GDPR has limited access to registration data for all parties, including ICANN and the Compliance Team. Accordingly, this limits ICANN’s ability to check the accuracy data. ICANN org is in communication with relevant authorities in Europe re: GDPR and NIS2 legislation. * With respect to compliance staff training, there is a robust training program that includes training on the contract and consensus policies. * ICANN org endeavored to provide tangible examples where possible. For example, question 4 provides example of types of complaints. * Specific data and metrics are all provided. Compliance has a robust dashboard for data points. Recommend going to this link if there is further interest: https://features.icann.org/compliance/dashboard/2021/0121/report. * Compliance reviewed the definition put forward by registrars, based on the RAA and noted it does not employ its own definition of accuracy but relies on what is in the RAA. * With respect to the Q on ARS, ICANN org is working on a more comprehensive memo on ARS. * Scoping team follow up questions / comments * How is the Compliance team trained on GDPR specifically? * Are the metrics from Compliance based on complaints received? (Answer: yes.) Would be interested to know – prior to the GDPR, how did ICANN perform these checks? * What is the status of the DPA negotiation between ICANN org and contracted parties? * Is the ability for ICANN to share any of the training materials possible? (For example, it has been difficult for the group with respect to wordsmithing. If there are documents regarding clarity on these issues, it would be very helpful.) * With respect to Q3, it discusses issues that are out of scope. How would a third party complainant ever file a complaint regarding the accuracy of registrant data behind a P/P service? When is a complaint in scope and when is it out of scope? * With respect to the engagement you are doing on the NIS2…exactly what kind of purpose are you lobbying for? How does it fit with ICANN’s controller role? Who else do you think should be able to avail themselves of that “legitimate purpose” role to check accuracy? Do you envisage outsourcing and how would that work? Who are you engaging with, the EC or the DPAs? * On the answer to Q21, Do not disagree with second and third paragraphs of this response; however, do not believe it belongs in a definition. The operational activities taken to make something accurate is not part of the definition of what is accurate. * On the answer to Q21, the second to last line uses the term “patently inaccurate”. How is “patently inaccurate” determined? For example, the name Mickey is an actual name. There are times where data may look fishy but is, in fact, correct. How does ICANN org make this determination? * Next steps * What is the preferred format for follow-up questions after this call? * Action: Members to submit follow-up questions in writing to the mailing list. Support Staff will then extract all questions into the dedicated wiki page here: https://community.icann.org/pages/viewpage.action?pageId=184996761. 1. Gap Analysis (20 minutes) * Responses to questions raised in relation to GAC input during meeting #11 * Continue review of remaining input (ISPCP, still missing BC): https://docs.google.com/document/d/11msexuoqWSUsFj8ZjVvWF-XHpcMJntWH/edit[docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/11msexuoqWSUsFj8ZjVvWF-XHpcMJntWH/edit__;!!PtGJab4!pMEO9gOaGmj6O2C0OJ2MiWB2y3FXuzrVZ-EHunnllzCDoNv5_ca8FMQzCbTWD-m_SUBWXLufFQk$> * BC input is still not finished – endeavor to submit this by COB today * ISPCP input: There do not seem any additional goals with respect to accuracy. * It is problematic to define additional goals beyond the processing purposes defined by the EPDP. However, additional work is required to properly implement the EPDP recommendations, such as international data transfers. * Operationally, the most important aspect is that the data - as provided by the registrant or account holder, is accurately processed by the contracted parties and not altered by technical flaws, human errors or external actors, e.g., in the context of cyber security threats. * The GNSO Council should work on any upcoming issues and potentially launch additional policy work. To the extent that problems arise in the context of the RAA, that would likely be contractual issues that might need to be covered by ICANN compliance. * Being able to register a domain name and allowing start-ups to use digital real estate as quickly as possible is important. Should not conflate this with the debate on authentication. There are rules in the financial sector for determining that a counterpart for a company is who they claim to be. However, the point here is that data processing is as secure as possible. * Concerned with proposal of NIS directive b/c it may contradict the goals of the SSAD. Asking CPs to check and verify data – it is unclear if this is intended for registrars only or registries as well. If data is not immediately verified, do not know if a company will lose its name immediately. NIS2 is a directive and is still has to be legislated into national laws. * Can ISPCP please elaborate on the additional policy work, and what he would see as the documentation that would be required to trigger it? * The question asks who should be working on issues – in answering the question, discussed the places this work can be done. Do not, however, see necessary additional policy work currently. * * Scoping team input * Confirm next steps 1. Measurement of current goals identified (20 minutes) – see page 25https://docs.google.com/document/d/11msexuoqWSUsFj8ZjVvWF-XHpcMJntWH/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/11msexuoqWSUsF...> (20 minutes) * EPDP Team to consider what is needed and from whom to obtain information identified as necessary to measure whether current goals are met * Now that the team has gone through most of the input (still awaiting BC input), it is time to discuss how to measure whether the objectives stated by groups are being met * In this document, Support Staff created a new table on p. 24, where the responses to Q2 are copied and pasted. There is also a new column where members can start providing more specifics as to what is needed and by whom. For example, registrar can measure the accuracy and should be able to have that information, so how can the group get access to this info? How would this be done? Similarly, other groups provided suggestions about how data could be obtained. * Thus far, no input has been received. * GAC response to questions received from Gap analysis: In relation to Q1 regarding current goals of accuracy, not fully convinced that the current state (as described at the bottom of this document) captures accurately the ‘existing accuracy requirements and enforcement’. We believe that there has to be a more holistic approach when capturing the current state of play and not limit our analysis to the WHOIS Accuracy Program Specification (WAPS). * With respect to comment about being on the same page, GAC agrees, but believes the current state of play is not limited to operational and syntactical accuracy. * Surprised to see this list referenced. The way it is listed of ICANN’s identification of purposes – this list is not the same as the EPDP-identified purposes, and the EPDP-identified purposes are the purposes this group was expected to consider. * In terms of whois.icann.org – action item to check with ICANN org team that owns this page – believe it is more of a historical documentation, but it may not be what this group should use as the authoritative source to build off of. * Which purposes are problematic here? * If the EPDP team agonized over the purposes, why should they be further discussed? * Believe if some believe the additional purposes are no longer valid and some believe they are, these should be further discussed. * The relevance of these purposes is in question. The value for this team with respect to the accuracy question is the data that pertains to the registrant, and this was agonized over by the EPDP. * There is no final order that the EPDP purposes are error or mistake-free. If looking at this list raises an issue where some members believe there is a possibility that the Phase 1 work omitted something, it should be flagged for future work. If there is no gap, the team can move on. * There is a difference between uses and purposes; accordingly, recommend using the EPDP-identified purposes * Confirm next steps 1. Confirm action items & next meeting (Thursday 20 January at 14.00 UTC)