Dear RDA Scoping Team Members, Please find below the notes and action items from today’s call. The next RDA Scoping Team call will take place on Thursday, 11 August 2022 at 14:00 UTC for 90 minutes. Best regards, Marika, Berry, and Chantelle -- Action Items In the upcoming days, the staff support team will flag on the mailing list when language has been inserted in relation to a proposed registrar audit (in the next few days) so members can begin reviewing. Scoping team to review write up for assignments #1 and #2 and identify whether there are any remaining “cannot live with items.” If so, please flag these in the form of comments and label these clearly as “cannot live with items.” Minor edits should also be suggested in the form of comments. This review must be completed by Friday 5 August COB at the latest. If groups want to append statements to the write up for assignments #1 and #2, these need to be submitted by Monday, 8 August 23:59 UTC. Policy Support Staff to schedule the next Scoping Team meeting for Thursday, 11 August at 14:00 UTC. Group to provide feedback directly to Steve Crocker on his document outlining the group's consensus on accuracy rules and relationship to the TempSpec. Notes 1. Welcome & Chair Updates Michael and Olga worked with staff to develop a timeline to submit the write up for assignments 1 and 2 to the GNSO Council: Between now and 8 August at the latest, any group can submit a statement regarding the write up for assignments #1 and #2. All submitted statements will be added as an annex to the report. The 11 August call would be used to review statements and resolve any outstanding items with the write up. Shortly after 11 August, the write-up would be submitted to the GNSO Council, ahead of the 15th of August Council document deadline. This would allow the Council to review the write up and especially the recommendations included in the write up. If there is no objection from Council, this could mean that the Scoping Team could potentially commence its work on the implementation of the recommendation(s) during ICANN75. Timeline will be circulated with today’s call notes to the list. 2. Continue review of additional proposals (see list attached). Outstanding items: Registrar Survey – see additional language added to Annex D of write up to reflect last week’s input (see https://docs.google.com/document/d/1cV5ExSZD6G-owksGmMEmig0OXVdGcAUU/edit [docs.google.com]). Language added to reflect current accuracy practices, and survey to ask questions about what registrars might be doing beyond the minimum requirements. Background language on how the questions originated and intent were also added. Discussion of Google forms vs Click Tools for distribution of the survey, depending on the group’s needs. Pros and cons of different tools is to be further considered during the implementation phase. GAC members to provide additional context as to what “reliability of data” means in reference to their registrar stress testing proposal (proposal 5). The group held a discussion on the differences between reliability and accuracy. Stephanie Perrin (NCSG): noted that accurate and reliable mean different things. Reliable implies functionality and that something continues to work. Accurate means that someone is contactable. Sarah Wyld (RrSG): noted that a non-response from a registrant in regards to an inquiry in no way indicates that the data is no longer accurate. Registrars have processes in place for verifying accuracy. Alan Greenberg (ALAC): noted that responses from Compliance, even if a registrant receives an email, they are not obligated to reply. Registrars do not have an obligation to follow-up. Sarah noted in the chat that the RAA has a policy on “How, and to Whom, the WDRP Notice May Be Presented: “the WDRP Notice can be presented via web, fax, postal mail, e-mail, or other appropriate means. It can be presented in one or more languages, including at least the language of the registration agreement. The Notice may be presented to the registrant either directly or through the administrative contact for each registration.” The admin contact is not necessarily the same as the account holder. Further, the admin contact is going away, and notice will be sent to the WDRP owner. Sarah Wyld (RrSG): reliable means that it remains consistent across time, and we've agreed that there are requirements to maintain the accuracy of data in an ongoing manner. A registrar has an obligation if they know data is inaccurate. The group discussed responsibilities regarding a controller and processor arrangement. Scott Austin (IPC): cited 3.3.4 of the RAA. WHOIS service must remain functional overtime. The chair encouraged the GAC representatives to relay this discussion back to the GAC team and report back to the group should further discussion be necessary. Proponents of “stress testing” (ALAC, GAC, IPC, etc.) to provide further information into the dedicated template [docs.google.com], beginning on p. 20. The additional details and context will be reviewed by the team to determine whether the proposal should be included in the write up. The scoping team reviewed the additional information that was provided by the IPC regarding this proposal in the google doc. Providing false data and saying that is true is problematic. Alan Greenberg (ALAC): the purpose of stress testing the system is in hopes to make it better. How do you confirm consent, or get around the need to confirm consent in the stress test? Mystery shopping would ensure the test is fully neutral. Chris Lewis Evans (GAC): shared ideas on how to set up the test like an audit, such as notify registrars and identify a window of time of when the test would happen. Alan Greenberg (ALAC): Random verification to ensure that accuracy is being followed. Alan Woods (RySG): It does appear to be a test of compliance, which is an audit. Stephanie Perrin (NCSG): A key element of this discussion is ICANN's security and compliance responsibilities, and the extent to which they are entitled to use data (both real and imaginary) to ensure Contracted Party (CP) compliance. ICANN is not like a corporation doing its own stress testing (such as a bank or an insurance company). It is, in this respect, acting as a public body performing a regulatory compliance role. Steve Crocker (SSAC): If ICANN cannot do the testing itself, it can simply impose a requirement that each registrar contract with a suitable organization to have it done. Stephanie Perrin (NCSG): As we discuss stress testing, ICANN appears to be carving itself in a limited role as a data controller, as a stand-in for a regulator. This is a function that might be managed by a government in other circumstances (forged under the ITU). Strict limits as to what ICANN do in its current role. This brings us back to conducting an audit. Benefit is to third parties seeking data that is no longer available in the WHOIS replacement. Confirm next steps Chair confirmed no meetings until the 11th. Over the next two weeks, the group to continue discussions via the mailing list: See if consensus can be reached about what has been proposed by ALAC and the IPC, which is a type of enhanced audit functionality that could be used. If the parties wanted to come together, there would be a way to pull that off. By the 11th, if there is consensus, the team could make changes to assignments 1 and 2. If no consensus, groups could submit their concerns/objections in their statements, which will be included in the Annex. The staff support team pointed out that the scoping team had previously considered recommending a registrar audit, but this did not include the concept of stress testing. For a variety of reasons such as the possible timeframe for conducting an audit as well as the inability to conduct an audit on aspects that would require access registration data until there is clarity from the EDBP, the Scoping Team did not recommend moving forward with the audit at that point. Seeing the renewed interest in this approach, the staff support team suggested providing some draft language to the group on a potential recommendation in relation to a registrar audit, which would highlight that further conversation would be needed to determine the if/how/why/what of a registrar audit. If consensus is achieved, the write-up could be included in the final draft. Otherwise, individual community statements to be added to the annex could further detail the proposal. Marc Anderson (RySG): discussed why an audit wasn’t pursued in the first place, it might have had to do with timing and needing over six months to receive the results. Need to go back and review the conversations. ICANN org would have potential GDPR concerns and need approval from the EDPB about accessing registrant data to conduct the audit. ICANN org said given these concerns, it would not include registrant data. The NCSG was interested in exploring the concept of data trusts, to examine oversight/audit capability in an MS environment. ICANN needs to have some kind of oversight over itself, as life gets more complex in the info society. Should ICANN sample domain names from the DAAR reporting? Concern that this might be potentially biased. Hence the idea for ICANN or a third-party vendor, to inject third party registrations and then do the testing. 3. Finalize write up for assignments #1 and #2 for delivery to GNSO Council – see https://docs.google.com/document/d/1cV5ExSZD6G-owksGmMEmig0OXVdGcAUU/edit [docs.google.com] 1. Any outstanding items? 2. Confirm deadline for final review. 3. Confirm next steps. Recommendation for ICANN org to draft language in bracketed text between now and the 11th Aug. Between now and the 11th, to continue discussions with the aim to achieve consensus. If groups want to append statements to the write up for assignments #1 and #2, these need to be submitted by Monday, 8 August 23:59 UTC. Need to show the GNSO Council that assignments 1 and 2 have been completed. Staff will flag on the mailing list when language has been inserted (in the next few days) so members can begin reviewing. If there are questions, please contact Steve Crocker to provide feedback on his proposal. 4. Confirm action items & next meeting (TBC) Next meeting is on Thursday, 11th August.