- GNSO-Accuracy-ST - lists.icann.org

ICANN Zoom room requirements: Zoom Logins: First & Last Name/ Surname Only
by Nathalie Peregrine March 8, 2022

March 8, 2022

Dear all, To ensure transparency of participation in ICANN’s multistakeholder model, please remember to sign in to Zoom sessions using your full name (e.g. First Name + Last Name/Surname). If you are in a session using the webinar format, you will need to first exit the Zoom room prior to rejoining. Please reach out to your support staff if you have any difficulties joining a Zoom session. To rename in a regular Zoom room: 1. Join the meeting. 2. Tap Participants. 3. Hover over your name on the participants list. 4. Click More. 5. Click Rename. 6. Enter the name you desire then click Rename. 7. Your name has now been changed within the meeting. To rename in a webinar Zoom room: 1. BEFORE entering the meeting, and during the login phase, update your Zoom name here: [cid:image001.png@01D83300.B8213430] 1. If you forget to do so, you can always log out of the webinar Zoom room and edit your name upon re-entering. Please contact your support staff if you run into any issues. Thank you! Kind regards, Nathalie

1 0

Level Setting
by Michael Palage March 8, 2022

March 8, 2022

Hello All, I am looking forward to a productive ICANN73 public session tomorrow. I spent the past several days trying to digest all of the exchanges that took place last Thursday. While I think we are close to wrapping up our work on Assignments 1 & 2, I think it would be constructive to quickly level set and make sure we are all on the same page to minimize potential future confusion. Part of my level setting involved going back to the original GNSO Council’s charge to the Scoping Team which asked is there “an agreed definition of registration data accuracy and, if not, consider what working definitions should be used in the context of the Scoping Team's deliberations.” See https://community.icann.org/display/AST/2.+Council+Instructions+to+Scoping+… This task at first blush seems simple enough, but as we have learned there have been several concerns raised in connection with the use of the term “definition” and the meaning of “accuracy.” Therefore, instead of using the term “definition” as proposed by the GNSO Council I propose that we use the phrase “current contractual requirements and enforcement construct.” I believe this should meet the concerns of the RrSG that have repeatedly raised concerns about “providing a definition” and the concerns of the GAC and others about how a definition might bias future discussions. Is there any objection to us using the phrase “current contractual requirements and enforcement construct?” If so please explain your objection and proposed alternative suggestion. Next we need to tackle what I have deemed the accuracy conundrum. The intervention by Stephanie this past week reminded me of some previous research that I was doing which I decided to revisit. I think Stephanie hit the nail on the head when she talked about how “accuracy” to most people conveys a binary choice, e.g. the data is accurate or is the data inaccurate. It is a black or white answer with no room for grey. In fact this seemed to align closely with the RrSG proposed “current contractual requirements and enforcement construct.” If the data collected meets syntactical validation and either the email or phone number was operationally verified, then the data provided by the Registrant was “accurate” per their interpretation of the 2013 RAA. So I decided to spend a couple of hours researching the definition and origins of the word “accuracy” online and with an old school trip to the local library. I believe this definition of the word “accuracy” best describes the conundrum that we as a group find ourselves. noun, plural 1. the condition or quality of being true, correct, or exact; freedom from error or defect; precision or exactness; correctness. 2. Chemistry, Physics. the extent to which a given measurement agrees with the standard value for that measurement. Compare precision (def. 6). 3. Mathematics. the degree of correctness of a quantity, expression, etc. Compare precision (def. 5). Source Dictionary.com Now the first definition “being true, correct, or exact; freedom from error or defect” is a rather high bar, particularly if you are applying this bar to all registration data elements processed like some working group members have advocated. However, that bar is substantially lower if free from defect simply means that the data collected by the Registrar was syntactically correct and a Registrar at a point in time got an affirmative response from either telephone number or an email. Alternatively, the third definition of a “degree of correctness” suggests something other than a binary accurate or inaccurate response. Therefore to help steer our future discussions I would like everyone to answer the following question: Question #1 For purposes of our Working Group the term accuracy should be defined as: [ ] true, correct and free from error; or [ ] degree of correctness; (PICK ONE) I think once we get clarity and/or agreement on these points, we should have a more clearly defined path forward for our post ICANN73 call. Best regards, Michael

7 11

FYI - Latest Developing Board Guidance on RDS Accuracy
by Brian Gutterman March 7, 2022

March 7, 2022

