July 2022 - GNSO-Accuracy-ST

Notes and action items - RDA Scoping Team Meeting #35 - 21 July 2022
by Chantelle Doerksen Aug. 16, 2022

Aug. 16, 2022

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.

3 3

New proposed language added for review re. Registrar audit
by Marika Konings July 23, 2022

July 23, 2022

Dear All, As per the action items, the staff support team has gone ahead and included proposed bracketed language in relation to a possible recommendation to conduct a registrar audit. This proposed language can be found on page 15. Please indicate on the mailing list and/or in the document (in the form of comments) if you have any concerns about this language and/or proposed changes. The staff support team has also gone ahead and accepted previous edits that were not deemed substantive and for which no concerns were flagged. In line with the action items circulated yesterday, the next steps are as follows: 1. 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. 2. 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. 3. The next Scoping Team meeting will be scheduled for Thursday, 11 August at 14:00 UTC with the aim of finalizing the write up for submission to the GNSO Council. Best regards, Chantelle, Berry and Marika From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces(a)icann.org> on behalf of Chantelle Doerksen <chantelle.doerksen(a)icann.org> Date: Friday, 22 July 2022 at 22:04 To: "gnso-accuracy-st(a)icann.org" <gnso-accuracy-st(a)icann.org> Subject: [GNSO-Accuracy-ST] Notes and action items - RDA Scoping Team Meeting #35 - 21 July 2022 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 1. 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. 2. 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. 3. 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. 4. Policy Support Staff to schedule the next Scoping Team meeting for Thursday, 11 August at 14:00 UTC. 5. 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: 1. 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]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1cV5ExSZD6G-o…>). * 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. 1. 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. 1. Proponents of “stress testing” (ALAC, GAC, IPC, etc.) to provide further information into the dedicated template [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1sScP8MwgDCg4…>, 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. 1. 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]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1cV5ExSZD6G-o…> 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.

1 0

Post call | Registration Data Accuracy Scoping Team | Thursday, 21 July 2022
by Terri Agnew July 21, 2022

July 21, 2022

Dear all, All recordings for the Registration Data Accuracy Scoping Team held on Thursday, 21 July 2022 can be found on the agenda wiki page <https://community.icann.org/x/aIFJD> (attendance included) and the GNSO Master Calendar <https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-accuracy-st/> and the main wiki page<https://community.icann.org/x/hQIuCg>. Thank you! Kind Regards, Terri

1 0

Meeting invitation | Registration Data Accuracy Scoping Team | Thursday, 11 August 2022 at 14:00 UTC
by Terri Agnew July 21, 2022

July 21, 2022

Dear all, The Registration Data Accuracy Scoping Team meeting is scheduled on Thursday, 11 August 2022 at 14:00 UTC for 90 minutes. Please click the link below to join the webinar: https://icann.zoom.us/j/94504686990?pwd=MWc2eXZENk9yN0RqOUUzaGx2eGV0QT09<https://urldefense.com/v3/__https:/icann.zoom.us/j/94504686990?pwd=MWc2eXZE…> Passcode: Vc#0B7$pu8 For Audio only: Or One tap mobile : US: +13017158592,,94504686990#,,,,*4631547480# or +13126266799,,94504686990#,,,,*4631547480# Webinar ID: 945 0468 6990 Passcode: 4631547480 International numbers available: https://icann.zoom.us/u/akRu7JTFd <https://urldefense.com/v3/__https:/icann.zoom.us/u/akRu7JTFd__;!!PtGJab4!pY…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, alternates and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/KgBpD * Check your time zone: https://tinyurl.com/n5d4vwn7 ONLY for Members and Alternates * Please join via the above Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and so it is captured in the recording. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form <https://urldefense.com/v3/__https:/forms.gle/GZqMAi4kKDaVP5o66__;!!PtGJab4!…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the Team is aware at any time who is active. Alternate Assignment –wiki page<https://community.icann.org/x/-wC7Cg>. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Terri

1 0

Registration Data Accuracy Scoping Team meeting
by ICANN Policy Calendar July 21, 2022

July 21, 2022

