Action Items 1. Proponents of “stress testing” (ALAC, GAC, IPC, etc.) to provide further information into the dedicated template<https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit>, beginning on p. 20 by COB Tuesday, 19 July. The additional details and context will be discussed by the team during the next meeting. 2. Michael P. to provide questions coming out of today’s meeting, e.g., budget allocation for ARS and status of AFAV, to ICANN org liaison in writing by COB Tuesday, 19 July. 3. GAC members to provide additional context as to what “reliability of data” means in reference to their registrar audit proposal (proposal 5) by COB Tuesday, 19 July. 4. Policy Support Staff to schedule an additional meeting for next week on Thursday, 21 July at 14:00 UTC. Registration Data Accuracy Scoping Team – Meeting #34 Thursday 14 July at 14.00 UTC 1. Welcome & Chair Updates 1. Review responses to the survey (at time of publication of agenda – 10 responses received, 70% is of the view that there are no other proposals to consider, 20% have put forward an additional proposal for consideration (see hereunder) and 10% doesn’t have any additional proposals themselves but are willing to consider those of others) * Review additional proposals put forward * Four proposals provide proposed enhancements to the registrar survey * There are some proposals regarding registrar audit/understanding of current accuracy requirements * There is a proposal about AFAV, ccTLD practices, other validation/verification requirements * Propose using the meeting time to go through the proposals that deal with additional suggestions from the registrar survey – these appear to be additions to what is already suggested in the report. As you may recall, a small group effort worked on proposed questions that appear as an annex in the write-up. * * The Accuracy Scoping Team needs to have a discussion about whether it makes sense to survey registrars on how they currently implement the requirements of the RAA Whois Accuracy Specification. As it stands, we are unclear on how registrars implement the accuracy obligations. The results of the survey could be used to assist with measuring accuracy in the Annex D survey and provide more context for what is meant by validation and verification. Please see draft survey attached to this email https://mm.icann.org/pipermail/gnso-accuracy-st/2022-May/000459.html (Sophie Hey, RySG) * The Accuracy Team should revisit the idea of a registrar survey and discuss whether it makes sense to survey registrars on how they currently implement the requirements of the RAA Whois Accuracy Specification. We are unclear on how registrars implement the accuracy obligations. (Elizabeth Bacon, RySG) What kind of effort would this take, and by whom, to implement this proposal? ICANN Org: have the survey translated into the 6 UN languages, create form for survey, distribute survey RrSG: work with ICANN Org to encourage registrars to respond to the survey Scoping Team: Analyse the results of the survey and report to Council. This could be done after the survey has closed, or the Scoping Team could meet while the survey is open to discuss how the results of the survey should be interpreted. (Sophie Hey, RySG, Elizabeth Bacon, RySG) * Registrar survey should include a measure of: a. Number of domains sponsored by the registrar; b. Number or percent of sponsored domains that have had their email contacts operationally verified; c. Number or percent of sponsored domains that had had their phone contacts operationally verified. d. A statement of whether the registrar analyzes all bounces of other indications of possible delivery failure or contact inaccuracy to rectify the situation. ii. Registrar survey should include a request for other (i.e .non-RAA) checks that they do related to accuracy and/or identity that they perform either voluntarily of to satisfy requirements for specific gTLD registries or for ccTLDs. iii. Discussion should be initiated with ICANN Org to identify specific incentives to registrars for completing the survey (if too complicated with no incentive, results will be rather limited) The Scoping Team must work with ICANN Org to develop the survey. The team must meet to enable such interaction with ICANN Org (at whatever intervals are necessary to support the ICANN Org work). There would be no need to meet which the survey is being carried out and until there is a preliminary analysis. However, there should be regular updates on the status and returns. ii. If there is any indication that the survey is not been met with reasonable enthusiasm resulting in significant input, the Scoping Team should be re-convened to address this. (Alan Greenberg, ALAC) * Believe registrar survey has merit, and the output would be worth the group’s time * There is nothing preventing the group from completing the write-up to the Council, and, in the event the Council greenlights the registrar survey, what could be a proposed cadence of the group to work on the survey? * From a Support Staff perspective: the original proposal sets out detailed questions and the proposed approach to be taken. If the group is supportive of the questions, Support Staff could work on a survey mockup and work with the group on finetuning the questions and format. One thing for the group to consider: the longer the survey, the more difficult it may be to get a response from registrars. * With respect to meeting times, this is unlikely to be a weekly conversation. ICANN org is already planning for the next ICANN meeting, and a slot for this group has been tentatively reserved. The group could consider enlisting a smaller team to work on this rather than the entire group. An intermediate step would be to share the write-up to the Council and see if they approve of the registrar survey. * Group should be able to submit the write-up on Assignments 1 and 2 before the survey is complete. * That’s correct, and that is the expectation between assignments 2 and 3. * Yes, the assignment for 1 and 2 should be submitted to the Council – it’s important to have the check-in with the GNSO Council as its ultimately the Council’s call to review the recommendations and consider them. * The implementation of the survey can be worked on after Council gives its green light to move forward with that approach * One unknown is to what extent the current RAA requirements related to accuracy are being implemented. The RAA gives the registrar a number of options – multiple fields can be verified, for example. It’s also unclear how many domain names are covered by the 2013 RAA. There may be other checks that are being carried out, not specified in the RAA, that the group should be made aware of. In terms of the survey being potentially too onerous – perhaps a consideration would be to prioritize the questions (please answer x questions at a minimum) or providing an incentive for registrars to provide incentives. 4. ICANN CPHs AND NIS2 CONSIDERATIONS. The recently negotiated EU NIS2 initiative is expected to pass this Fall. The RDA could work together to find solutions for implementation within ICANN's contract framework. NIS2 requires that internet service providers adopt and implement proportionate processes to verify registration data. ICANN should be adapting the Registrars survey to include questions that establish what the best practices are among cc's and gTLDs and come up with our recommendations as to what would be proportionate. Such data would be useful as the NIS2 is adopted by the member states. It would be a real breakthrough for community efforts come up with a joint agreement that could be socialized within ICANN and by jurisdictions that are proposing NI2 implementing language or similar laws outside of the EU. We can use this opportunity to stand together and demonstrate the strength of the MSM. What kind of effort would this take, and by whom, to implement this proposal? The registrar survey could be drafted to include specific questions to explain the verification procedures that registrars employ, if the verification processes go beyond the minimum that ICANN requires within its contract, what percentage of domains are operationally verified, what the costs of such verification are to the Internet Service providers. There may not be any additional costs just rethinking of questions. (Lori Schulman, IPC) * Perhaps there could be an open question, such as: are there other things you do? Rather than guiding the registrars to respond from a ccTLD perspective. * This could provide some evidence to go and see what is out there. Because the group wants to make fact-based determinations, it would be helpful to understand current business practices. * ccTLDs may have valuable information for this group, such as .DK. * The legal considerations that may differ ccTLDs from gTLDs are a factor when the group decides to recommend policy – however, if there are other accuracy-related checks that are financially viable, whether they can applied universally or not, could be helpful to understand and analyze * Countries operate differently, and would not recommend this. Need to be extremely cautious in applying practices that go with ccTLDs that is a market reality in gTLDs. Would recommend seeking an opinion from Bird & Bird. * Agree to ask; however, there are things to consider once responses come in – the scoping team will need to carefully analyze. * With respect to comments on .DK, not suggesting their methods should be blindly applied but could be considered. Registrar Audit & understanding of current accuracy requirements 5. Building on the ICANN74 Communique, the GAC encourages the team to explore additional and complementary work items, such as: - measuring existing registrant data accuracy controls for new registrations, - testing accuracy controls in a manner that is not dependent upon access to personal data (i.e., data that relate to an identified or identifiable individual), - testing registrar safeguards/systems to see how cases of inaccurate data are handled. etc. Moreover, on the separate topic of what further interim work may be done (separate and apart from the proposals for Registrars surveys and testing), we can discuss how current accuracy requirements are understood and enforced. We note that these requirements are not limited to accurate but also to reliable data (also confirmed by the GNSO instructions when forming the accuracy scoping team). The team has not yet analyzed whether there are procedures in place to ensure that the registration data are both accurate and reliable. What kind of effort would this take, and by whom, to implement this proposal? This is something the Scoping Team should discuss in more detail in upcoming meetings. For instance, the following considerations should be discussed: 1. Who should conduct the testing? (ICANN? Academic researcher? Open invite to parties who may wish to conduct the testing at their own expense?). 2. How many test registrations should be conducted per registrar? 3. How many registrars should be tested and how should this sample be selected. 4. Cost considerations? (Melina Stroungi, GAC) * An audit limits what this group can ask because as part of an audit, ICANN can only require registrars to respond to contractual requirements that the registrar is obligated to do * Audit is probably the wrong word here * Reliability – to some this means that the message is sent to the registrant and the registrant will acknowledge receipt and respond * One additional question – what would be the sequencing of the survey and the stress test – could there be questions for the survey that would inform the stress test? * Confused as to what is being spoken about vs. what is on the screen – the trigger is updates to the contact information. The RAA has certain requirements and could be repeated if helpful. In terms of reliability – what does this mean? * Could GAC provide an update as to what reliable means in advance of next week’s call? * Stress-test the current RAA validation/verification rules by having ICANN Org contract for a study to register names with varying degrees of inaccuracy (in all of its varied definitions) and report to what extent these were recognized during registration). (Alan Greenberg, ALAC) * It may be helpful to know what ICANN previously spent on ARS to inform if there is budget for something like this * Michael to put draft question to ICANN org in writing * Concerns with this proposal: do not like that this team or ICANN is going to choose a specific registration provider or several and that provider gets business from this test. Then the chosen provider gets more scrutiny than the providers who are not chosen. Buying a domain name with purposely incorrect information violates the registration agreement * FINDING ACCURACY DATA ISSUES USING TEST CASES. ICANN could contract with a 3rd party (either a university or private vendor) to register a statistically significant sample of domain names across gTLDs using a fictitious entity. The contractor would monitor the number of domains that were flagged as needed further verification during the initial registration period and then followed to determine whether subsequent accuracy complaints are filed and how they are resolved. What kind of effort would this take, and by whom, to implement this proposal * This would take the scoping of an RFP and a bid for the work by ICANN staff with consultation from the RDA (probably a small working group) and would add an additional survey cost. However, the results could solve a lot of our questions as to the nature and scope of existing accuracy problems. Issues of GDPR liability are eliminated under this scenario as no rights will be violated due to fictitious nature of registrant. (Lori Schulman, IPC) * The registrar would not know that this is a fictitious registrant or entity and would not know that this could be treated differently, and if they do not know, that seems to defeat the purpose. * More clarification would be helpful – getting to a number may not supply anything useful – what does this number mean for example. * Helpful to follow the standard template Cross field validation study * Contract for an independent study of the value of and feasibility of cross-filed verification (as required by the 2013 RAA but never enforced). (Alan Greenberg, ALAC) * Cross-field validation, which is a 2013 RAA requirement, has never been implemented or enforced – largely b/c this was deemed not feasible. This warrants more investigation – looking at it in the context of today’s technology, is may be more practical to implement and enforce today. * Would recommend ICANN provide an update on the last time this was done. * Michael to include a question about AFAV status in email to Brian (org liaison). * It should be possible for each registrar to have its own policy as to what validation and verification it does, but ICANN provides the minimum. Study of ccTLD practices * ccTLDs should be surveyed to identify the level of accuracy and process that they undertake. This should be done with the support of the ccNSO which will hopefully be supportive. (Alan Greenberg, ALAC) Development of other validation / verification requirements * There have been statements made by some team members that the current RAA requirements are not sufficient. The team should delve into this and develop a list of possible (and practical) other validation/verifications/whatever-appropriate-descriptor should be considered for future RAA revisions. These should each include a rationale as to what the benefit would be. Such checks could be made at the time of registration or at other specific times within the life of the registration What kind of effort would this take, and by whom, to implement this proposal? Item vii above is a Scoping Team effort and it must meet to carry out this task. (Alan Greenberg, ALAC) * Do not know if this delves into assignments 3 and 4 – this is simply saying to put some new ideas on the table. * This appears to be #4 - in #3, gaps are expected to be identified and then #4 should identify how those gaps can be addressed (through which process) Confirm next steps 1. Finalize write up for assignments #1 and #2 for delivery to GNSO Council – seehttps://docs.google.com/document/d/1cV5ExSZD6G-owksGmMEmig0OXVdGcAUU/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1cV5ExSZD6G-ow...> * Any outstanding items? * Confirm deadline for final review * Confirm next steps 1. Confirm action items & next meeting (TBC)