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.
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.
GNSO COUNCIL QUESTIONS FOR ICANN BOARD
EPDP Outcome
1. What is the intent of the EPDP? Is it simply to confirm the Temporary Specification, or something more? What room is there in scoping to anticipate that the EPDP may conclude that the Temporary Specification cannot be confirmed “as is”, and make changes in order to achieve consensus policy?
There is room for various outcomes: confirming temporary specification; developing a different approach from what is established in the temporary specification; addressing additional issues that are not specifically identified in the temporary specification but for example, the annex. The EPDP is for the GNSO Council to manage, but the Board stands ready to assist as needed. Any outcome will obviously need to comply with the law.
2. What happens if the GNSO is not able to reach consensus at the end of the 1 year period?
The Board will explore other ways forward. Absent another way forward, there are things that automatically occur at the end of the 12 month period, the temp spec would no longer be in force. Review throughout the 12 month period how things are going, would allow Board to explore alternative ways forward which could potentially buy more time. The longer it takes, the greater the likelihood is that decisions are taken outside of ICANN. If community wants to be in control, it needs to work in a timely manner.
Temporary Specification Effective Date/Expiration
- Does the initial 90-day (and maximum one-year) period - and thus the maximum timeline for the GNSO’s policy work - commence on 17 May (date of Board resolution) or 25 May (effective date of the temporary specification)? We note that the operative language from the RAA/RA specifies that “In establishing any Temporary Policy, the Board shall state the period of time for which the Temporary Policy is adopted and shall immediately implement the Consensus Policy development process set forth in ICANN's Bylaws”, and the Board resolution is clear that the specification is effective beginning on 25 May. This could be interpreted to mean that the one-year clock starts from the effective date of the specification rather than Board action via resolution, which is a difference of 8 days.
25 May 2018 is the starting point, so 1 year period would end on 24 May 2019. Up to the Council to decide when to start, but regardless, process has to complete by 24 May 2019.
2. How is the re-confirmation process expected to occur as the temporary policy is only valid for 90 day intervals?
The Board will hold meetings at 90 day intervals and review prior to each meeting whether there is any new guidance that may require changes, followed by renewal of temporary specification for another 90 days. Changes may need to happen outside of that cycle.
Temporary Specification Amendments
- What happens should the Board decide to either modify the Temporary Specification or completely replace the temporary specification by a new one at a later point in time? Does this change the scope of the ongoing EPDP (note: Council does not intend to run multiple EPDPs simultaneously), and if so, how is the EPDP expected to deal with such changes while it may be half way through its process?
If there is an amendment to the temporary spec, the circumstances need to be considered. An amendment in month 1 may be dealt with differently compared to an amendment in month 11. Similarly, the type of amendment - minor or substantial. It may also be possible that a new temporary spec is triggered on a certain issue that, in theory, would trigger a new PDP, although it might be possible to fold this into the existing PDP. Flexibility is key, need timely communication to ensure that the appropriate approach can be considered factoring in all circumstances. The Board does not want to use the temporary specification approach unless absolutely necessary, for example when guidance is received from DPAs that certain elements would need to be changed.
Effect of Ongoing Court Cases
1. As evidenced by the recent legal action involving EPAG, there are parties who believe aspects of the Temporary Specification as written are not compliant with the GDPR. How does the Board think the GNSO Council should approach this matter when structuring and scoping the PDP?
Ongoing court cases may have an impact on issues, but the EPDP Team is not expected to deliberate on these issues unless these are reflected in the temporary specification.
FREQUENTLY ASKED QUESTIONS
EPDP Team Membership
Who can join the EPDP Team as a member?
Unlike other GNSO PDP efforts, which are open for anyone to join, the GNSO Council has decided to limit the membership composition of this EPDP primarily in recognition of the need to complete the work in a relatively short timeframe and to resource the effort responsibly. GNSO Stakeholder Groups, the Governmental Advisory Committee (GAC), the Country Code Supporting Organization (ccNSO), the At-Large Advisory Committee (ALAC) and the Security and Stability Advisory Committee (SSAC) have each been invited to appoint up to a set number of members and alternates, as outlined in the charter [include link]. In addition, the ICANN Board and ICANN Org have been invited to assign a limited number of liaisons to this effort.
To see who have been appointed to the EPDP Team, please see https://community.icann.org/x/2opHBQ.
If I am not appointed as a member, does that mean I cannot be involved?
No, even if you are not an appointed member, you can follow the deliberations of the EPDP Team by signing up as a mailing list observer as well as follow the meetings via real-time audio cast. In addition, recordings and transcripts of all meetings are expected to be publicly posted. Furthermore, the charter dictates that the EPDP Team should make provisions as part of its work plan to provide regular updates to the broader ICANN community and others interested, for example, through newsletters and/or webinars. Moreover, the EPDP Team is required to reach out at an early stage to GNSO Stakeholder Groups / Constituencies as well as other ICANN Supporting Organizations and Advisory Committees to request input and everyone will be invited to comment on the Initial Report once it is published for public comment.
To sign up as a mailing list observer, please go to: https://goo.gl/forms/iZg5JWHOnERsoEMI2
To review EPDP Team recordings and transcripts, please see: EPDP on the Temporary Specification for gTLD Registration Data.
EPDP Team Scope
What is the scope of the EPDP?
The proposed scope of the EPDP Team’s efforts includes confirming, or not, the Temporary Specification by 25 May 2019 (the date the Temporary Specification will expire). Additionally, the proposed scope includes discussion of a standardized access model to nonpublic registration data; however, the discussion of a standardized access model will occur only after the EPDP Team has comprehensively answered a series of “gating questions”, which will be specified in the EPDP Team’s Charter.
What questions is the EPDP expected to answer?
Terms of the Temporary Specification
Part 1: Purposes for Processing Registration Data
a) Purposes outlined in Sec. 4.4.1-4.4.13 of the Temporary Specification:
a1) Are the purposes enumerated in the Temporary Specification valid and legitimate?
a2) Do those purposes have a corresponding legal basis?
a3) Should any of the purposes be eliminated or adjusted?
a4) Should any purposes be added?
Note: Questions under a) are gating questions for the EPDP Team’s discussion of access, in that they must be answered before work on a standardized access model can commence. They are gating because establishing purposes will inform decisions about how personal data in registration data is processed. Because providing access to non-public Registration Data is a processing activity, there must be a legitimate purpose(s) with a corresponding legal basis(es) established prior to granting such access. Further, as pointed out by the European Data Protection Board (“EDPB”) (letter from Jelinik to Marby, July 5, 2018), the EPDP Team should recognize the distinction between ICANN’s purposes for processing registration data, and the purposes which third parties may present to obtain the disclosure of data.
Part 2: Required Data Processing Activities
b) Collection of registration data by registrar:
b1) What data should registrars be required to collect for each of the following contacts: Registrant, Tech, Admin, Billing?
b2) What data is collected because it is necessary to deliver the service of fulfilling a domain registration, versus other legitimate purpose as outlined in part (A) above?
b3) How shall legitimacy of collecting data be defined (at least for personal data collected from European registrants and others in jurisdictions with data protection law)?
b4) Under the purposes identified in Section A, is there legal justification for collection of these data elements, or a legal reason why registrars should not continue to collect all data elements for each contact?
Note: Questions under b) are gating questions for the EPDP Team’s discussion of access, in that they must be answered before work on a standardized access model can commence. They are gating because the answers to these questions will establish a baseline set of data that is collected for each domain name registration, which will in turn inform what data is made public, as opposed to only made available to accredited users.
c) Transfer of data from registrar to registry:
c1) What data should registrars be required to transfer to the registry?
c2) What data is required to fulfill the purpose of a registry registering and resolving a domain name?
c3) What data is transferred to the registry because it is necessary to deliver the service of fulfilling a domain registration versus other legitimate purposes as outlined in part (a) above?
c4) Is there a legal reason why registrars should not be required to transfer data to the registries, in accordance with previous consensus policy on this point?
c5) Should registries have the option to require contact data or not?
c6) Is there a valid purpose for the registrant contact data to be transferred to the registry, or should it continue to reside at the registrar?
Note: Questions under c) are gating for the EPDP Team’s discussion of access in that they must be answered before work on a standardized access model can commence. They are gating because the answers to these questions will determine which parties hold all registration data (thick WHOIS), and therefore are able to provide access to that data.
d) Transfer of data from registrar/registry to data escrow provider:
d1) Should there be any changes made to the policy requiring registries and registrars to transfer the data that they process to the data escrow provider?
d2) Should there be any changes made to the procedures for transfer of data from a data escrow provider to ICANN Org?
e) Transfer of data from registrar/registry to ICANN:
e1) Should there be any changes made to the policy requiring registries and registrars to transfer the domain name registration data that they process to ICANN Compliance, when required/requested?
f) Publication of data by registrar/registry:
f1) Should there be any changes made to registrant data that is required to be redacted? If so, what data should be published in a freely accessible directory?
f2) Should standardized requirements on registrant contact mechanism be developed?
f3) Under what circumstances should third parties be permitted to contact the registrant, and how should contact be facilitated in those circumstances?
Note: Questions under f) are gating for the EPDP Team’s discussion of access in that they must be answered before work on a standardized access model can commence. They are gating because the answers to these questions will determine what data is made available through a public Registration Data Directory Service (RDDS) record, as opposed to only made available to accredited users.
g) Data retention:
g1) Should adjustments be made to the data retention requirement (life of the registration + 2 years)?
g2) If not, are changes to the waiver process necessary?
g3) In light of the EDPB letter of 5 July 2018, what is the justification for retaining registration data beyond the term of the domain name registration?
h) Applicability of Data Processing Requirements
h1) Should Registry Operators and Registrars (“Contracted Parties”) be permitted or required to differentiate between registrants on a geographic basis?
h2) Is there a legal basis for Contracted Parties to differentiate between registrants on a geographic basis?
h3) Should Contracted Parties be allowed or required to treat legal and natural persons differently, and what mechanism is needed to ensure reliable determination of status?
h4) Is there a legal basis for Contracted Parties to treat legal and natural persons differently?
h5) What are the risks associated with differentiation of registrant status as legal or natural persons across multiple jurisdictions? (See EDPB letter of 5 July 2018).
i) Transfer of data from registry to Emergency Back End Registry Operator (“EBERO”)
i1) Consider that in most EBERO transition scenarios, no data is actually transferred from a registry to an EBERO. Should this data processing activity be eliminated or adjusted?
j) Temporary Specification and Reasonable Access
j1) Should existing requirements in the Temporary Specification remain in place until a model for access is finalized?
If so:
1. Under Section 4 of Appendix A of the Temporary Specification, what is meant by “reasonable access” to Non-Public data?
2. What criteria must Contracted Parties be obligated to consider in deciding whether to disclose non-public Registration data to an outside party requestor (i.e. whether or not the legitimate interest of the outside party seeking disclosure are overridden by the interests or fundamental rights or freedoms of the registrant)?
B. If not:
1. What framework(s) for disclosure could be used to address (i) issues involving abuse of domain name registrations, including but not limited to consumer protection, investigation of cybercrime, DNS abuse and intellectual property protection, (ii) addressing appropriate law enforcement needs, and (iii) provide access to registration data based on legitimate interests not outweighed by the fundamental rights of relevant data subjects?
j2) Can the obligation to provide “reasonable access” be further clarified and/or better defined through the implementation of a community-wide model for access or similar framework which takes into account at least the following elements:
1. What outside parties / classes of outside parties, and types of uses of non-public Registration Data by such parties, fall within legitimate purposes and legal basis for such use?
2. Should such outside parties / classes of outside parties be vetted by ICANN in some manner and if so, how?
3. If the parties should not be vetted by ICANN, who should vet such parties?
4. In addition to vetting the parties, either by ICANN or by some other body or bodies, what other safeguards should be considered to ensure disclosure of Non-Public Personal Data is not abused?
Part 3: Data Processing Terms -- To be concluded during the initial stage of the EPDP work, as part of the Temporary Specification review and initial report.
k) ICANN's responsibilities in processing data
k1) For which data processing activities undertaken by registrars and registries as required by the Temporary Specification does ICANN determine the purpose and means of processing?
k2) In addition to any specific duties ICANN may have as data controller, what other obligations should be noted by this EPDP Team, including any duties to registrants that are unique and specific to ICANN’s role as the administrator of policies and contracts governing gTLD domain names?
l) Registrar's responsibilities in processing data
l1) For which data processing activities required by the Temporary Specification does the registrar determine the purpose and means of processing?
l2) Identify a data controller and data processor for each type of data.
l3) Which registrant data processing activities required by the Temporary Specification do registrars undertake solely at ICANN's direction?
l4) What are the registrar's responsibilities to the data subject with respect to data processing activities that are under ICANN’s control?
m) Registry's responsibilities in processing data
m1) For which data processing activities required by the Temporary Specification does the registry determine the purpose and means of processing?
m2) Which data processing activities required by the Temporary Specification does the registry undertake solely at ICANN's direction?
m3) Are there processing activities that registries may optionally pursue?
m4) What are the registry's responsibilities to the data subject based on the above?
Part 4: Updates to Other Consensus Policies
n) URS
n1) Should Temporary Specification language be confirmed, or are additional adjustments needed?
o) UDRP
o1) Should Temporary Specification language be confirmed, or are additional adjustments needed?
p) Transfer Policy
p1) Should Temporary Specification language be confirmed or modified until a dedicated PDP can revisit the current transfer policy?
p2) If so, which language should be confirmed, the one based on RDAP or the one based in current WHOIS?
q) Sunsetting WHOIS Contractual Requirements
q1) After migration to RDAP, when can requirements in the Contracts to use WHOIS protocol be eliminated?
q2) If EPDP Team’s decision includes a replacement directory access protocol, such as RDAP, when can requirements in the Contracts to use WHOIS protocol be eliminated?
System for Standardized Access to Non-Public Registration Data
Work on this topic shall begin once the gating questions above have been answered and finalized in preparation for the Temporary Specification initial report. The threshold for establishing “answered” for the gating questions shall be consensus of the EPDP Team and non-objection by the GNSO Council.
(a) Purposes for Accessing Data – What are the unanswered policy questions that will guide implementation?
a1) Under applicable law, what are legitimate purposes for third parties to access registration data?
a2) What legal bases exist to support this access?
a3) What are the eligibility criteria for access to non-public Registration data?
a4) Do those parties/groups consist of different types of third-party requestors?
a5) What data elements should each user/party have access to based on their purposes?
a6) To what extent can we determine a set of data elements and potential scope (volume) for specific third parties and/or purposes?
a7) How can RDAP, that is technically capable, allow Registries/Registrars to accept accreditation tokens and purpose for the query? Once accreditation models are developed by the appropriate accreditors and approved by the relevant legal authorities, how can we ensure that RDAP is technically capable and is ready to accept, log and respond to the accredited requestor’s token?
(b) Credentialing – What are the unanswered policy questions that will guide implementation?
b1) How will credentials be granted and managed?
b2) Who is responsible for providing credentials?
b3) How will these credentials be integrated into registrars’/registries’ technical systems?
(c) Terms of access and compliance with terms of use – What are the unanswered policy questions that will guide implementation?
c1) What rules/policies will govern users' access to the data?
c2) What rules/policies will govern users' use of the data once accessed?
c3) Who will be responsible for establishing and enforcing these rules/policies?
c4) What, if any, sanctions or penalties will a user face for abusing the data, including future restrictions on access or compensation to data subjects whose data has been abused in addition to any sanctions already provided in applicable law?
c5) What kinds of insights will Contracted Parties have into what data is accessed and how it is used?
c6) What rights do data subjects have in ascertaining when and how their data is accessed and used?
c7) How can a third party access model accommodate differing requirements for data subject notification of data disclosure?EPDP Team Deliverables
What deliverables is the EPDP Team expected to produce?
The first deliverable of the EPDP Team shall be a triage document of the Temporary Specification, which includes items that have the Full Consensus support of the EPDP Team that these should be adopted as is (with no further discussion or modifications needed). These items need to be:
In the body of the Temporary Specification (not in the Annex)
Within the "picket fence" (per limitations on Consensus Policy as set out in the Contracts)
Not obviously in violation of the GDPR / Assumed to be compliant with GDPR [Presumed to be legal according to the members’ best knowledge of GDPR]
Consistent with ICANN’s Bylaws
Deliberations of this first deliverable should include at least one round of elimination of clauses, if appropriate, and a second round of Full Consensus approval of a whole set of clauses.
The second deliverable shall be the Initial Report which will include the items that received Full Consensus support per the triage document as well as all other items of the Temporary Specification (not including the Annex) that were considered and deliberated upon, followed by a Final Report following review of public comments. Per the illustrative timeline below, this implies that the Initial Report on the items related to the Temporary Specification (excluding the Annex) is expected to be published for public comment shortly after ICANN63 (October 2018) and the Final Report delivered to the GNSO Council for its consideration by the end of January / beginning of February 2019.
The third deliverable of the EPDP Team shall be an Initial Report outlining a proposed model of a system for providing accredited access to non-public Registration Data, followed by a Final Report following review of public comments.
The Team shall not commence work on the aforementioned third deliverable of an Initial Report outlining the proposed model of a system for providing accredited access to non-public Registration Data until all gating questions have been answered.
EPDP Team Work Plan
Where can I find the EPDP Team work plan?
The EPDP Team is expected to produce a work plan as one of its first deliverables. Once developed, it will be posted on the EPDP Team workspace: https://community.icann.org/x/2opHBQ.