Meeting: Registration Data Accuracy Scoping Team meeting Date/time: Thursday, 11 August 2022 at 14:00 UTC for 90 minutes Please click the link below to join the webinar: https://icann.zoom.us/j/94504686990?pwd=MWc2eXZENk9yN0RqOUUzaGx2eGV0QT09<https://urldefense.com/v3/__https:/icann.zoom.us/j/94504686990?pwd=MWc2eXZE…> Passcode: Vc#0B7$pu8 For Audio only: Or One tap mobile : US: +13017158592,,94504686990#,,,,*4631547480# or +13126266799,,94504686990#,,,,*4631547480# Webinar ID: 945 0468 6990 Passcode: 4631547480 International numbers available: https://icann.zoom.us/u/akRu7JTFd <https://urldefense.com/v3/__https:/icann.zoom.us/u/akRu7JTFd__;!!PtGJab4!pY…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, alternates and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/KgBpD * Check your time zone: https://tinyurl.com/n5d4vwn7 ONLY for Members and Alternates * Please join via the above Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and so it is captured in the recording. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form <https://urldefense.com/v3/__https:/forms.gle/GZqMAi4kKDaVP5o66__;!!PtGJab4!…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the Team is aware at any time who is active. Alternate Assignment –wiki page<https://community.icann.org/x/-wC7Cg>. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Terri

1 0

**starting in 15 minutes | Meeting invitation | Registration Data Accuracy Scoping Team | Thursday, 21 July 2022 at 14:00 UTC
by Terri Agnew July 21, 2022

July 21, 2022

**Starting in 15 minutes Dear all, The Registration Data Accuracy Scoping Team meeting is scheduled on Thursday, 21 July 2022 at 14:00 UTC for 90 minutes. Please click the link below to join the webinar: https://icann.zoom.us/j/94504686990?pwd=MWc2eXZENk9yN0RqOUUzaGx2eGV0QT09<https://urldefense.com/v3/__https:/icann.zoom.us/j/94504686990?pwd=MWc2eXZE…> Passcode: Vc#0B7$pu8 For Audio only: Or One tap mobile : US: +13017158592,,94504686990#,,,,*4631547480# or +13126266799,,94504686990#,,,,*4631547480# Webinar ID: 945 0468 6990 Passcode: 4631547480 International numbers available: https://icann.zoom.us/u/akRu7JTFd <https://urldefense.com/v3/__https:/icann.zoom.us/u/akRu7JTFd__;!!PtGJab4!pY…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, alternates and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/aIFJD * Check your time zone: https://tinyurl.com/36vhy89k<https://urldefense.com/v3/__https:/tinyurl.com/36vhy89k__;!!PtGJab4!-K2TELK…> ONLY for Members and Alternates * Please join via the above Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and so it is captured in the recording. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form <https://urldefense.com/v3/__https:/forms.gle/GZqMAi4kKDaVP5o66__;!!PtGJab4!…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the Team is aware at any time who is active. Alternate Assignment –wiki page<https://community.icann.org/x/-wC7Cg>. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

Re: [GNSO-Accuracy-ST] Proposed Agenda - Registration Data Accuracy Scoping Team meeting #35 on Thursday 21 July at 14.00 UTC
by Marika Konings July 21, 2022

July 21, 2022

