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 Thursday, 11 November at 14:00 UTC. Best regards, Marika, Berry, and Caitlin -- Action Items 1. RDA Policy Support Team to distribute call for volunteers for alternates to SO/AC/C leadership. (complete) 2. RDA Scoping Team members to review the most recent working definition for accuracy (p. 12 of the Assignment 1 background briefing doc<https://docs.google.com/document/d/1k9fvA4gnb13bNbB8O4o72mXMZ8mQnJGC/edit>) and provide proposed edits or alternate definitions by COB Wednesday, 10 November. Once the Team agrees to the baseline working definition, groups can begin working on their proposed “aspirational” or “desired future state” definitions. 3. RDA Scoping Team members to populate questions to ICANN org in the dedicated Google Doc<https://docs.google.com/document/d/1arlKdQkbRkE1LuurmDdd-PZP184_AdFm/edit> over the coming weeks with a goal to finalize questions by Friday, 27 November. Registration Data Accuracy Scoping Team – Meeting #4 Thursday 4 November at 13.00 UTC 1. Welcome & Chair Updates * Council non-objection to appointing alternates and vice-chair * Groups can notify GNSO Support Staff if they intend to appoint an alternate * At this point in time, not going to undertake appointment of a vice-chair, but this has been approved * Appointment of Council liaison * Olga Cavalli has been appointed as the GNSO Council Liaison to the Scoping Team * Adjustment of call time & duration from next week onwards to accommodate for DST * Going forward, the meetings will take place on Thursdays at 14:00 UTC for 90 minutes, with the intent to end meetings after 60 minutes. * This schedule does include Thursday, Nov 25 (U.S. Thanksgiving) * Over the next couple of weeks, here is the plan: * Today – hope to reach rough consensus on the current definition of accuracy * Pending success on that, the Team will have four weeks to go back to their respective groups and produce what is called an “aspirational definition” on where they think the definition of accuracy should evolve to. * During these four weeks, the Team will use that intervening time to produce questions to ICANN org. * These questions need to be vetted before the ICANN org presentation, so please submit them by the last week of November 1. Proposed Work plan & timeline * Review proposed work plan & timeline * Many on this team are familiar with the PDP 3.0 principles for project management, i.e., defining and measuring the work ahead of us. * The Leadership Team was leaning toward an aspirational delivery of a report to the GNSO Council by ICANN75 (mid-September). * The Leadership Team will forward the project plan to the GNSO Council on Monday, 8 November (the motions and documents deadline). It will be an AOB item for the Council meeting. * Each month, we will produce a project package, including the dashboard currently shown on screen, the project plan, and the elements/topics the Team is discussing. * There are four assignments in front of the Team, per the Council’s instructions. The Team will work assignments 1 and 2 before working 3 and 4. Assignments 1 and 2 will be worked in parallel for 12 business weeks (roughly through the end of January). * One challenge in putting this plan together is that it is nebulous what the scope of work will look like; accordingly, February is planned to scope Assignment 3. The Council instructions provide a general direction, but the Team needs to drill own on defining the scope of Assignment 3 (for example, is a survey needed?) * The output of the deep dive into Assignment 3 will result in an update to the Council re: the sizing of the work ahead of the Team. * If necessary, the Team can communicate back to the Council if more or less time is needed. * If the group is on track after ICANN73, the Team will endeavor to deliver the report to the Council by September 2022. * The previous talking points will be included in the provision of the project plan to the Council. * The Group expressed concerns with how to account for the unknowns in Assignment 3, so the current plan includes some caveats and flexibility. * Scoping Team Input: * In looking at the whole process, there is a lot of emphasis regarding the criteria and measurement of accuracy. What are the purposes that are intended to be satisfied? In other words, if these requirements are satisfied, are the requirements fit for purpose? Does the group have an explicit and direct address to that issue? * As a Scoping Team, the Team is afforded latitude; however, the Team should be cautious about relitigating other aspects such as access. * If you called a phone number and it rang, is that accurate data? Most judges would probably say no. Is there a correlation? * For the purpose of today’s conversation, are there any concerns with the timeline? * Question about the tasks: different ideas of what we are putting out from this group. The Scoping Team is not something a PDP is doing. * Getting back to the timeline, what we have proposed here – over the next three months, the Team will be working concurrently on assignments 1 and 2. Today, the group will begin a substantive discussion on what the definition is today and get rough consensus on what that definition is today. From there, the Team will spend the next four weeks discussing within their groups on what the aspirational definition is. * Confirm next steps 1. Working definition of accuracy From assignment #1: “The Scoping Team shall, with reference to the resources that will be included in the index of relevant resources cited below, consider whether there is an agreed definition of registration data accuracy and, if not, consider what working definitions should be used in the context of the Scoping Team's deliberations. Particular attention should be given to the definition that ICANN Compliance employs for “accuracy” in ICANN’s contracts. Note, this does not preclude any subsequent effort from formalising the definition(s) that should be applied in the context of any existing and/or new accuracy requirements that may be developed”. * Review input received on definition (see page 12 - https://docs.google.com/document/d/1k9fvA4gnb13bNbB8O4o72mXMZ8mQnJGC/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1k9fvA4gnb13bN...>) * Sarah and Michael had an exchange on the definition * The latest definition proposed by Sarah appears on p. 12 * The group’s task is to determine if contractual data accuracy obligations are effective at ensuring accuracy levels. The definition is one part of this and even if the definition is perfect, this does not address effectiveness or scope. * Subpart f of the Whois Accuracy Program Specification – there is a difference in technical and legal speak. Affirmative response means more than operational validation. * The requirements for operational validation discussed affirmative response; do not think the phone just ringing would not meet the current requirements. * Do not understand where the example of the phone just ringing comes from. Not sure what an affirmative response actually is – that is determined b/w ICANN compliance and the relevant registrar. The verification method is included in the RAA definition. Have hesitation about incorporating the specific examples because a definition should stand on its own without examples. Agree that it is important to have a common understanding of the difference between validation and verification. * Where is the relationship between the requirement and whether it serves the purpose? * Agree that it’s important to have a good foundation to begin on. Here is the definition, here is current enforcement, here is the scope of where the PDP will lie. * Question 3 could be reviewed before 1 and 2. * If there is a problem, that is what assignment 4 accounts for. One reason the group has been given some strong suggestive guidance is that after the analysis is undertaken, that will drive #4. * It is not just ensuring that the phone is ringing, it is communicating with the RNH. * What is the standard implementation of this requirement for operational accuracy. It is hard to answer that because have not done a survey of all registrars. Email verification is likely more common than a phone verification. Familiar with a text with a link to a webpage. It is, however, difficult to answer the standard overall method for registrars. If that is something the group determines is needed, this could be done via a survey of providers, but this may be out of scope. * Is there anyone who would like to update the definition as it appears now? * In the current definition, it may be helpful to reference the purpose of the definition by citing the relevant portion of the ICANN Bylaws. * In the group’s preparatory meeting, two of three elements of the definition are included. The third element (verification that there is a person at the end and that person is the RNH) is not – there is a third element that should be included. The third prong is not recognized anywhere; this should not be discarded. * The above appears to be identify verification – such as RNH being required to send in a photo ID and that being verified. * Text from ICANN org enforcement of accuracy pre and post-GDPR: “However, if the complaint is about identity (e.g., the registrant is not who they say they are), Contractual Compliance may ask the registrar to provide further information concerning their findings and the results of their investigation specific to the facts of the complaint.” * Registrars have been doing a lot of visible heavy lifting. Proposal to strike “shall strictly be defined” Instead, accuracy “is” syntactical accuracy of the registration data elements processed by Registrars. Also, in line with the text from the GAC Communique, proposal to add “and registries”. In other words, “Accuracy is syntactical accuracy of the registration data elements processed by Registrars and certain Registry Operators” provided by the Registered Name Holder or Account Holder as well as the operational accuracy of either the telephone number or the email address. * What is ICANN org’s authority for doing an identity check? * This is a question to address to compliance as this is confusing, even to registrars * Important to ensure this is a stable and clear definition * Text from ICANN72 GAC Communique: The GAC considers that assignments iii) and iv) are particularly important for the purpose of assessing possible improvements of accuracy of registration data. The GAC is looking forward to exchanging with other constituencies not only on the definition and measurement of accuracy but also on solutions on how to enhance accuracy. The GAC gives particular importance to the verification, validation and correction of all registration data by registrars, and certain registries, in line with their contractual obligations, and supports rigorous monitoring and enforcement of such contractual obligations by ICANN. The GAC stresses the importance of delivering on all four tasks in a timely and effective manner. * ICANN Compliance may ask for further information on the registrar’s findings – this is not asking the registrar to do something new * Compliance will see if registrar has taken reasonable steps * When the Team considers an aspirational definition, consider this as a future state/future solution. It is important not just to focus on the text of the aspirational definition, but also to accompany the text with (i) the problem or concern the aspirational definition is intended to address; and (ii) how that problem can be measured / confirmed. This can be included in clear bullet points. For example, some have suggested that identify verification needs to be included. * * Consider whether in addition to working definition focused on current application, input should be requested on aspirational definitions to identify perceived gap between current definition and aspirational definition * Scoping team input * Confirm next steps 1. Follow up questions to ICANN org regarding enforcement and Accuracy Reporting System * Note additional information added to the index of relevant resources from RDS-WHOIS2 RT, including responses to questions * Input received from scoping team to date: https://docs.google.com/document/d/1arlKdQkbRkE1LuurmDdd-PZP184_AdFm/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1arlKdQkbRkE1L...> * Scoping team input * Confirm deadline for submission of questions 1. Confirm action items & next meeting (Thursday 11 November at 14.00 UTC)