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

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

March 2, 2022

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> 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> 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.

2 2

Potential Additional Questions to ICANN Org
by Michael Palage March 2, 2022

March 2, 2022

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

8 10

Proposed Agenda - Registration Data Accuracy Scoping Team meeting #20 on Thursday 3 March at 14.00 UTC
by Marika Konings March 2, 2022

March 2, 2022

Dear All, Please find below the proposed agenda for the next Registration Data Accuracy Scoping Team meeting which is scheduled for Thursday 3 March at 14.00 UTC. As a reminder, for those who have not done so yet: 1. RDA Scoping Team Members to review the definition/document provided by Staff Support (https://docs.google.com/document/d/1JGdNLjOjhmJnj-iDaGvcVnv1gZ5tQu5C/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1JGdNLjOjhmJn…>), which includes the Rr-provided accuracy definition augmented by the feedback from Contractual Compliance. Groups to include proposed edits or suggestions into the Google Doc by Wednesday, 2 March. Best regards, Caitlin, Berry and Marika 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) · Q & A session 1. Measurement of accuracy (10 minutes) * Review remaining input received on google doc<https://docs.google.com/document/d/11msexuoqWSUsFj8ZjVvWF-XHpcMJntWH/edit>, see page 25 - How and by whom can it be measured whether current goal(s) of existing accuracy requirements are met? * Confirm next steps 1. Accuracy working definition / construct (30 minutes) * Review input received (see https://docs.google.com/document/d/1JGdNLjOjhmJnj-iDaGvcVnv1gZ5tQu5C/edit) * 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…) * Introduce questions (Alan, Michael) * EPDP Team input * Confirm next steps 1. Confirm action items & next meeting (ICANN73 - Monday 7 March at 16.30 UTC)

2 1

**REMINDER** Meeting invitation | Registration Data Accuracy Scoping Team | Thursday, 03 March 2022 at 14:00 UTC
by Julie Bisland March 2, 2022

March 2, 2022

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

ICANN73 Virtual Community Forum | Guidelines for Speakers
by Devan Reed March 1, 2022

March 1, 2022

Dear all, As we are just a week away from the ICANN73 Virtual Community Forum, the ICANN Language Services Team has created a document to serve as a guideline for speakers. As a reminder, GNSO-supported ICANN meetings do not use interpretation services. However, the reminders and pointers included are useful for all. Thank you! Kind regards, Devan

1 0

Additional questions for ICANN Org
by Alan Greenberg Feb. 25, 2022

Feb. 25, 2022

I am submitting the following five questions to ICANN Compliance. Alan Greenberg, Member representing the ALAC The 2013 RAA Whois Accuracy Program Specification section 4 requires a Registrar take certain actions if it has any information that specific RDDS fields are wrong (fields references are any of the name, postal address, e-mail address, voice telephone number, and (where available) fax number). The example given in section 4 of having such information is: “Registrar receiving a bounced email notification or non-delivery notification message in connection with compliance with ICANN's Whois Data Reminder Policy or otherwise”. Question 1: In the view of ICANN Compliance, does this example apply only to Registrars who happen to monitor such email bounce or non-delivery notifications, or are Registrars obliged to do such monitoring? Question 2: If a Registrar is obliged to monitor such email notification of non-delivery, are they similarly required to monitor other delivery methods (such as postal mail failure to deliver, or a message to through the Registrar’s domain management portal never being viewed)? Question 3: If a Registrar is obliged to do such monitoring, does ICANN Compliance audit this requirement? Section 4 goes on to require that “Registrar must verify or re-verify, as applicable, the email address(es) as described in Section 1.f…” Question 4: With respect to the reference to “email address(es)”, since the information about inaccuracy may be about any of the name, postal address, e-mail address, voice telephone number, and (where available) fax number, is the Registrar only required to verify or re-verify the email addresses (even if the inaccuracy was in respect to one of the other fields)? If other fields are included, please be specific as to what fields must be verified or re-verified. Question 5: The ICANN Org comments on the RrSG definition of accuracy saying that accuracy requirements are not limited to syntactical and operational accuracy implies that it may also include the requirement that the field contents are in fact associated with the RNH, and lacking such association, they may be deemed inaccurate. Is this an accurate reading of the ICANN Org comment, and if not, please explain just what the characteristics are that might make such fields inaccurate (in cases which are not as blatant as Mickey Mouse residing on Main Street of Disneyland)?

4 7

Notes and Action Items - Registration Data Accuracy Scoping Team Meeting #19 Thursday 24 February
by Marika Konings Feb. 24, 2022

Feb. 24, 2022

Dear All, Please find below the notes from today’s Registration Data Accuracy Scoping Team meeting. As a reminder, for those who have not done so yet: 1. RDA Scoping Team Members to review the definition/document provided by Staff Support (https://docs.google.com/document/d/1JGdNLjOjhmJnj-iDaGvcVnv1gZ5tQu5C/edit [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1JGdNLjOjhmJn…>), which includes the Rr-provided accuracy definition augmented by the feedback from Contractual Compliance. Groups to include proposed edits or suggestions into the Google Doc by Wednesday, 2 March. Best regards, Caitlin, Berry and Marika Registration Data Accuracy Scoping Team – Meeting #19 Thursday 24 February at 14.00 UTC 1. Welcome & Chair Updates (5 minutes) * Due to conflict with Policy Update this meeting is scheduled for 60 minutes. * Thanks to all for doing homework in preparation for this meeting. 1. Measurement of accuracy (20 minutes) * Review remaining input received on google doc<https://docs.google.com/document/d/11msexuoqWSUsFj8ZjVvWF-XHpcMJntWH/edit>, see page 25 - How and by whom can it be measured whether current goal(s) of existing accuracy requirements are met? * Confirm next steps * See BC input in the google doc Comments: * Input is based on assumptions not facts. * Problematic to have ICANN org review the data as that would require data transfer to the US which may be legally difficult. * Focus is on a very small sub-set of registrations – majority of registrations are not abusive. How can that be demonstrated? If there is data available it should be provided. * Either there is a general problem that needs to be addressed or not. Focusing on a sub-set shouldn’t be the objective. * Transfers to US could be prevented by using ICANN office in Brussels. * If policy needs to be changed, there is a need to demonstrate that there is a problem, not the other way around. See ARS Cycle 6 Report (https://whois.icann.org/sites/default/files/files/whois-ars-phase-2-report-…) From the report: We present here the key takeaways from the findings: Ability to Establish Immediate Contact * Ninety-eight percent of records had at least one email or phone number meet all operability requirements of the 2009 RAA, which implies that nearly all records contain information that can be used to establish immediate contact. Only two percent of records had all contact information that met neither email nor or phone operability requirements. * ‘only’ two percent of records still means over 4 million registrations (based on Q3 2021 registration numbers) that do not have contact information that meets email nor or phone operability requirements. * Does the group consider that an acceptable number? If not, what could be suggested to allow for further consideration to improve this number? Operability Accuracy * Ninety-nine percent of postal addresses, 60 percent of telephone numbers and 92 percent of email addresses met all operability requirements of the 2009 RAA. Fifty-six percent of domains passed all operability tests for all contact types (registrant, administrative and technical) and contact modes (email, telephone and postal address), which is a 7 percent drop from Cycle 5 findings. * Regional variations of operability accuracy are greatest for telephone, which ranges from 35 percent accurate (Asia Pacific) to 81 percent accurate (North America). * The contact mode with the highest rate of passing all operability tests was postal address, with 99 percent passing all tests. The mode with the lowest rate of passing all operability tests was telephone numbers, with 60 percent passing all tests. * The majority of email operability errors occurred when an email address bounced (98 percent of errors), compared to the error of a missing email address (2 percent of errors). * The majority of telephone operability errors were from invalid numbers (58 percent), while most of the remaining errors were from disconnected telephone numbers (40 percent) and other issues preventing connection (2 percent). Less than one percent were missing or not verifiable. Syntax Accuracy: * More than 92 percent of telephone numbers met all syntax requirements of the 2009 RAA, increasing from Cycle 5 (90 percent). * Regional variations of syntax accuracy were greatest for postal address, which ranged from 66 percent accurate (Africa) to 97 percent accurate (North America). * The most common reason for telephone syntax error in most regions was incorrect length, but in North America the most common reason for error was a missing country code. * For postal addresses, the vast majority of errors in each study have consistently been due to missing fields that were required, such as city, state/province, postal code or street. * In Cycles 5 and 6 the 2009 RAA group had the highest percentage of records in which all three contact modes were accurate. This is a change from Cycle 4, where the 2013 NGF RAA group had the highest percentage of records in which all three contact modes were accurate. Note that the 2009 RAA group contained only 130 records in Cycle 6. * Team to consider whether based on this data, the outcomes are ‘good enough’ or whether there are issues that could/should be addressed. In addition, reviewing this information may help inform what further study or research should be undertaken. * Team could also consider whether a sub-set of data could / should be reviewed if the team suspects that there may be specific issues with that sub-set such as abusive domain names. * Team to document the viewpoints on how looking at this issue – some view that there is no issue / problem, while others consider that there is an issue. * Can we correlate the 2% of the bad actors or just administrative errors? That is a gap in information. * Is this data comparable to actual use experience? Testing seems to be a proxy for what actual use is. * Agree that there is no current data and note that there are opposing points of views on whether there is a problem or there isn’t and document that as part of the team’s findings. Need to stop repeating the argument that because there is no data there is no problem or there is a problem because the team is not going to agree on this. * Need to look at the relevance of this data in today’s world – if data is not publicly available, it is not of use. * Concerning that 40% of phone numbers were disconnected. * Numbers don’t speak for themselves and are open to interpretation. * Need to look at the trends at previous ARS. * Less invasive method of contact have a better result – need to factor that in and need to consider what is behind that. Having phone number publicly posted can be considered invasive. * This is not about access or display, this is about accuracy. If data is provided, it is accurate. Need to avoid comingling topics. * Measurement is a snap shot in time – need to also consider how issues were addressed. * See also https://whois.icann.org/en/whoisars - in 83% a ticket was closed out because the domain was suspended, not because underlying accuracy of data was considered. Trend of higher rate of suspended domain names towards later ARS reports. Is it considered there is ‘no issue’ because tickets are closed because domain name is suspended (but no review of the underlying data to determine inaccuracy)? Should also consider correlating data. * We agree that accuracy is difficult to measure. We do not agree on whether it is important to continue such measurement attempts. * Suspension does not mean the data was incorrect. It only means the registrant did not respond in time or did not provide evidence. * Consider pulling out of the table specific suggestions that can be further considered and discuss these further by the team (pros and cons). Consider inviting ICANN Compliance to provide input on suggestions such as whether a Registrar Audit on accuracy could be carried out. * Would it be worth considering sending out a survey to registrars to better understand the steps they take to implement requirements and whether there is data that they would be willing to share? If this is voluntary, how useful will the data be as only ‘good’ actors may respond? * Will be limited what can be done until we get a clear confirmation in relation to ICANN org’s role as controller or processor. How long before the factual determination takes place? 1. Accuracy working definition / construct (30 minutes) * Review input received (see https://docs.google.com/document/d/1JGdNLjOjhmJnj-iDaGvcVnv1gZ5tQu5C/edit) * Confirm next steps Deferred to the next meeting 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 * Team to consider these existing data sources and role in assessing existing current situation & identifying possible gaps * Confirm next steps Deferred to the next meeting – see also notes above in relation to ARS 1. Confirm action items & next meeting (Thursday 3 March at 14.00 UTC)

1 0

Registration Data Accuracy Scoping Team | Thursday, 24 February 2022
by Terri Agnew Feb. 24, 2022

Feb. 24, 2022

Dear all, All recordings for the Registration Data Accuracy Scoping Team held on Thursday, 24 February 2022 can be found on the agenda wiki page <https://community.icann.org/x/-YD3Cg> (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, 03 March 2022 at 14:00 UTC
by Terri Agnew Feb. 24, 2022

Feb. 24, 2022

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 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

Canceled: Registration Data Accuracy Scoping Team meeting
by ICANN Policy Calendar Feb. 24, 2022

Feb. 24, 2022

Meeting: Registration Data Accuracy Scoping Team meeting Date/time: Recurring weekly on Thursdays at 14:00 UTC for 90 minutes, 03 March – 31 March 2022 Please click the link below to join the webinar: https://icann.zoom.us/j/94504686990?pwd=MWc2eXZENk9yN0RqOUUzaGx2eGV0QT09 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 [icann.zoom.us]<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 [gnso.icann.org]<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 2022 Wiki agenda pages: https://community.icann.org/x/7ID3Cg (see dates on the left column) * Check your time zone: https://tinyurl.com/2p8mvfh8 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://forms.gle/GZqMAi4kKDaVP5o66> 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.

1 0