For your information, please note that Scott has made updates to the google doc per action item #1 below in relation to the stress testing proposal. If possible, please review this in advance of the meeting: (from page 20 onwards: https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit) Best regards, Chantelle, Berry and Marika From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces(a)icann.org> on behalf of Marika Konings <marika.konings(a)icann.org> Date: Tuesday, 19 July 2022 at 15:55 To: "gnso-accuracy-st(a)icann.org" <gnso-accuracy-st(a)icann.org> Subject: [GNSO-Accuracy-ST] Proposed Agenda - Registration Data Accuracy Scoping Team meeting #35 on Thursday 21 July at 14.00 UTC Dear All, Please find below the proposed agenda for the next Registration Accuracy Scoping Team meeting which is scheduled for Thursday 21 July at 14.00 UTC. As a reminder: 1. Proponents of “stress testing” (ALAC, GAC, IPC, etc.) to provide further information into the dedicated template [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1sScP8MwgDCg4…>, beginning on p. 20 by COB Tuesday, 19 July. The additional details and context will be discussed by the team during the upcoming meeting. (note that the staff support team has already gone ahead and added some of the questions / comments raised during the last meeting and on the mailing list) 2. GAC members to provide additional context as to what “reliability of data” means in reference to their registrar stress testing proposal (proposal 5) by COB Tuesday, 19 July. In relation to agenda item 2a, please note that the staff support team has added additional language to Annex D of the write up to capture the additional input received on the registrar survey. Please review this text to make sure it accurately captures the discussion. As also noted, as part of the implementation of the registrar survey, following the delivery of the write up of assignments #1 and #2 to the Council, and Council support for proceeding with the Registrar Survey, the staff support team would work with the Scoping Team to work out the details of the survey based on the guidance included in Annex D. Best regards, Chantelle, Berry and Marika Registration Data Accuracy Scoping Team – Meeting #35 Thursday 21 July at 14.00 UTC 1. Welcome & Chair Updates 1. 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]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1cV5ExSZD6G-o…>) * GAC members to provide additional context as to what “reliability of data” means in reference to their registrar stress testing proposal (proposal 5) * Proponents of “stress testing” (ALAC, GAC, IPC, etc.) to provide further information into the dedicated template [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1sScP8MwgDCg4…>, 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. * Confirm next steps 1. 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]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1cV5ExSZD6G-o…> * Any outstanding items? * Confirm deadline for final review * Confirm next steps 1. Confirm action items & next meeting (TBC)

1 0

Re: [GNSO-Accuracy-ST] [Ext] Re: ICANN org concerns re "stress testing" proposals -Notes and action items - RDA Scoping Team Meeting #34 - 14 July 2022
by Brian Gutterman July 20, 2022

July 20, 2022

