“The ARS remains paused as ICANN org assesses the effects of General Data Protection Regulation (GDPR). Based on the lack of predictable publicly available registration data and given the community work from the GNSO’s Expedited Policy Development Process (EPDP) on Temporary Specification for gTLD Registration Data, ICANN org believes it may be prudent to continue to pause and consider the impact of the EPDP efforts and assess our ability to effectively administer ARS.”

Follow-up Questions

1.How is the Compliance team trained on GDPR specifically?

...

ICANN Contractual Compliance enforces the Registrar Accreditation Agreement, Registry Agreements and Consensus Policies, and its staff are extensively trained on these agreements and policies. ICANN Contractual Compliance does not enforce laws or regulations which are outside the contractual scope of the ICANN organization. Accordingly, the ICANN Contractual Compliance team does not undergo GDPR specific training (or that of any other law or regulation), but subject-matter experts do maintain a general awareness of GDPR issues relevant to their areas of compliance expertise. Each contracted party must ensure its own processing complies with GDPR, where applicable, as well as any other applicable laws and regulations

2. Are the metrics from Compliance based on complaints received? (Answer: yes.) Would be interested to know – prior to the GDPR, how did ICANN perform these checks?

As noted in real-time during the discussion, metrics from Compliance are based on complaints received. Prior to the transition to the Naming Services portal (NSp) on 29 August 2020, ICANN did not track complaints received by reporter type, as the level of granularity in reporting was limited within the legacy system. ICANN Contractual Compliance’s monthly dashboard contains historical data about complaints received/closed that are related to accuracy which is available here. Additional information specifically addressing complaints received before and after GDPR went into effect is available here.

3. What is the status of the DPA negotiation between ICANN org and contracted parties?

Following the Board’s adoption of the EPDP Phase 1 Recommendations, ICANN org and a group of registry and registrar representatives designated by the CPH have been working on a document to implement EPDP Phase 1 Recommendations 19 and 20. At present, we are aiming to produce a draft Data Processing Specification to the Registry Agreement and Registrar Accreditation Agreement, which, once finalized, a contracted party could elect to enter into for purposes of data protection compliance. We have made significant progress toward a draft that will, once tentatively agreed, be shared with the Implementation Review Team (IRT) for feedback. In late 2021, ICANN org and the CPH group held extended discussions regarding remaining open issues with the aim to bring this effort to completion in the near term. We expect that this will be ready to share with the IRT prior to the draft Registration Data Policy document (the product of the EPDP Phase 1 IRT’s work) being published for public comment.

4. Is the ability for ICANN to share any of the training materials possible? (For example, it has been difficult for the group with respect to wordsmithing. If there are documents regarding clarity on these issues, it would be very helpful.)

ICANN Contractual Compliance utilizes written training materials, as well as regular in-person and phone/video training sessions conducted by senior staff. These training materials contain information about our systems, internal procedures and processes and are, therefore, confidential. Such materials, however, do not seek to define or interpret contractual requirements, and use the defined terms and requirements within the Registrar Accreditation Agreement, Registry Agreements, and Consensus Policies.

5. With respect to Q3, it discusses issues that are out of scope. How would a third complainant ever file a complaint regarding the accuracy of registrant data behind a P/P service? When is a compliant in scope and when is it out of scope?

ICANN refers the team to the prior response to question #20. In-scope complaints pertaining to customer data of a P/P Service Provider are limited. For example, if the underlying customer is also the Account Holder, or where the service provides an anonymized email that forwards to the underlying customer email (such that an inaccurate underlying email would result in a bounce-back from the email in the public Registration Data).

ICANN additionally notes that the majority of P/P services are “Proxy Services”, which are “service[s] through which a Registered Name Holder licenses use of a Registered Name to the P/P Customer in order to provide the P/P Customer use of the domain name, and the Registered Name Holder's [RNH] contact information is displayed in the Registration Data Service (Whois) or equivalent services rather than the P/P Customer's contact information.” (See Section 1.3 of the Specification of Privacy and Proxy Registrations). In such cases, the “registrant data” is the data of the Proxy Service/RNH.

6. With respect to the engagement you are doing on the NIS2…exactly what kind of purpose are you lobbying for? How does it fit with ICANN’s controller role? Who else do you think should be able to avail themselves of that “legitimate purpose” role to check accuracy? Do you envisage outsourcing and how would that work? Who are you engaging with, the EC or the DPAs?