Hi all, FYI As Becky has referenced during our session today, the below was sent to the GAC leadership from Goran yesterday re. some of the latest thinking and discussions of the Board re. registration data accuracy. Best, Brian RE: For GAC Leadership Information – ICANN73 Prep – Latest Board Feedback Planned on Accuracy of Registration Data Dear Manal and GAC Vice-Chairs, As you know, the Board had some productive workshop discussions this weekend regarding continued ICANN org efforts to ensure the accuracy of registration data. As a result of the discussions, further Board guidance has been developed for how to address these issues going forward. The language set forth below has been developed as a guide for further oral discussions the Board may have with community groups during ICANN73. It is likely to be shared Monday during discussions with the GNSO and later in the week during the GAC’s meeting with the ICANN Board. “The ICANN Board first of all would like to highlight its support for continued efforts to ensure the accuracy of registration data. ICANN org continues to advocate for greater clarity from the competent European authorities on several outstanding questions and issues regarding the application of the GDPR to registration data when opportunities arise. The issue of data accuracy is one of the areas that would benefit from greater clarity. In relation to data accuracy, the ICANN Board has requested ICANN org to prepare a number of specific scenarios for which it will consult the EDPB on whether or not ICANN org has a legitimate purpose that is proportionate, i.e., not outweighed by the privacy rights of the individual data subject(s) to request Contracted Parties to provide access to individual records as well as bulk access to registration data in order to review the accuracy of registration data. The ICANN Board is of the view that this clarification will further inform discussions on this topic and will be helpful to address the issue of accuracy, as ICANN org could take further steps like restart the WHOIS ARS. The EC has committed to facilitate ongoing dialogue with the EDPB and European DPAs. We hope the EC will help bring this question to the level of the EDPB. We highlight that the CPs have a responsibility for the accuracy of the data. A Registrant has to provide accurate data to a Contracted Party who has the obligation to confirm that existing accuracy requirements are being met. If a Registrant is found not to meet the obligation to provide accurate data, the registration will be suspended. Furthermore, upon notification by any person of an inaccuracy, including at CPs own initiative, in the contact information associated with a Registered Name sponsored by Registrar, Registrar must take reasonable steps to investigate that claimed inaccuracy. But here is the problem, Registration Data is no longer publicly available which makes it difficult if not impossible to see if the Registrant listed is Mickey Mouse. Even for ICANN org.” Please let me know if I can provide further preparation information for the GAC meeting with the Board later this week. Best, Göran #. #. #

1 0

Proposed Agenda - Accuracy Scoping Team ICANN73 Session on Monday 7 March at 16.30 UTC
by Marika Konings March 4, 2022

March 4, 2022

Dear All, In line with yesterday’s discussion, please find hereby the proposed agenda for the Accuracy Scoping Team’s ICANN73 session: Proposed Agenda: 1. Welcome 2. Introduction to work of the Accuracy Scoping Team & current status 3. Review Gap Analysis Data Collection Proposals (see https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit) * Walk through of proposals * Scoping Team to consider upside, downside and possible next steps for each proposal * Confirm next steps 4. Confirm homework assignment for accuracy current status definition<https://docs.google.com/document/d/1JGdNLjOjhmJnj-iDaGvcVnv1gZ5tQu5C/edit> 5. Opportunity for community questions and input 6. Confirm next steps & next meeting (Thursday 17 March at 14.00 UTC) As a reminder the meeting being held during ICANN73 will take place on Monday, 07 March 2022 at 12:30 local time (16:30 UTC). ICANN73 wiki agenda page: https://community.icann.org/x/xAEiCw. Please be sure you are registered for ICANN73! Zoom participation links will be published 24 hours before the ICANN73 sessions start. For more information on how to participate, visit: https://73.schedule.icann.org/attend. Best regards, Caitlin, Berry and Marika

1 0

Notes and action items - RDA Scoping Team Meeting #20 - 3 March 2022
by Caitlin Tubergen March 3, 2022

March 3, 2022

