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?
There is a board meeting planned for later today (21 August). No changes to the Temporary Specification are being proposed.
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.
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?
Outstanding Questions
- 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?
- 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.
- 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.
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?
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?
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”?
- 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?
- Regarding Temporary Specification section 4.4.13 - Handling contractual monitoring requests: which data sets will be required to measure compliance against which contractual provisions?