As regards the ongoing negotiations on NIS2, ICANN org is engaging with the co-legislators, i.e. the European Parliament and the Council of the EU. The purpose of the engagement is to explain how the DNS works, highlight what the community is working on, and identify the challenges the community is facing with respect to the application of GDPR to registration data in the context of the ICANN policy making. This engagement is with the aim to ensure that deliberations and decisions relating to the DNS in NIS2 are made with a full understanding of the current situation and possible impact of the proposed legislation.

With respect to registration data accuracy, ICANN org provided information about the requirements to perform due diligence checks as developed by the ICANN community and applied through contractual structures with the contracted parties, as well as information about how ICANN compliance enforces these requirements, including how GDPR has affected ICANN compliance’s ability to enforce accuracy requirements.

Regarding the question, “How does it fit within ICANN’s controller role[?] (emphasis added)”, the intended meaning of “it” is unclear. However, as regards the “purpose,” if a purpose for registration data processing and recognition of a legitimate interest in processing that data (where the GDPR applies), were codified in a European directive and in turn in implementing member state laws, this could provide helpful clarity for any controller of the processing of personal data within registration data. The question (“Do you envisage outsourcing and how would that work?”) is also unclear (what would ICANN be potentially outsourcing?) and, thus, an answer on this aspect of the question cannot be provided.

7. On the answer to Q21, the second to last line includes the term “patently inaccurate”. How is "patently inaccurate" determined? For example, the name Mickey is an actual name. There are times where data may look fishy but it is, in fact, correct. How does ICANN org make this determination?

ICANN Contractual Compliance takes into account the totality of the information/evidence available. For instance, in the example provided, a fictional address “1234 Main Street, Disneyland, 00000, USA” combined with the Registrant Name “Mickey Mouse”, would be sufficient to suggest that the data is incorrect. ICANN Contractual Compliance further notes that it does not independently make determinations of accuracy, but may initiate a notice or inquiry where the information/evidence suggests that such contact information is incorrect.

==========

Follow up questions (responses received 6 April 2022)

1. 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”. 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?

Section 4 of the Whois Accuracy Program Specification (Specification) applies to all registrars that have “any information suggesting that the contact information specified in Section 1(a) through 1(f) of [the Specification] is incorrect” and is not limited to registrars who proactively monitor email bounce or non-delivery notifications. Information suggesting an inaccuracy in the RDDS Registration Data may come from sources other than a registrar’s self-monitoring, including ICANN Contractual Compliance (Compliance) in the event it receives a report containing sufficient evidence of inaccuracy (including a bounced email notification or non-delivery notification message).

The Registrar Accreditation Agreement (RAA) and the Specification do not contain requirements for a registrar to monitor bounce back or non-delivery notifications of email communications it sends to its registrants or other contacts as contained in Section 1 of the Specification. However, if through a registrar’s own practices it becomes aware of information that suggests the contact information is inaccurate, the obligations described under Section 4 of the Specification do apply.

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

Not applicable, see response to question 1 above.

3. If a Registrar is obliged to do such monitoring, does ICANN Compliance audit this requirement?

Not applicable, see response to question 1 above.

4. 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…” 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.

Verification, as described under Section 4 of the Specification, applies to the email address(es) of the Registered Name Holder (RNH), and Account Holder (AH), if different. Note however that registrars must also take reasonable steps to investigate a claimed inaccuracy (RAA Section 3.7.8), which may not be limited to verification or re-verification of the email address(es), and can include additional actions necessary to address the inaccuracy (or alleged inaccuracy).

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

ICANN is not clear what the phrase “associated with the RNH '' means in the context of this question. Upon notification of an inaccuracy in contact information, registrars are required to investigate, and, where applicable, correct any inaccuracy. Compliance will enforce this requirement where a registrar has any information to suggest that the contact information listed in Section 1 of the Specification is incorrect. Some examples of reported inaccuracies are provided below in an effort to help describe what characteristics may be sufficient to suggest an inaccuracy in the contact information in the RDDS (other than syntactical accuracy and operational accuracy of the email and/or telephone, as described in Section 1(f) the Specification):

An individual reports that their home address is used in Registration Data for a domain name that is not associated (or is no longer associated) with that address;
Business entity address/telephone/etc. used in Registration Data by someone not authorized to use and/or not associated with that business entity (e.g. ex-employee continues utilizing address of employer);
Privacy or Proxy Service contact information used in Registration Data for a domain name that is not or is no longer utilizing that P/P Service.

...

Content

Space Tools

Versions Compared

Old Version 7

New Version Current

Key