Dear EPDP Team, Below, please find answers to questions the EPDP Team posed to ICANN org: QUESTION: The Temporary Specification for gTLD Registration Data EPDP Team is currently considering language on a “Purpose M” regarding ICANN’s role in coordinating the development and implementation of policies concerning ICANN’s dispute resolution processes in the context of domain name registrations. Two of the processes currently being considered within scope of this purpose are the PDDRP (Post Delegation Dispute Resolution Process) and the RRDRP (Registry Restrictions Dispute Resolution Process). It would particularly be very helpful and important to the EPDP Team if ICANN could provide clarification on any point within the processes of PDDRPs and RRDRPs where processing of gTLD Registration Data is necessary for the dispute resolution processes to be completed. This clarification should identify which (if any) data elements within gTLD Registration Data are necessary, as well as all parties involved in the processing activities. RESPONSE: The PDDRP rules and the RRDRP rules each require the complainant (a trademark holder in PDDRP proceedings; an established institution in the relevant community in RRDRP proceedings) to “provide the name and address of the current owner of any at-issue domain name registration related to the dispute, to the best of the Complainant’s knowledge[.]” See PDDRP Rules, Section 3(b)(iv); RRDRP Rules, Section 3(b)(iv). The dispute resolution provider is required to serve the respondent (the registry operator) with a copy of the complaint, and to retain information related to the provider’s transmission of the complaint. Thus, these procedures may result in the complainant, provider, and/or respondent’s processing of gTLD registration data. It should be noted that neither of these procedures have been used yet. ICANN org would not process gTLD registration data in proceedings of either of these procedures because they are administered by independent dispute resolution service providers. However, if either procedure is used and ICANN org receives a panel’s decision, then that decision would include gTLD registration data. On another note, the current wording of Purpose M states: “coordinating the development and implementation of policies concerning ICANN’s dispute resolution processes in the context of domain name registrations.” It is unclear how developing and implementation of policy would involve processing of gTLD registration data or personal data. QUESTION: What is the rationale for not redacting organization field in the Temporary Specification? RESPONSE: Including the registrant organization field was determined to be consistent with ICANN org’s stated goal of complying with the GDPR while maintaining the WHOIS system to the greatest extent possible. The name of an organization refers to a legal person and not a natural person and therefore is arguably not covered under the GDPR. Additionally, the organization field is an optional field for registrants so to the extent that the registrant provides the organization name, the Temp Spec allows for publication of that information. Leading up to the development of the Temporary Specification, ICANN org consulted with the community and the DPAs to determine which data elements should continue to be made publicly available. Through the data matrix exercise where ICANN org asked contracted parties and interested stakeholders to identify user types and purposes of data elements required by ICANN policies and contracts, 40 user purposes for the registrant organization field were identified. For reference, Section 5.5.16(i) of the Interim Model for Compliance with ICANN Agreements and Policies in Relation to the European Union’s General Data Protection Regulation (also called the Cookbook) states that “the registrant “organization” would be required to be published (if applicable) so that registrations of legal entities would readily include the name of the entity.” -- Thank you. Best regards, Marika, Berry, and Caitlin