Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Fix links.

...

10. 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.

...

During development of the Temp Spec, contracted parties pointed out that this requirement would require development time to implement in their platforms.

EPDB Advice

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

2. 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. See DPA Advice Summary-DRAFT.xlsx15. Why city field is redacted in the Temporary Specification:

Regarding the EPDP Team’s question about why the City field is redacted in the Temp Spec, the Cookbook provides the following rationale: "The registrant’s state/province and country will be published, but the address fields that could be used to more specifically identify the registrant would not be included in the public WHOIS (e.g. street, city, postal code). This would enable non-accredited users to determine the registrant’s general location and likely jurisdiction but would generally not enable identification of the registrant”. The link to the Cookbook:https://www.icann.org/en/system/files/files/gdpr-compliance-interim-model-08mar18-en.pdf. The above quote is on page 26.


EPDB Advice

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

2. 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. See DPA Advice Summary-DRAFT.xlsx.

3. Is there any further information that can be provided in relation to the discussions that have been held with the EDPB and/or DPAs in addition to the blog posts and correspondence that have been shared, such as briefing notes and summaries of meetings?

Aside from the blog posts and correspondence that have already been shared, and consistent with ICANN Publication Practices, ICANN org has not identified any additional notes or summaries of meetings that are suitable for publication.

ICANN org has previously stated that having clear guidance may increase legal certainty for ICANN and the contracted parties as well as assist the community in the Expedited Policy Development Process (EPDP) to consider the Temporary Specification for gTLD Registration Data (Temp Spec). Our commitment to transparency in publishing summaries of our interactions with the EDPB supports this stated purpose.

In this regard, we’ve posted summaries of our conversations with the EDPB and DPAs on ICANN’s Data Protection/Privacy Issues page. The purpose of these conversations has been to educate, inform, and request guidance. In these discussions, we have also relayed to the EDPB the concerns and questions that we have solicited from the community.

Additionally, in the Work and Tools section of the EDPB website, the EDPB states that: “We issue general guidance to promote a common understanding of European data protection laws, both across the European Union and around the world. We clarify data protection provisions, advise the European Commission and provide the general public and stakeholders with our interpretation of their rights and obligations. We can issue guidelines, recommendations and best practices about the GDPR and the Law Enforcement Directive, as well as other documents.” Accordingly, guidance from the EDPB to ICANN is publicly posted on their website and ICANN’s website so that the guidance is available for all interested parties and can help inform the work of the community.


ICANN org's GDPR Compliance

...

4. During the 19 September 2018 EPDP Q&A Session with Becky Burr, there was a request for more information regarding what ICANN org does with personal data as it relates to ICANN contractual compliance. Additionally, on 4 October 2018, ICANN org received a question from the EPDP Team regarding data retention procedures. In response to these two items, please see the attached a summary of ICANN org’s contractual compliance personal data processing activities: Summary-Contractual-Compliance-Data-Processing-Activities.pdf

...

Input from ICANN Compliance

Contractual Compliance responses to EPDP_5oct1825jan19.pdf

Summary-Contractual-Compliance-Data-Processing-Activities.pdf


OUTSTANDING QUESTIONS

  1. Is indemnification provided by ICANN through a joint controller agreement an option? If EPDP agrees on policy that requires ICANN to indemnify, would the ICANN legal team and Board oppose it?

  2. When will the ICANN be released memorandum concerning the roles and responsibilities in processing data. The EPDP team encourages ICANN to issue the memo within 48 hours so its position can be referenced in the Initial Report.