Dear RDA Scoping Team Members, Please find below the notes and action items from today’s meeting. As a reminder, the next meeting will be on Monday, 7 March at 16:30 UTC. Please remember to registrar for ICANN73 in order to access the details for this session. Best regards, Marika, Berry, and Caitlin -- Action Items 1. In advance of the ICANN73 RDA Scoping Team Session on Monday at 16:30 UTC, RDA Scoping Team Members to review the Gap Analysis Proposal Review. (https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit) Note: this document was compiled by Support Staff in an effort to distill the proposals made by Scoping Team Members, including upsides and downsides noted by either the proposer or other team members in subsequent discussions. The document is not meant to restrict the group into choosing one proposal, but rather, the group should review all proposals and see which proposals provide a viable path to forward progress. Registration Data Accuracy Scoping Team – Meeting #20 Thursday 3 March at 14.00 UTC 1. Welcome & Chair Updates (10 minutes) * ICANN73 Working Session proposed agenda: • Brief overview of background and current status • Continue deliberations (e.g., accuracy working definition, review of existing data sources) * Will go over table of pros, cons, etc. * Marc A. suggested this idea during the last meeting – to look through the input received by different groups regarding how data could be obtained. Support Staff went through the input and distilled a number of specific proposals. In some cases, similar proposals are grouped together. When upsides and downsides were identified either in the proposal or in subsequent discussions, these have been included. Staff has also proposed next steps in some instances. * Note: the document isn’t designed as a “choose one” – multiple proposals could be chosen; the team is now asked to look at which proposal(s) could be viable * Action item: RDA Scoping Team to review the document (https://docs.google.com/document/d/1sScP8MwgDCg4yvFNAYwQVql7DQob60vX/edit) in advance of Monday’s ICANN73 session. * This document is a good way of getting into the gap analysis. • Q & A session 1. Measurement of accuracy (10 minutes) * Review remaining input received on google doc [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/11msexuoqWSUs…>, see page 25 - How and by whom can it be measured whether current goal(s) of existing accuracy requirements are met? * ISPCP – * RAA spells out accuracy requirements – build on this * Build on third party reports on inaccurate data * Could also collect and compare different data points with other registrars’ data points * Some of this work is harmed by the lack of DPAs – ICANN will not be able to see the actual data, but the methodology can be agreed upon and ICANN audits could confirm if the registrar is applying the correct methodology * There is likely a joint controller situation b/w ICANN and CPs, and JCA could spell our roles and responsibilities with respect to accuracy * When it comes to rectifying data, registrars have the largest pool of data to assist with this * Role of resellers: probably have been one of the overlooked and unaccounted links in the domain name ecosystem * Re: red herring – a lot can be done by drafting additional data processing agreements, but what are we trying to achieve? During Phase 1 of EPDP, there is a recommendation for ICANN and CPs to come up with draft protection arrangements. For a DPA, you can allocate functional responsibilities for the joint controllers. * Confirm next steps 1. Accuracy working definition / construct (30 minutes) * Review input received (see https://docs.google.com/document/d/1JGdNLjOjhmJnj-iDaGvcVnv1gZ5tQu5C/edit[d…<https://urldefense.com/v3/__https:/docs.google.com/document/d/1JGdNLjOjhmJn…>) * For clarity, the 2013 RAA also includes all consensus policies * ICANN Compliance did respond to the draft construct; the response did not change the requirements, but rather, explains when the requirements are tested * Based upon the requirements set forth in 2013 RAA, what are potential changes or enhancements for the group to consider? * Thought team was asked to comment on the definition proposed by the RrSG – seems that now we are discussing how the 2013 RAA is currently implemented. These are different things, and members may have responded differently based on what they thought the assignment was. * There is an inherent confusion in the highlighted assignment: there is a difference b/w what is currently required contractually and what is or what should be a working definition as a task of this accuracy scoping team * Should consider using the term data quality instead of data accuracy – accuracy has a binary quality – what this group is talking about is whether it is formatted correctly, updated in a reasonable timeframe, etc. This implies a role for ICANN that has yet to be defined in a DPA through the parties. ICANN has made progress in how it sees itself, but the details of that are still muddy since the 2013 RAA was hatched without any regard to data protection law. Some issues are on the other side of the picket fence. If this were a negotiated policy, ICANN could argue that it is not a controller. * The problem is when we talk about accuracy and requirements, these are not the same thing. To be accurate to contactability – when Whois was started, the goal was contactability, so accuracy seems to be can someone be contacted. The requirements that have been put in place to achieve the accuracy are not accuracy in and of themselves. Are these contacts contactable? Think what this question was intended to mean: Are there additional requirements that the RrSG did not include that ICANN org included in their comments? * Thought working definition meant what the current definition is, not necessarily what it should be. Once current definition is established, the team can review if changes are needed * The group has struggled with the use of working definition. Important to take note that reference to a working definition is part of the first assignment – this gets to the understanding of the current situation – this allows the group to move to the second assignment – how is this currently measured? There needs to be agreement on what the current requirements of enforcement are. Rrs came forward with current requirements; ICANN responded. Having looked at the proposals here, some are jumping ahead to what they would like the definition to be, but this is about what is currently required and enforced so that we can use that as the benchmark over whether current requirements are being met. * To facilitate and avoid confusion – refer to it as a current description of obligations * When this group started, the RrSG put forward a definition based upon interpretations of 2013 RAA requirements. Yesterday, in a message, started with a presumption that this is a binary process. One definition of accuracy is binary – it is either accurate or inaccurate. Syntactical and operational accuracy of one element. Feedback from Compliance regarding its standard operation procedures – this was not just limited to syntactical and operational accuracy. In response to Mickey Mouse, the term “patently false” was used. What this group needs to be focusing on – what is the grey area here? That is part of the gap analysis. This analysis will help guide the group through assignments 3 and 4. The group is not excluding here; instead, taking the analysis and gathering what the current state is, see if there is a gap, and provide a path forward. * Current RAA has not been revised to look at whether requirements comply with the GDPR – when will that be done and how? Is that within the scope of this team? Do not think so. * For example, identity accuracy is a difficult term, it is not a requirement for registering a domain name. Do not need identity accuracy to register a domain name. * Main requirement for CPs is to accurately process data as it is inputted by the registrants. * There is no absolute bar against certainty about the identity of a registrant – that is a current decision that has been made, and it’s a perfectly rational decision, but it’s also a perfectly rational position to make requirements regarding who, in fact, the registrant is. Trying to draw a very firm line that precludes stricter requirements is a policy discussion. * This scoping team was not looking at what GDPR requires – what we have today is currently above GDPR * There appears to be a global platform that permits anyone to be anyone else without any preventative measures taken – it’s as if a blind eye is turned to domain registration. Why should accuracy not include truth? * Accuracy, in and of itself, is a registrant obligation. Registrars have to act upon inaccurate information when there is evidence of this. No one is saying the information is accurate other than the registrant. * The purpose is contactability; now others are suggesting it’s contactability and identity. Accuracy today is geared toward contactability. * The comment that ID accuracy would promote crime is incorrect – as recognized in early documents in 2000 and 2005 clearly dealt with identity validation – not sure where this got lost along the way. The fact is that everything has evolved since 2013 – criminals and cyber-squatters have evolved – there is a need for this policy to evolve to create preventive aspect from filing fraudulent registration data. * These comments should be discussed later and not here – some have noted that questions would have been answered differently if they understood the assignment better. * As the group goes forward, would be helpful if groups can update what their answer should have been. * RDA Scoping Team Members to update their answers based on the updated question: Based on the feedback from ICANN org, what updates, if any, should be made to the RrSG proposed “current state” definition so that it accurately describes the current requirements and enforcements of these requirements. (Note: question was updated to clarify the original assignment.) * Confirm next steps 1. Review of existing data sources (30 minutes) * See compilation<https://community.icann.org/download/attachments/173703498/Gap%20analysis%2…> developed by Staff Support Team as well as overview of ARS Cycle 6 findings<https://community.icann.org/download/attachments/173703498/From%20the%20Pha…> * Team to consider these existing data sources and role in assessing existing current situation & identifying possible gaps * Confirm next steps 1. Additional questions for ICANN Compliance (10 minutes) (see https://docs.google.com/document/d/1arlKdQkbRkE1LuurmDdd-PZP184_AdFm/edit?p… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1arlKdQkbRkE1…>) * Introduce questions (Alan, Michael) * EPDP Team input * Confirm next steps 1. Confirm action items & next meeting (ICANN73 - Monday 7 March at 16.30 UTC)

