Dear Scoping Team Members, Below, please find the notes and action items from today’s meeting. Our next meeting will be during ICANN72 on Tuesday, 26 October from 19.30 – 21.00 UTC. Best regards, Marika, Berry, and Caitlin Action Items 1. Policy Support Staff to set up email list similar to SSAD ODP mailing list, which can be used by non-members to submit suggestions regarding accuracy. (Note: the mailing list will be test for one month. At the conclusion of one month, Leadership will choose to retain or discontinue the mailing list based on use.) 2. Michael to notify GNSO Council that the Scoping Team plans to allow alternates to participate in the Scoping Team. The use of alternates will be similar to how other GNSO efforts have used alternates; in other words, alternates would be available to step in if a member is unavailable. 3. Reminder that all Scoping Team members are requested to comprehensively review the briefing materials, and, if questions to ICANN org arise after having read the materials, Scoping Team members to populate questions into the dedicated Google Doc<https://docs.google.com/document/d/1lRiuyCMg2lxkMDJEuAroUht_pgv2Nw9e/edit>. Following receipt of questions, Leadership will determine if a briefing is warranted. 4. Scoping Team members to review new input provided in Assignments #1 - #2 and consider how this needs to be translated into a work plan and timeline by COB Monday, 25 October Registration Data Accuracy Scoping Team – Meeting #3 Thursday 21 October at 13.00 UTC 1. Welcome & Chair Updates (10 minutes) * Miscellaneous administrative issues * With respect to the email list for third parties, we will set up the email address (similar to the SSAD ODP email list), and we will try it for one month. If it proves successful, we will keep it; if not, we will terminate the email address. * Action: ICANN Support Staff to set up email list for third parties. * With respect to the use of alternates, the charter does not foresee the use of alternates but it does allow for additional expertise. It may be worth notifying the GNSO Council of the proposed use of alternates as this was not specifically foreseen. There is, however, some flexibility in the Council instructions. This could work in the same way that alternates work in other settings; in other words, alternates would step in for members when members are not available. * Michael to notify GNSO Council of Scoping Team’s proposed use of alternates. * ICANN72 session – Tuesday 26 October (19.30 – 21.00 UTC). Proposed agenda: · Welcome & Introduction · High level overview of workplan · Open microphone · Confirm action items & next meeting (Thursday 4 November at 13.00 UTC) * Many members will be available for this session * No objections to the proposed agenda for the ICANN session * There have been some questions about Google Docs; Support Staff will review determine if there is an instructional video on how to use Google Docs * It works very similarly to other word processing tools; however, contributors can include comments, but cannot delete others’ comments * One issue members have is locating links to the documents * Some members are having issues getting to the google drive via email * Note: please find additional helpful links here: https://community.icann.org/display/AST/Google+folder 1. Background briefing assignment #2 – see https://docs.google.c‌om/document/d/1OyzzAjZgvNkfZ5EekUvJ7PQg80vNZvJ3/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1OyzzAjZgvNkfZ...> * Review assignment #2 * Staff Support team collected information on how accuracy levels have been measured so that the group could consider the questions below * There is now input from both the RrSG and IPC * Note: background briefing #1 includes the proposed working definition of accuracy from the RrSG in this briefing * Consider questions and team input received: · What information, if any, is missing to support the team’s deliberations on whether ARS needs a revamp or whether there are other ways in which accuracy levels can/should be measured? * IPC: The question, as worded, is confusing. A better question may be - how do we restart ARS in a GDPR-compliant world? For example, how does the ARS function? Did ARS scrape WHOIS? If so, that will not work anymore, and the group can consider how to make it function. * There may be value in reviewing publicly-available registration data – it would show that there is redacted data (due to data protection law) but also show that some data is not redacted and could be checked for syntactical accuracy * There are some problems in the ARS that are not obvious from the data, including time delays. It may be helpful to receive a briefing from ICANN org re: how the ARS worked. * Question: would it be possible to reach out to relevant staff in ICANN org re: the gaps that are present in the publicly available data? * Action: Alan G. to synthesize questions to ICANN org in the Google Doc, and Brian G. will relay these questions to ICANN org. * Some of the questions IPC is asking are contained in the background documents. Action: As part of the team’s homework, comprehensively review all background information, and if there are follow-up questions, please reflect the questions in the Google Doc. * The following communication is helpful in understanding the current status: https://www.icann.org/en/system/files/correspondence/swinehart-to-fouquart-2.... * Documents are helpful, but believe it would be well worth the group’s time to receive a briefing from ICANN org. ARS could be run today – all domains today have a public Whois response; it’s just that some data is redacted that wasn’t previously. That, in ICANN org’s mind, skews the results. * Before requesting a briefing, please document questions for ICANN org. The other concern being articulated is – can the ARS be done in the current climate? * There is so much material and unlike other stakeholders who have had to review these documents because of contractual requirements, other stakeholders are not as familiar with these documents. The IPC responses endeavor to go to the heart of the matter. What kind of data is available, and what is possible in a GDPR compliant world? * There is a lack of understanding of what the ARS is, and what the current status is. A lot of the documents include many footnotes that link to many other pages, and not all have the stamina to review all of these documents and links. This is why a briefing has been suggested. * The index of relevant resources is the long list of documents in ICANN’s history. The list is long, but it provides helpful context. The background briefing documents pinpoint the most relevant excerpts from documents – such as excerpts regarding ARS, for assignment 2. * The Whois Accuracy Specification is being characterized as optional or discretionary, and that is incorrect. The Whois Accuracy Specification is mandatory. * There is some confusion around data that is collected and data that is disclosed. The data that is collected must be accurate whether it is disclosed or not. There is ambiguity that came out of the dialogue yesterday – there is a minimum level of validation on the data, but registrars may choose to apply a higher level of discretionary validation. The policy question is – should this become mandatory across all registrars. * Footnote 9 alludes to the problem of ARS even when it was in operation. If there is no ARS, but data is still being collected, how is accuracy being tested? * With respect to registrars choosing to impose a higher level of validation, that would be the registrar’s business decision. That is not relevant to this discussion. It may be helpful to review the accuracy requirements under the Whois Accuracy Specification. * What the registrars put forward is not a proposed definition of accuracy; this is the detail of what the working definition is today based on the RAA. * If the registrar validated the email but not the phone number, that is sufficient. Allowing registrars to check either one, but not necessarily give you both is a problem. * If you drill down the Whois Accuracy Program Specification Section f, the language seems to suggest a higher level of validation than just an operable email of phone number. * “In either case, if Registrar does not receive an affirmative response from the Registered Name Holder, Registrar shall either verify the applicable contact information manually or suspend the registration, until such time as Registrar has verified the applicable contact information. If Registrar does not receive an affirmative response from the Account Holder, Registrar shall verify the applicable contact information manually, but is not required to suspend any registration.” – this seems to suggest a higher level of accuracy. * Have a different understanding of this higher level of accuracy. Why are the current requirements not suitable? Accuracy is not the same thing as access to the data. The controller determines the accuracy. The ability for a person to look up data on the internet is not the same as accuracy. In terms of higher level of validation, important to not conflate the registered name holder and the account holder. Instead of using an automated email, it could mean that someone from customer service calls or emails rather than an automated system – this has never been interpreted as an ID check. * ICANN had the opinion that failure to verify would result in suspension; this language was added by request of registrars. With this option, registrars can reach out to important customers and avoid the automatic de-activation. * Qualitative review of data is outside the scope of what ICANN needs to do; it may be something registrars want to do, but should not be required by ICANN * Does this baseline definition seem correct to everyone? * The working assumption is that this is the definition today and the scoping team is reviewing what needs to be changed (if anything). * There is a notion of improving accuracy in ICANN’s bylaws; this is important to consider as continue to discuss this definition. * If there are problems, how can this be investigated? If there is agreement that the definition of today is not where it should be, how can the community get to where it should be? · What approach should the team take to develop these recommendations? · How much time and resources are expected to be needed to either revamp ARS or implement other ways in which accuracy levels can/should be measured? * Confirm next steps 1. Background briefing assignment #3 – see https://docs.google.com/document/‌d/1NiwMk6qHOQRn7VdcW0Paj5OoC3tWAQpm/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1NiwMk6qHOQRn7...> * Review assignment #3 * Work needs to be completed on assignments 1 and 2 before work can be considered on 3 * This is broken down in two pieces – Part 2 looks at the analysis of the accuracy levels measured to see if the contractual requirements are effective. * Consider questions and team input received: · What is necessary to undertake such an analysis? · What is the definition of “effective”? · How are “accurate and reliable” to be interpreted (see also assignment #1 re. working definitions)? * What next steps and approach should the team take to address this assignment? * Confirm next steps 1. Background briefing assignment #4 - see https://docs.google.com/document/d/1Z8t-uH4gRqXytHOGnIkZ2qMSJctgR_kD/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1Z8t-uH4gRqXyt...> * Review assignment #4 * Assignment #4 is the conclusion of the group’s work and focused on impacts and improvements. * If changes are recommended to existing contractual requirements, a PDP or contractual negotiation is necessary to implement the changes. * There is currently no input or comments yet. * As the group works through 1 and 2, the answers to 3 and 4 may change. For example, a survey or study may change, so it may have to be readministered. * It may be a stretch to do anything on 4 at this time. Similarly, the group can discuss 3 but it may not be possible to do anything on 3 at this time. * With respect to the work plan, this is not a PDP, but it is still a group that is beholden to the GNSO Council. At some point, this group owes the Council a work plan or target date for when the work will be completed. It’s important for the group to review all of the assignments so that the work can be properly scoped – can the assignments be worked on in parallel, or is it iterative? The group needs to think about these key aspects that the group thinks must be included as part of the deliberations. The group needs to come up with a reasonable date and work towards it diligently. This has been decided by the community as an important topic to be discussed; accordingly, there has to be some sense of urgency to work that is assigned for homework and productivity in plenary calls. * Consider questions and team input received: · When & how are estimates of benefits and costs expected to be developed? · In addition to outcome of assignment #1-3 and cost/benefit analysis, is there anything further that is needed for the scoping team to deliberate on whether any changes are needed to improve accuracy levels? · Based on response to previous question, what are the options the team can consider for how and by whom these changes would need to be developed? * What next steps and approach should the team take to address this assignment? * Confirm next steps 1. Confirm action items & next meeting (ICANN72 session on Tuesday 26 October at 19.30 UTC)