Dear RDA Scoping Team Members, Please find below the notes and action items from today’s meeting. As a reminder, the next meeting will be on Monday, 7 March at 16:30 UTC. Please remember to registrar for ICANN73 in order to access the details for this session. Best regards, Marika, Berry, and Caitlin -- Action Items 1. In advance of the ICANN73 RDA Scoping Team Session on Monday at 16:30 UTC, RDA Scoping Team Members to review the Gap Analysis Proposal Review. (https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit) Note: this document was compiled by Support Staff in an effort to distill the proposals made by Scoping Team Members, including upsides and downsides noted by either the proposer or other team members in subsequent discussions. The document is not meant to restrict the group into choosing one proposal, but rather, the group should review all proposals and see which proposals provide a viable path to forward progress. Registration Data Accuracy Scoping Team – Meeting #20 Thursday 3 March at 14.00 UTC 1. Welcome & Chair Updates (10 minutes) * ICANN73 Working Session proposed agenda: • Brief overview of background and current status • Continue deliberations (e.g., accuracy working definition, review of existing data sources) * Will go over table of pros, cons, etc. * Marc A. suggested this idea during the last meeting – to look through the input received by different groups regarding how data could be obtained. Support Staff went through the input and distilled a number of specific proposals. In some cases, similar proposals are grouped together. When upsides and downsides were identified either in the proposal or in subsequent discussions, these have been included. Staff has also proposed next steps in some instances. * Note: the document isn’t designed as a “choose one” – multiple proposals could be chosen; the team is now asked to look at which proposal(s) could be viable * Action item: RDA Scoping Team to review the document (https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit) in advance of Monday’s ICANN73 session. * This document is a good way of getting into the gap analysis. • Q & A session 1. Measurement of accuracy (10 minutes) * 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? * ISPCP – * RAA spells out accuracy requirements – build on this * Build on third party reports on inaccurate data * Could also collect and compare different data points with other registrars’ data points * Some of this work is harmed by the lack of DPAs – ICANN will not be able to see the actual data, but the methodology can be agreed upon and ICANN audits could confirm if the registrar is applying the correct methodology * There is likely a joint controller situation b/w ICANN and CPs, and JCA could spell our roles and responsibilities with respect to accuracy * When it comes to rectifying data, registrars have the largest pool of data to assist with this * Role of resellers: probably have been one of the overlooked and unaccounted links in the domain name ecosystem * Re: red herring – a lot can be done by drafting additional data processing agreements, but what are we trying to achieve? During Phase 1 of EPDP, there is a recommendation for ICANN and CPs to come up with draft protection arrangements. For a DPA, you can allocate functional responsibilities for the joint controllers. * Confirm next steps 1. Accuracy working definition / construct (30 minutes) * Review input received (see https://docs.google.com/document/d/1JGdNLjOjhmJnj-iDaGvcVnv1gZ5tQu5C/edit[docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1JGdNLjOjhmJnj-iDaGvcVnv1gZ5tQu5C/edit__;!!PtGJab4!tt60RLv9dTD650zoDH0T_jOfUStCLQ76hNSEpWSj5_RJndv9Kkz6AuQEzwJvpPjTnQpfh1YQT5s$>) * For clarity, the 2013 RAA also includes all consensus policies * ICANN Compliance did respond to the draft construct; the response did not change the requirements, but rather, explains when the requirements are tested * Based upon the requirements set forth in 2013 RAA, what are potential changes or enhancements for the group to consider? * Thought team was asked to comment on the definition proposed by the RrSG – seems that now we are discussing how the 2013 RAA is currently implemented. These are different things, and members may have responded differently based on what they thought the assignment was. * There is an inherent confusion in the highlighted assignment: there is a difference b/w what is currently required contractually and what is or what should be a working definition as a task of this accuracy scoping team * Should consider using the term data quality instead of data accuracy – accuracy has a binary quality – what this group is talking about is whether it is formatted correctly, updated in a reasonable timeframe, etc. This implies a role for ICANN that has yet to be defined in a DPA through the parties. ICANN has made progress in how it sees itself, but the details of that are still muddy since the 2013 RAA was hatched without any regard to data protection law. Some issues are on the other side of the picket fence. If this were a negotiated policy, ICANN could argue that it is not a controller. * The problem is when we talk about accuracy and requirements, these are not the same thing. To be accurate to contactability – when Whois was started, the goal was contactability, so accuracy seems to be can someone be contacted. The requirements that have been put in place to achieve the accuracy are not accuracy in and of themselves. Are these contacts contactable? Think what this question was intended to mean: Are there additional requirements that the RrSG did not include that ICANN org included in their comments? * Thought working definition meant what the current definition is, not necessarily what it should be. Once current definition is established, the team can review if changes are needed * The group has struggled with the use of working definition. Important to take note that reference to a working definition is part of the first assignment – this gets to the understanding of the current situation – this allows the group to move to the second assignment – how is this currently measured? There needs to be agreement on what the current requirements of enforcement are. Rrs came forward with current requirements; ICANN responded. Having looked at the proposals here, some are jumping ahead to what they would like the definition to be, but this is about what is currently required and enforced so that we can use that as the benchmark over whether current requirements are being met. * To facilitate and avoid confusion – refer to it as a current description of obligations * When this group started, the RrSG put forward a definition based upon interpretations of 2013 RAA requirements. Yesterday, in a message, started with a presumption that this is a binary process. One definition of accuracy is binary – it is either accurate or inaccurate. Syntactical and operational accuracy of one element. Feedback from Compliance regarding its standard operation procedures – this was not just limited to syntactical and operational accuracy. In response to Mickey Mouse, the term “patently false” was used. What this group needs to be focusing on – what is the grey area here? That is part of the gap analysis. This analysis will help guide the group through assignments 3 and 4. The group is not excluding here; instead, taking the analysis and gathering what the current state is, see if there is a gap, and provide a path forward. * Current RAA has not been revised to look at whether requirements comply with the GDPR – when will that be done and how? Is that within the scope of this team? Do not think so. * For example, identity accuracy is a difficult term, it is not a requirement for registering a domain name. Do not need identity accuracy to register a domain name. * Main requirement for CPs is to accurately process data as it is inputted by the registrants. * There is no absolute bar against certainty about the identity of a registrant – that is a current decision that has been made, and it’s a perfectly rational decision, but it’s also a perfectly rational position to make requirements regarding who, in fact, the registrant is. Trying to draw a very firm line that precludes stricter requirements is a policy discussion. * This scoping team was not looking at what GDPR requires – what we have today is currently above GDPR * There appears to be a global platform that permits anyone to be anyone else without any preventative measures taken – it’s as if a blind eye is turned to domain registration. Why should accuracy not include truth? * Accuracy, in and of itself, is a registrant obligation. Registrars have to act upon inaccurate information when there is evidence of this. No one is saying the information is accurate other than the registrant. * The purpose is contactability; now others are suggesting it’s contactability and identity. Accuracy today is geared toward contactability. * The comment that ID accuracy would promote crime is incorrect – as recognized in early documents in 2000 and 2005 clearly dealt with identity validation – not sure where this got lost along the way. The fact is that everything has evolved since 2013 – criminals and cyber-squatters have evolved – there is a need for this policy to evolve to create preventive aspect from filing fraudulent registration data. * These comments should be discussed later and not here – some have noted that questions would have been answered differently if they understood the assignment better. * As the group goes forward, would be helpful if groups can update what their answer should have been. * RDA Scoping Team Members to update their answers based on the updated question: Based on the feedback from ICANN org, what updates, if any, should be made to the RrSG proposed “current state” definition so that it accurately describes the current requirements and enforcements of these requirements. (Note: question was updated to clarify the original assignment.) * Confirm next steps 1. Review of existing data sources (30 minutes) * See compilation<https://community.icann.org/download/attachments/173703498/Gap%20analysis%20...> developed by Staff Support Team as well as overview of ARS Cycle 6 findings<https://community.icann.org/download/attachments/173703498/From%20the%20Phas...> * Team to consider these existing data sources and role in assessing existing current situation & identifying possible gaps * Confirm next steps 1. Additional questions for ICANN Compliance (10 minutes) (see https://docs.google.com/document/d/1arlKdQkbRkE1LuurmDdd-PZP184_AdFm/edit?pl... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1arlKdQkbRkE1L...>) * Introduce questions (Alan, Michael) * EPDP Team input * Confirm next steps 1. Confirm action items & next meeting (ICANN73 - Monday 7 March at 16.30 UTC)