Dear Michael, all, Thanks for your response and question. To confirm what Becky said, this is indeed an ICANN org response, but for those interested in how it came about, the concerns were raised and shared by a cross-functional team within ICANN that coordinates on these topics that consists of reps from different departments including Policy, GDS, Legal, Compliance as well as other relevant SMEs as needed. Hope this helps clarify a bit, and looking forward to hearing from others and continuing our work towards completing the assignments from Council together. Best Brian From: Becky Burr <BBurr(a)hwglaw.com> Date: Tuesday, July 19, 2022 at 8:06 AM To: "michael palage.com" <michael(a)palage.com>, Brian Gutterman <brian.gutterman(a)icann.org>, "gnso-accuracy-st(a)icann.org" <gnso-accuracy-st(a)icann.org> Subject: [Ext] Re: ICANN org concerns re "stress testing" proposals -Notes and action items - RDA Scoping Team Meeting #34 - 14 July 2022 Hi Michael, Didn't mean to get into an extended back and forth here, just sharing my personal views. On issue 1, we disagree. Bottom line, if "Org" is wrong, Goran is accountable (and the Board to the extent that error reflects any oversight failure). On point 2, when you register a domain name with GoDaddy, for example, you represent and warrant that all information you submit when you create your account is accurate, current, and complete. If you are required to represent and warrant that you will not use gmail to send authorized, non-infringing emails that look like, but are not spam to employees for the purpose of cybersecurity awareness and training, that is news to me. b J. Beckwith Burr HARRIS, WILTSHIRE & GRANNIS LLP 1919 M Street NW/8th Floor Washington DC 20036 202.730.1316 (P) 202.352.6367 (M) ________________________________ From: michael palage.com <michael(a)palage.com> Sent: Tuesday, July 19, 2022 10:36:43 AM To: Becky Burr; Brian Gutterman; gnso-accuracy-st(a)icann.org Subject: RE: ICANN org concerns re "stress testing" proposals -Notes and action items - RDA Scoping Team Meeting #34 - 14 July 2022 Hello Becky, Thanks for your response. Respectfully, I disagree. Personally, I think the “who” is important. Because if you do not know the “who” and the “what” (considerable concerns) how can there be accountability if the “who” was later found to be wrong. Regarding stress tests, many organizations regularly send fake spam messages to its employees to see if they will click on it as part of a broader cyber security and education program. Now as “we” are both aware there have been legal issues involving third parties that conduct these test when they use famous trademarks registered in the domain names sending the fake spam. However, from what I heard from the proposals being discussed over the past couple of sessions, no one was proposing using the trademarks just manufactured identities so as to not involve PII. If you could share any decisions regarding the legality of fake spam testing please share them to the list so that we can include them in our report. Best regards, Michael From: Becky Burr <BBurr(a)hwglaw.com> Sent: Tuesday, July 19, 2022 10:16 AM To: michael palage.com <michael(a)palage.com>; Brian Gutterman <brian.gutterman(a)icann.org>; gnso-accuracy-st(a)icann.org Subject: Re: ICANN org concerns re "stress testing" proposals -Notes and action items - RDA Scoping Team Meeting #34 - 14 July 2022 FWIW - and speaking personally - I'm not sure why it matters "who" in Org was the source of this concern. It was presented as a view of the organization. I understand the purpose of the stress test, but I too have to think about the ethics of attesting to the truth of information you know to be untruthful. J. Beckwith Burr HARRIS, WILTSHIRE & GRANNIS LLP 1919 M Street NW/8th Floor Washington DC 20036 202.730.1316 (P) 202.352.6367 (M) ________________________________ From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces(a)icann.org<mailto:gnso-accuracy-st-bounces@icann.org>> on behalf of michael palage.com <michael(a)palage.com<mailto:michael@palage.com>> Sent: Tuesday, July 19, 2022 8:44:21 AM To: Brian Gutterman; gnso-accuracy-st(a)icann.org<mailto:gnso-accuracy-st@icann.org> Subject: Re: [GNSO-Accuracy-ST] ICANN org concerns re "stress testing" proposals -Notes and action items - RDA Scoping Team Meeting #34 - 14 July 2022 Hello Brian, Thanks for the proactive response from ICANN Org. Could you please clarify who in ICANN Org has raised these “considerable concerns” and could you share them in advance of Thursday’s call. The preamble to the WHOIS ACCURACY PROGRAM SPECIFICATION in the 2013 RAA state ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ [https://alert-dg01.redatatech.com/onprem_security_warning_fetch?r=1&dep=yE5…]<https://urldefense.com/v3/__https:/us.report.cybergraph.mimecast.com/alert-…> Hello Brian, Thanks for the proactive response from ICANN Org. Could you please clarify who in ICANN Org has raised these “considerable concerns” and could you share them in advance of Thursday’s call. The preamble to the WHOIS ACCURACY PROGRAM SPECIFICATION in the 2013 RAA states that the“ Registrar shall implement and comply with the requirements set forth in this Specification, as well as any commercially practical updates to this Specification that are developed by ICANN and the Registrar Stakeholder Group during the Term of the Registrar Accreditation Agreement.” The “stress test” cited by several members of the Scoping Team seems “commercially practical” to me. Therefore, I think from a fact finding perspective we need to document why this is not commercially practical and who is objecting, i.e. ICANN Org and/or the Registrars. Further to our fact gather exercise, is anyone aware of any legal actions taken by a Contracting Party against a registrant/third party that had knowing provided false and inaccurate information in connection with a domain name registration? For the avoidance of any doubt, I do not believe that any one has proposed that these “stress test” domain names be used in any type of DNS Abuse or illegal activity. Best regards, Michael From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces(a)icann.org<mailto:gnso-accuracy-st-bounces@icann.org>> On Behalf Of Brian Gutterman Sent: Monday, July 18, 2022 1:47 PM To: gnso-accuracy-st(a)icann.org<mailto:gnso-accuracy-st@icann.org> Subject: [GNSO-Accuracy-ST] ICANN org concerns re "stress testing" proposals -Notes and action items - RDA Scoping Team Meeting #34 - 14 July 2022 Dear Accuracy Scoping Team Colleagues, With respect to the proposal(s) related to “stress testing” that the group is currently considering and discussing, we wanted to flag that ICANN Org has some considerable concerns about this. Any proposal that suggests that ICANN (or a proposal that ICANN org would ask a third party to do this on its behalf) would enter into domain name registration agreements fraudulently with fake contact info, etc. raises a red flag. Carrying out a stress-test like this may violate many different laws. While we do appreciate and support “outside the box” proposals as we carry out the GNSO instructions and assignments together, we wanted to flag to the group that it may not be possible for ICANN to implement such a proposal, should there be support from the Scoping Team to include it in its write up. Thanks and look forward to discussing more about this on Thursday. Best, Brian From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces(a)icann.org<mailto:gnso-accuracy-st-bounces@icann.org>> on behalf of Caitlin Tubergen <caitlin.tubergen(a)icann.org<mailto:caitlin.tubergen@icann.org>> Date: Thursday, July 14, 2022 at 11:55 AM To: "gnso-accuracy-st(a)icann.org<mailto:gnso-accuracy-st@icann.org>" <gnso-accuracy-st(a)icann.org<mailto:gnso-accuracy-st@icann.org>> Subject: [GNSO-Accuracy-ST] Notes and action items - RDA Scoping Team Meeting #34 - 14 July 2022 Action Items 1. Proponents of “stress testing” (ALAC, GAC, IPC, etc.) to provide further information into the dedicated template [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1sScP8MwgDCg4…>, 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-o…> * Any outstanding items? * Confirm deadline for final review * Confirm next steps 1. Confirm action items & next meeting (TBC)