1 0

IMPORTANT - Session change ICANN73: New gTLD Subsequent Procedures: Operational Design Phase
by Julie Bisland March 3, 2022

March 3, 2022

Dear all, ⚠️ Due to scheduling conflicts the ICANN73 session New gTLD Subsequent Procedures: Operational Design Phase will take place at a different time and date. ⚠️ Previously scheduled for Wednesday 9 March 2022 at 09:00 am local time (13:00 UTC), it will now take place on Monday 7 March 2022 at 12:30 local time (16:30 UTC). To update your calendars please follow the below steps: 1. Remove the entry for New gTLD Subsequent Procedures: Operational Design Phase on Wednesday 9 March 2022 09:00 am local time. 2. If you had already selected the new gTLD Subsequent Procedures: Operational Design Phase entry in your “My Agenda” on the ICANN73 website, you will not need to re-select it. You will however need to export that session once again to your own calendar. 3. Please refer to the attached “How to Get Organised” email to refresh your memories on how to download sessions! Please reach out to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> if you have any questions. Kind regards, Nathalie

1 0

Meeting invitation | Registration Data Accuracy Scoping Team | Thursday, 17 March 2022 at 14:00 UTC
by Terri Agnew March 3, 2022

March 3, 2022

As a reminder the meeting being held during ICANN73 will take place on Monday, 07 March 2022 at 12:30 local time (16:30 UTC). * ICANN73 wiki agenda page: https://community.icann.org/x/xAEiCw * Please be sure you are registered for ICANN73! * Zoom participation links will be published 24 hours before the ICANN73 sessions start. For more information on how to participate, visit: https://73.schedule.icann.org/attend [73.schedule.icann.org]<https://urldefense.com/v3/__https:/73.schedule.icann.org/attend__;!!PtGJab4…> Find below the meeting details for the call taking place after ICANN73. ************************************************************* Dear all, The Registration Data Accuracy Scoping Team meeting is scheduled on Thursday, 17 March 2022 at 14:00 UTC for 60 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 [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/6RQiCw * Check your time zone: https://tinyurl.com/3sse849u ONLY for Members and Alternates * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. * 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, 03 March 2022 at 14:00 UTC
by Terri Agnew March 3, 2022

March 3, 2022

