EPDP TEAM QUESTIONS FOR ICANN ORG
Temporary Specification Expiration
- The Team seeks clarification on the exact expiry date of the Temporary Specification. In Section 3, the effective date of the Temporary Specification is 25 May 2018, but was adopted on 17 May 2018.
Per Section 3 of the Temporary Specification, the effective date of the Temporary Specification is 25 May 2018. Additionally, the ICANN Board resolution adopting the Temporary Specification states: “The Temporary Specification will be effective for a 90-day period beginning 25 May 2018. The Board will reaffirm its temporary adoption every 90 calendar days for a total period not to exceed one year.”
Temporary Specification Amendments
- If the Board is considering any amendments to the Temporary Specification, it would be helpful if the EPDP Team can be made aware of any proposed changes in advance. Is the Board currently considering any amendments to the Temporary Specification? To address what requirement?
ICANN Org is not aware that any amendments are currently being considered. The Board is scheduled to meet in August to consider reaffirming the Temporary Specification according to the process in ICANN’s agreements for adopting temporary policies and specifications.
2. Can an update be provided on the status of the reconfirmation of the Temporary Specification by the ICANN Board?
The Board reaffirmed the Temporary Specification with no changes on 21 August 2018.
Temporary Specification Terminology Clarification
1. When ICANN refers to “security” as part of its mission - can ICANN describe what types of security are included??
The word “security” appears 36 times in the ICANN Bylaws in relation to topics such as: the DNS, the Internet, the Internet’s system of unique identifiers, the Internet’s root server systems, the registry database, and Top Level Domains.
2. With regard to the term “content,” in Section 4.4.5 - can ICANN provide context for use of the term?
It is generally believed that ICANN does not see itself in the role of a content regulator but there are scenarios where use of the term “content” is appropriate in this section.
Section 4.4.5 of the Temporary Specification provides a mechanism for third parties to contact Registered Name Holders to address “technical issues and/or errors with a Registered Name or any content or resources associated with such a Registered Name.” With regards to the question about ICANN being a “content regulator,” Section 1.1.c of ICANN’s Bylaws makes clear that ICANN does not regulate content.
3. Regarding Temporary Specification section 4.4.8 - Supporting a framework to address issues involving domain name registrations: the team requests additional specificity. Does this mean that registrars and registries must support a uniform access mechanism when approved or is there some present requirement?
Section 4.4.8 identifies that addressing issues involving domain name registrations, including but not limited to: consumer protection, investigation of cybercrime, DNS abuse, and intellectual property protection using a framework to be developed is a legitimate purpose for the processing of registration data. With regard to the second question, section 4.4.8 does not by itself require that registrars and registries must support a uniform access mechanism when approved. Please note however that section 4.1 of Appendix A does have a requirement for registrars and registries to “provide reasonable access to Personal Data in Registration Data to third parties on the basis of legitimate interests pursued by the third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the Registered Name Holder or data subject pursuant to Article 6(1)(f) GDPR.” Separately, section 4.2 of Appendix A requires registrars and registries to “provide reasonable access to Personal Data in Registration Data to a third party where the Article 29 Working Party/European Data Protection Board, court order of a relevant court of competent jurisdiction concerning the GDPR, applicable legislation or regulation has provided guidance that the provision of specified non-public elements of Registration Data to a specified class of third party for a specified purpose is lawful.” Section 4.2 of Appendix A further requires that registrars and registries “provide such reasonable access within 90 days of the date ICANN publishes any such guidance, unless legal requirements otherwise demand an earlier implementation.”
4. Regarding Temporary Specification section 4.4.13 - Handling contractual monitoring requests: which data sets will be required to measure compliance against which contractual provisions?
The data requested by ICANN Contractual Compliance will vary depending on the particular compliance issue. For example, for a registrant’s complaint that a renewal reminder email was not received, ICANN Contractual Compliance may request from the registrar of record a copy of the communication to the Registered Name Holder.
5. In section 5.7 of the Temporary Specification (and other sections), what is the meaning of “reasonable access”? Is it access to personal data reasonably provided? Does “reasonably” relate to the effort necessary to retrieve it? Does it mean how criteria for releasing it are applied, i.e., legitimate and not overcome by the rights of others? Should it just be “access”?
“Reasonable access” is not defined in the Temporary Specification. Generally, compliance with the requirement for registrars and registries to provide reasonable access to non-public registration data is evaluated on a case-by-case basis, based on evidence provided by the requestor, including its request for access to non-public registration data, evidence of the requestor’s legitimate purpose for accessing the non-public registration data, the timing and content of the contracted party’s response to the request (if any), and any other information or evidence relevant to assessing the request and response.
6. Regarding data disclosures concerning LEA requests: does GDPR compel a report of those disclosures to be made to the data subject? Please provide analysis of “in-jurisdiction” and “out-of-jurisdiction” requests.
The latest Draft Framework for a Possible Unified Access Model for Continued Access to Full WHOIS Data – For Discussion addresses the question of “whether or not logs of query activities concerning non-public data must be available to the registrant upon request except if prohibited by a relevant court order or legal requirement.” Please refer to Section 8 of the draft framework for more information on this topic. The draft framework is published for community discussion and to seek guidance from the European Data Protection Board. With a better understanding of the law, we will all be well positioned to develop, implement and enforce a legally sound, consistent unified model for access to non-public registration data, and lower the risk for the contracted parties in order for them to be able to accept such model.
7. The text in the preamble of Appendix C is simply an overview of the processing requirements that follows. The preamble does reference the GDPR, and it states that generally “terms with initial capital letters have the meaning given under the GDPR.” But we would need more clarity around what specific language in the preamble is seen to be similar to what specific language in the GDPR to be able to comment further on this question.
The text in the preamble of Appendix C is simply an overview of the processing requirements that follows. The preamble does reference the GDPR, and it states that generally “terms with initial capital letters have the meaning given under the GDPR.” But we would need more clarity around what specific language in the preamble is seen to be similar to what specific language in the GDPR to be able to comment further on this question.
8. Why did ICANN include the term content in 4.4.5?
To be clear, ICANN does not regulate content.
Section 4.4 lists purposes for processing personal data in registration data*. The processing activities in this section are not limited to ICANN's, they include the processing activities by Registrars and Registries and other third-parties. Section 4.4.5 says one of those purposes is “Enabling a mechanism for the communication or notification to the Registered Name Holder of technical issues and/or errors with a Registered Name or any content or resources associated with such a Registered Name.” For example, a law enforcement agent investigating potentially illegal content might use the registration data to identify and contact the registered name holder as part of the investigation. As a point of reference regarding processing by third parties, on 25 May 2018 the EDPB endorsed a statement of the WP29, which stated that the “WP29 expects ICANN to develop and implement a WHOIS model which will enable legitimate uses by relevant stakeholders, such as law enforcement, of personal data concerning registrants in compliance with the GDPR, without leading to an unlimited publication of those data.” <https://www.icann.org/en/system/files/files/statement-edpb-whois-27may18-en.pdf>
(*Note that Registration Data is defined in the Temporary Specification as “data collected from a natural and legal person in connection with a domain name registration.” This is broader than just data displayed in RDDS and includes all data collected in connection with the domain name registration.)
EPDB Advice
Can ICANN summarize in some searchable form the contacts and engagements with the EDPB and/or other DPAs in relation to the Temporary Specification for gTLD Registration Data?
ICANN org has been open and transparent with our engagements with the EDPB and DPAs. All of the formal written communications from EDPB and DPAs are published on ICANN correspondence. In addition, we’ve had informal verbal conversations with the EDPB and DPAs to educate, inform, and ask for guidance. Summaries of those informal conversations are published in blogs. To assist the EPDP Team in its work, ICANN org will provide the EPDP Team with a compiled list of correspondence received and blogs published thus far, including the topic of each correspondence/blog.
ICANN org's GDPR Compliance
1. Believing that ICANN org has its own GDPR implementation plan in place, it would be helpful for our group to understand the elements and implementation status of the plan so that the Team can draw comparisons to the EPDP Team’s work.
ICANN org has been open and transparent about its work to get ready for GDPR both in terms of domain registration data collected and processed by registrars and registries (which we refer to as “external” GDPR readiness), and personal data processed by ICANN org in the ordinary course of the organization’s operations such as finance, meetings, and human resources (which we refer to as “internal” GDPR readiness). ICANN org’s plans and activities regarding “external” (domain registration data) GDPR compliance have been openly and transparently blogged and posted on the ICANN Data Protection page at <https://www.icann.org/dataprotectionprivacy [icann.org]>. On 5 June 2018, ICANN’s CEO and President, Göran Marby, shared information about ICANN org’s “internal” efforts to be GDPR compliant via a blog. In the blog, Göran shared that several of ICANN’s policies have been updated. These include an updated online Privacy Policy [icann.org], a revised Terms of Service [icann.org], a revised Cookies Policy [icann.org], a new Notice of Applicant Privacy [icann.org] (relating to data processed for employment applications), and a revised New gTLD Program Personal Data Privacy Statement [newgtlds.icann.org]. Additionally, ICANN org has also rolled out internal changes to the way we handle personal data, from data processing arrangements with vendors to our various personnel policies. Read the full blog here [icann.org].
ICANN Org Liaisons Role
1. The Council envisioned, via the EPDP Charter, to have direct participation of ICANN org liaisons, within the EPDP Team. As we leave the Triage and head into substantive detail, do the ICANN liaisons see a role or specific set of actions for ICANN supporting the team?
Section III of the EPDP Charter describes the role of ICANN org liaisons as “ICANN Staff Liaison: The ICANN Org GDD and Legal Liaisons are expected to provide timely input on issues that may require ICANN Org input such as implementation-related queries. The ICANN Staff Liaisons are not expected to advocate for any position and/or participate in any EPDP Team consensus calls.” In line with this description of ICANN org liaisons’ role, Göran Marby’s response [icann.org] to the GNSO Council regarding a request for appointment of ICANN org liaisons confirmed the scope of participation of the ICANN org liaisons as “Trang Nguyen from ICANN organization’s Global Domains Division and Dan Halloran from ICANN’s legal team will join the working group’s mailing list and the group’s calls to coordinate responses to requests for GDD or legal input as needed to support the working group’s deliberations. Such requests will ordinarily be responded to in writing, following consultation with internal and external experts as appropriate.”
WHOIS Conflicts with Local Laws
- Has the WHOIS Conflicts with local laws procedure been used and successfully used to date? Please indicate the instances where the procedure was invoked and the outcome. Were any specific issues identified with the use of this procedure?
The procedure was most recently invoked for .FRL in late 2017. However, the request was withdrawn prior to an outcome when .FRL agreed to comply with the requirements of the Temporary Specification. The request was withdrawn early on in the process so ICANN org had not conducted a formal review to identify specific issues with the procedure.
The procedure was also previously attempted by .FRL in late 2016 but the request did not meet the requirements to utilize the procedure. At the time, requirement to trigger the procedure was that the contracted party must have received “notification of an investigation, litigation, regulatory proceeding or other government or civil action that might affect its compliance.” However, .FRL was not subject to any such proceeding at the time, and the procedure could not be used.
Specification or Policy
- Is the GNSO & the EPDP Team creating a policy or a specification?
As described in the Charter and the Board resolution that launched this Expedited Policy Development Process, the team’s task is to develop policy recommendations.
The starting point for these recommendations is the temporary specification adopted by the Board on 17 May 2018.
The temporary specification includes both high-level principles such as defining purposes and legal bases for processing registration data, and also detailed technical requirements such as descriptions of modifications to the registration data display requirements set forth in the registry and registrar agreements.
The Board does have the ability to adopt both temporary policies and specifications. The exact difference between a "temporary policy" and a "temporary specification" is not defined in the Bylaws or registry/registrar agreements.
Although the GNSO’s procedures <https://gnso.icann.org/en/council/procedures> generally discuss developing policy recommendations and not "specification" recommendations, the PDP Manual actually outlines a wide variety of "PDP Outcomes and Processes" one of which is "technical specifications". As noted above, the label that is given may not matter too much as during implementation a further assessment is usually made in relation to how to address each approved recommendation. Any remaining questions about the scope of the team’s work or how its deliverables should be structured and styled could be referred to the GNSO council.
OUTSTANDING QUESTIONS