1 0

REMINDER | Meeting invitation | Registration Data Accuracy Scoping Team | Thursday, 21 July 2022 at 14:00 UTC
by Devan Reed July 20, 2022

July 20, 2022

Dear all, The Registration Data Accuracy Scoping Team meeting is scheduled on Thursday, 21 July 2022 at 14:00 UTC for 90 minutes. Please click the link below to join the webinar: https://icann.zoom.us/j/94504686990?pwd=MWc2eXZENk9yN0RqOUUzaGx2eGV0QT09<https://urldefense.com/v3/__https:/icann.zoom.us/j/94504686990?pwd=MWc2eXZE…> Passcode: Vc#0B7$pu8 For Audio only: Or One tap mobile : US: +13017158592,,94504686990#,,,,*4631547480# or +13126266799,,94504686990#,,,,*4631547480# Webinar ID: 945 0468 6990 Passcode: 4631547480 International numbers available: https://icann.zoom.us/u/akRu7JTFd <https://urldefense.com/v3/__https:/icann.zoom.us/u/akRu7JTFd__;!!PtGJab4!pY…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, alternates and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/aIFJD * Check your time zone: https://tinyurl.com/36vhy89k<https://urldefense.com/v3/__https:/tinyurl.com/36vhy89k__;!!PtGJab4!-K2TELK…> ONLY for Members and Alternates * Please join via the above Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and so it is captured in the recording. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form <https://urldefense.com/v3/__https:/forms.gle/GZqMAi4kKDaVP5o66__;!!PtGJab4!…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the Team is aware at any time who is active. Alternate Assignment –wiki page<https://community.icann.org/x/-wC7Cg>. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

ICANN org concerns re "stress testing" proposals -Notes and action items - RDA Scoping Team Meeting #34 - 14 July 2022
by Brian Gutterman July 19, 2022

July 19, 2022

Dear Accuracy Scoping Team Colleagues, With respect to the proposal(s) related to “stress testing” that the group is currently considering and discussing, we wanted to flag that ICANN Org has some considerable concerns about this. Any proposal that suggests that ICANN (or a proposal that ICANN org would ask a third party to do this on its behalf) would enter into domain name registration agreements fraudulently with fake contact info, etc. raises a red flag. Carrying out a stress-test like this may violate many different laws. While we do appreciate and support “outside the box” proposals as we carry out the GNSO instructions and assignments together, we wanted to flag to the group that it may not be possible for ICANN to implement such a proposal, should there be support from the Scoping Team to include it in its write up. Thanks and look forward to discussing more about this on Thursday. Best, Brian From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces(a)icann.org> on behalf of Caitlin Tubergen <caitlin.tubergen(a)icann.org> Date: Thursday, July 14, 2022 at 11:55 AM To: "gnso-accuracy-st(a)icann.org" <gnso-accuracy-st(a)icann.org> Subject: [GNSO-Accuracy-ST] Notes and action items - RDA Scoping Team Meeting #34 - 14 July 2022 Action Items 1. Proponents of “stress testing” (ALAC, GAC, IPC, etc.) to provide further information into the dedicated template [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1sScP8MwgDCg4…>, 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) a) 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-o…> * Any outstanding items? * Confirm deadline for final review * Confirm next steps 1. Confirm action items & next meeting (TBC)

3 4