**Starting in 15 minutes Dear all, The Registration Data Accuracy Scoping Team meeting is scheduled on Thursday, 03 March 2022 at 14:00 UTC for 60 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 [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/nxIiCw * Check your time zone: https://tinyurl.com/2p8mvfh8 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/2p8mvfh8__;!!PtGJab4!v4Ln_GB…> ONLY for Members and Alternates * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. * 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

Re: [GNSO-Accuracy-ST] Potential Additional Questions to ICANN Org
by Michael Palage March 2, 2022

March 2, 2022

Sarah, I think your response actually hits the nail on the head regarding the concerns of the BC, IPC, ALAC, SSAC, and GAC. When I get my annual notification from GoDaddy at my email address, I do nothing because I know the data is accurate and I know there is no need to respond. I think there is group consensus that this is the right outcome. However, when malicious registrant uses mickey.mouse(a)protonmail.com <mailto:mickey.mouse@protonmail.com> to register an abusive domain name, and their Registrar sends an annual email that does not bounce, under the contractual requirements in the 2013 RAA that data is deemed accurate. I think that is the break down between both camps. Further complicating matters is that a point in time operational verification of an email could have happened years in the past. Finally, I think the BC, IPC, ALAC, SSAC, and GAC also have a trust issue with the accuracy of the registrant data depending upon a malicious registrant being expected to tell the truth. Thanks for your contribution and moving this discussion forward. Best regards, Michael From: Sarah Wyld <swyld(a)tucows.com> Sent: Wednesday, March 2, 2022 10:42 AM To: michael(a)palage.com; 'Roger D Carney via GNSO-Accuracy-ST' <gnso-accuracy-st(a)icann.org> Subject: RE: [GNSO-Accuracy-ST] Potential Additional Questions to ICANN Org Hi Michael, Indeed, if the data is accurate, the RNH has no obligation to respond. If it’s inaccurate they must update it. For all we know, you don’t check that account because it forwards to your primary email address. -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they <mailto:swyld@tucows.com> swyld(a)tucows.com From: Michael Palage <mailto:michael@palage.com> Sent: March 2, 2022 9:44 AM To: 'Sarah Wyld' <mailto:swyld@tucows.com> ; 'Roger D Carney via GNSO-Accuracy-ST' <mailto:gnso-accuracy-st@icann.org> Subject: RE: [GNSO-Accuracy-ST] Potential Additional Questions to ICANN Org Hello Sarah, Please correct me if I am wrong but the current requirement is for Registrars to send an annual email reminder, however, there is NO requirement for the Registrant to affirmatively respond. Moreover, if there is NO bounce the Registrar is permitted to assume that all is good. When I get my annual GoDaddy email I largely ignore it, and sometimes find it in my spam folder. Therefore, if I was to register a domain name with the email MickeyMouse(a)protonmail.com <mailto:MickeyMouse@protonmail.com> and never check that email account, as long as the Registrar NEVER received a bounced email it would be considered accurate under your reference to the annual email notification. Would you agree with this statement? I guess the more important insight is what are the Registries and Registrars participating in the malicious v. compromises domain name study doing to make this determination. Could the Registrars and Registries perhaps share any insight on how this research is being undertaken? Best regards, Michael From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces(a)icann.org <mailto:gnso-accuracy-st-bounces@icann.org> > On Behalf Of Sarah Wyld Sent: Wednesday, March 2, 2022 9:27 AM To: Roger D Carney via GNSO-Accuracy-ST <gnso-accuracy-st(a)icann.org <mailto:gnso-accuracy-st@icann.org> > Subject: Re: [GNSO-Accuracy-ST] Potential Additional Questions to ICANN Org Hello all, There’s a lot going on in this thread which I am not able to respond to at this time, but I do want to respond to one specific suggestion: > Would it be that much of an additional burden to ask the Registrants if the information contained in the Whois/RDDS is accurate and share those results with the group? There is an annual Whois data confirmation email sent out to all registrants, which includes the current registration data and asks them if it is accurate, along with an explanation that they are required to provide accurate and up-to-date information and instructions for how to update it if necessary. Does that not match up with this idea of asking Registrants if their Whois info is accurate? Thanks, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they <mailto:swyld@tucows.com> swyld(a)tucows.com From: Michael Palage <mailto:michael@palage.com> Sent: March 2, 2022 9:10 AM To: 'Becky Burr' <mailto:BBurr@hwglaw.com> ; 'STROUNGI Melina' <mailto:Melina.STROUNGI@ec.europa.eu> ; 'Becky Burr' <mailto:becky.burr@board.icann.org> Cc: gnso-accuracy-st(a)icann.org <mailto:gnso-accuracy-st@icann.org> Subject: Re: [GNSO-Accuracy-ST] Potential Additional Questions to ICANN Org Hello Becky, In my capacity as the Chair, I view my responsibilities as trying to balance the respective perspectives of all participants and making sure that we document all of these perspectives in our work product. As noted before, I would like to avoid some of the holes identified in the SSAD ODA, by making sure that we look at all sides of issues (both popular and unpopular). I think most will agree with me, that there have been some deeply held and divergent viewpoints that were crystal clear at the start of this Group’s work, see https://mm.icann.org/pipermail/gnso-accuracy-st/attachments/20211005/46ce22… I think it is fair to characterize the Registrar’s position as follows: the 2013 RAA provides a black and white guidance as to the term accuracy; recent ICANN Compliance reports indicate that there are a de minimis number of accuracy complaints; therefore there is no problem let’s move on. I also think it is fair to characterize the BC, IPC, ALAC, SSAC and GAC respective positions as the 2013 RAA definition is over narrow; the recent ICANN Compliance reports are under-reporting inaccuracy because legitimate third party access has largely gone dark, therefore we need to reinitiate some type of accuracy survey to see the scope of the problem (if any) and propose a new definition (if necessary). So as Chair, I started out with the proposition that the 2013 RAA was a rebuttal status quo baseline for defining accuracy. Initially, there were several groups that rebutted that definition. In fact, the push back was so hard we did not even use the term “definition” for a couple of weeks. However, after ICANN Compliance provided their feedback it was clear that the scope of accuracy was not simply a 2013 RAA black and white syntactical and operational exercise. My job as Chair was then to help define the scope of that “grey” for purposes of our working definition as well as potential studies that might be undertaken to help document any accuracy problem. In response to calls from a number of members that wanted to restart the ARS, which was unilaterally suspended by ICANN Org after the GDPR went into effect, my job as Chair was to help find a potential middle ground if possible. While being respectful of contracting parties data privacy concerns, including the lack of no DPA with ICANN, I wanted to find the optimal path forward for a potential new ARS that would be in compliant with Article 6.1.(f) of the GDPR: processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. So instead of processing data from a universe of over 200 million gTLD domain registrations, I thought ICANN Org would be able to maximize its legitimate interest (while also taking into account the interests of the registrant) by focusing on a much narrower class of domain names associated with documented DNS abuse. Now there is almost universal recognition that there is a DNS Abuse problem, see DNS Abuse Institute, topDNS, Global Cyber Alliance, EU DNS Abuser Report, and CoCCA DSI. In fact the Registries and Registrars are both supportive of the upcoming DNS Abuse session that will undertake an analysis between maliciously registered domain names and compromised domain names. What I find odd is the almost universal support of Registries and Registrars to look at a DNS Abuse subset of domains to make a “malicious / comprised” determination, yet the mere suggestion that this same subset of data could be analyzed through the lens of “accuracy” is somehow verboten. I think you would agree with me that to an objective outside observer, the Registrar pushback appears less likely tied to statistical purity and potentially more likely because of what those results may reveal. To those Registries and Registrars that may be participating in the malicious v compromised domain name study, I assume you are contacting Registrants. Would it be that much of an additional burden to ask the Registrants if the information contained in the Whois/RDDS is accurate and share those results with the group? In respond to your comment about “understand[ing] the interest in asking ICANN about its legal advice, but I am skeptical that will prove particularly enlightening.” Perhaps if ICANN Legal just provided a legal basis to the community instead of making self-serving proclamations about its role that would help out from a trust building exercise. These are the concerns that I heard on the call last week when Thomas raised the issue about the lack of a DPA and Stephanie’s repeated request for ICANN to file a DPIA over the past several years. Additionally, there have been other members that have raised similar concerns, so as Chair I will continue to push for these voices within the Working Group to be heard and to obtain the data for this group to make a factual determination. Best regards, Michael From: Becky Burr <BBurr(a)hwglaw.com <mailto:BBurr@hwglaw.com> > Sent: Tuesday, March 1, 2022 1:29 PM To: 'STROUNGI Melina' <Melina.STROUNGI(a)ec.europa.eu <mailto:Melina.STROUNGI@ec.europa.eu> >; 'Becky Burr' <becky.burr(a)board.icann.org <mailto:becky.burr@board.icann.org> >; michael(a)palage.com <mailto:michael@palage.com> Cc: gnso-accuracy-st(a)icann.org <mailto:gnso-accuracy-st@icann.org> Subject: Re: [GNSO-Accuracy-ST] Potential Additional Questions to ICANN Org Re "clearing the bar" for legitimate interests not outweighed by the data subjects' privacy rights, what I think is probably not particularly relevant. In the end, it will fall to the party granting access to the data (i.e., the Contracted Party) to make that call. But in general I do agree that processing based on a specific cause for concern will usually be easier to justify under GDPR. That said, I do agree with the CPs who expressed concern about skewed results. If we want to actually understand the volume and nature of inaccuracy across the entire data set and we wanted an answer that cannot be dismissed by one group of stakeholders or another, then a proactive audit that looks at registrant data across domains and across sponsoring registrars is likely necessary. I'm not a statistics guru, but I suspect you could design a study that looked at a subset of the data, but looking only at the subset of data that has already been identified as inaccurate seems very problematic to me. I understand the interest in asking ICANN about its legal advice, but I am skeptical that will prove particularly enlightening. While I'd prefer to use the actual language from the 6.1(f) exception (legitimate interests not overridden by the interests/rights/freedoms of the data subject) using "under the GDPR" rather than "proportionate" also works. 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 < <mailto:gnso-accuracy-st-bounces@icann.org> gnso-accuracy-st-bounces(a)icann.org> on behalf of Michael Palage < <mailto:michael@palage.com> michael(a)palage.com> Sent: Tuesday, March 1, 2022 12:14:56 PM To: 'STROUNGI Melina'; 'Becky Burr' Cc: <mailto:gnso-accuracy-st@icann.org> gnso-accuracy-st(a)icann.org Subject: Re: [GNSO-Accuracy-ST] Potential Additional Questions to ICANN Org Hello Becky, I think we are in agreement that the processing/disclosing of non-public PII involves a two part test: legitimate interest and proportionate interest. As you and others may recall this is why I have proposed that any limited restart of the ARS program involve a sampling of the data from the monthly DAAR reporting. >From a legitimate interest standpoint, the domains reported in DAAR (e.g. malware, phishing, SPAM) are clearly involved in illegal activity in most jurisdictions. I do not see any situation in which ICANN would not easily clear this bar. Would you agree? With regard to the proportionality (balancing test), as will be discussed in the upcoming ICANN73 meeting, there are two types of potential registrations involving abusive domains, maliciously registered domain names and compromised domain names. From a “balancing test” ICANN easily clears any proportionality bar when looking at maliciously registered domain names. Would you agree? With regard to compromised domains, while this balancing test is a little more substantive than with malicious domain names, I believe this is a bar that ICANN Org and the Contracting Parties should easily be able to clear in almost every scenario. Unlike the old Whois/RDDS that made registrant data publicly available for scraping, this proposed audit would be limited to a restrictive number of parties, ICANN, third-party vendor, and contracting party. Would you agree? I am also in agreement with your comments distinguishing between targeted processing/disclosure versus bulk processing/disclosure. This is why I made the specific proposal to restart ADR on a limited scale targeting just Abusive Domain Names reported via DAAR. This targeted focus should address your bulk processing claims. Would you agree? What I found disappointing when I brought this to the consideration of the entire Working Group is that several Contracting Parties opposed this potential reasonable path forward because they thought that this would potentially skew the accuracy results. These Contracting Parties instead were adamant that any survey would need to involve the entire data set. My concern with this position is that any demands to include the entire set is potentially a non-start for processing in a legal compliant manner per the GDPR. In order to further explore your claim that the DPA is a red hearing, perhaps the Registry and Registrars representatives could go back to their respective stakeholders groups and ask for scenarios in which they would be willing to transfer data to ICANN or a designated vendor to check the accuracy of data. Would you agree with me that this data point would be extremely helpful in resolving potential ambiguity between the parties and their respective roles? In closing, I want to thank both Becky and Melina for your respective feedback and I look forward to additional constructive feedback going forward. Best regards, Michael From: STROUNGI Melina < <mailto:Melina.STROUNGI@ec.europa.eu> Melina.STROUNGI(a)ec.europa.eu> Sent: Tuesday, March 1, 2022 11:13 AM To: Becky Burr < <mailto:becky.burr@board.icann.org> becky.burr(a)board.icann.org>; <mailto:michael@palage.com> michael(a)palage.com Cc: <mailto:gnso-accuracy-st@icann.org> gnso-accuracy-st(a)icann.org Subject: RE: [GNSO-Accuracy-ST] Potential Additional Questions to ICANN Org Dear Becky, all, many thanks for your additional suggestions. my two cents on the below: I support the distinction proposed by Becky, but would recommend replacing ‘proportionate’ with ‘under the GDPR’ so we are fully covered. The original question raised was “Is ICANN able to access registration data under the GDPR on the basis that it has a legitimate interest in checking the accuracy of the data? “ The reference alone to the GDPR means that indeed the balancing test has been taken into account. As you rightly point out the GDPR requires a balancing test when ‘legitimate interests’ is used as a legal basis. So in my view as long as there is a reference to the GDPR there is no need to explicitly add the proportionate part. It is already implied. Plus, a more general reference is more encompassing in the sense that it takes into account the totality of the balancing test (i.e., data subjects’ interests etc.) Having said that I am all supportive of asking all of these questions (in general I am in favor of asking as many questions as we can think of as this is at the heart of our scoping tasks), but I would maintain –on top of what you suggest –the specific question on whether ICANN ever received or plans to receive legal advice on this particular topic. If I recall correctly this had been discussed in our accuracy scoping meeting of 17 February and was proposed as a question to be addressed to Brian so he can forward it to ICANN compliance. In order to be able to progress with our discussions, it is important to know where exactly ICANN would base their assessment on these questions (i.e., whether they have received specific in-house or external legal advice, including but not limited to any correspondence with the EDPB). I have now tried to integrate Becky’s suggestion to the original questions. Hope this helps. Question 1 1. Does ICANN have a legitimate interest under the GDPR in accessing domain name registration data in response to complaints that the data is inaccurate? Has ICANN ever received or plans to receive legal advice on this particular topic? 2. Does ICANN have a legitimate interest under the GDPR in proactively acquiring bulk access to domain name registration data to undertake an accuracy audit, even with respect to data for which it has no basis to question its accuracy? Has ICANN ever received or plans to receive legal advice on this particular topic? Question 2 For either scenario a or b under question 1: Does ICANN believe that a Data Protection Agreement between itself and the Contracted Parties is a necessary legal requirement for requesting and receiving this data, and if so for what legal reason? What happens if the registrar receiving the access request disagrees with ICANN's application of the balancing test, i.e., does ICANN have the contractual authority to enforce its access request? Best, Melina From: GNSO-Accuracy-ST < <mailto:gnso-accuracy-st-bounces@icann.org> gnso-accuracy-st-bounces(a)icann.org> On Behalf Of Becky Burr Sent: Tuesday, March 1, 2022 4:27 PM To: <mailto:michael@palage.com> michael(a)palage.com Cc: <mailto:gnso-accuracy-st@icann.org> gnso-accuracy-st(a)icann.org Subject: Re: [GNSO-Accuracy-ST] Potential Additional Questions to ICANN Org Michael - Respectfully, and without taking a position on whether these questions are relevant or timely, I think the questions need to be more nuanced to produce useful answers. 3. Does ICANN have a legitimate and proportionate interest in accessing individual registration records in response to credible complaints that the data is inaccurate? If so, is a DPA required to access data in such situations? What happens if the registrar receiving the access request disagrees with ICANN's application of the balancing test, i.e., does ICANN have the contractual authority to enforce its access request? 4. Does ICANN have a legitimate and proportionate interest in proactively acquiring bulk access to registrant data to undertake an accuracy audit, even with respect to data for which it has no basis to question its accuracy? If so, is a DPA necessary to do so? What happens if the registrar receiving the access request disagrees with ICANN's application of the balancing test, i.e., does ICANN have the contractual authority to enforce its access request? It is important to keep in mind that a legitimate interest is necessary but not sufficient under GDPR. The processing necessary to satisfy a legitimate interest must be proportionate, i.e., not outweighed by the privacy rights of the individual data subject(s). As a result, the two situations (access to a single record based on reasonable grounds to believe the data is inaccurate v. proactive access without individualized suspicion) are quite different from a data protection perspective, with the first being far less complicated to defend. In addition, a CP's contractual obligations, e.g., under the RAA, may be different in those situations. FWIW, I think the DPA issue is a bit of a red herring here. Presumably, ICANN's requests for one-off data can be handled in the same way that anyone else's access request is handled, e.g., if the data is to be transferred outside of the EU by imposing controller to controller Standard Contractual Clauses as the terms and conditions of such access on a case-by-case basis. If the EDPB were to confirm that ICANN's bulk access to data for proactive checking was legitimate and proportionate, it's clear to me that a narrowly focused DPA between ICANN and CPs applicable to data access for the specific purpose of checking accuracy (e.g., prohibiting onward transfer, etc.) could be crafted. The real question is whether (i) the temp spec /epdp phase 1 policy obligating CPs to provide reasonable access for legitimate and proportionate purposes encompasses bulk access or (ii) some other provision of the agreements produces an obligation to provide bulk access. Apologies for being pedantic here. None of us can say with any certainty what GDPR does or does not permit as that determination is ultimately made by individual data protection authorities and/or the EDPB. We are asking ICANN for its views on what GDPR would permit in specific circumstances, so the relevant circumstances should be articulated precisely to produce useful answers. b On Thu, Feb 24, 2022 at 5:12 PM Michael Palage <michael(a)palage.com <mailto:michael@palage.com> > wrote: Hello Everyone, Over the past couple of weeks there has been a recurring theme in our calls and in some of the side discussions that I have had with some members regarding about how the potential lack of a Data Processing Agreement between ICANN Org and the Contracting Parties might negatively impact our future work and/or recommendations. Therefore I would like to propose to the group for their consideration the following additional questions that we may want to propose to ICANN Org as we continue our work: • “Is ICANN able to access registration data under the GDPR on the basis that it has a legitimate interest in checking the accuracy of the data? Has ICANN ever received or plans to receive legal advice on this particular topic? • Does ICANN believe that the Data Protection Agreement between itself and the Contracted Parties is a necessary legal requirement for requesting and receiving this data, and if so for what legal reason?" As always I welcome any thoughts and or considerations? Best regards, Michael _______________________________________________ GNSO-Accuracy-ST mailing list GNSO-Accuracy-ST(a)icann.org <mailto:GNSO-Accuracy-ST@icann.org> https://mm.icann.org/mailman/listinfo/gnso-accuracy-st <https://urldefense.com/v3/__https:/mm.icann.org/mailman/listinfo/gnso-accur…> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://urldefense.com/v3/__https:/www.icann.org/privacy/policy__;!!DOxrgLB…> ) and the website Terms of Service (https://www.icann.org/privacy/tos <https://urldefense.com/v3/__https:/www.icann.org/privacy/tos__;!!DOxrgLBm!U…> ). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

3 5

RDA_ST // 28 Feb 2022 Project Package
by Berry Cobb March 2, 2022

March 2, 2022

Dear Scoping Team, Please find a link below to project package for the RDA_ST (28 Feb 2022). This package is a snap-shot at the close of each month and developed by the leadership team to report on the working group’s activities and status of the project. It is also distributed to the GNSO Council to keep them informed as managers of the project. The package is deposited on the wiki so that we can track access statistics. Link: https://community.icann.org/x/PQ2HCg 1. Page 01 – Summary dashboard 2. Page 02 – Project Sitrep – an extract from the Council’s Project List 3. Page 03 – Group roster 4. Page 04,05 – Work and activity metrics 5. Page 06 – Project Plan, Gantt chart 6. Page 07 – Work plan & Action items for the period Please let us know if you have questions. Thank you. B Berry Cobb Policy Development - Portfolio Manager Internet Corporation for Assigned Names and Numbers (ICANN) berry.cobb(a)icann.org

1 0