Skip to main content

Make Your Voice Heard: Comment Now on the EPDP Phase 2 Initial Report

Epdp team phase 2 icann66 1816x1029 10feb20 en

EPDP Team group photo taken in November 2019 during ICANN66 Montréal


On behalf of the Expedited Policy Development Process (EPDP) Team on the Temporary Specification for gTLD Registration Data, I am pleased to announce the publication of the Team's Phase 2 Initial Report and the opening of the Public Comment period.

The Initial Report sets out the EPDP Team's preliminary recommendations for a System for Standardized Access/Disclosure (SSAD) to Non-Public gTLD Registration Data. Please visit the Public Comment page for further information on how to submit your comment until 23 March 2020.

To facilitate your engagement in the Public Comment proceeding, the EPDP Team will host a 60-minute webinar on Thursday, 13 February starting at 14:00 UTC to provide details of our SSAD proposal and the related policy recommendations. All members of the ICANN community are welcome to participate and ask questions.

Initial Report Highlight

EPDP Phase 2 centers on the discussions around an SSAD. As described in a previous blog, the Team started our deliberations from the "hamburger model," consisting of a supply side and demand side of nonpublic registration data.

This model has now evolved into a detailed set of preliminary policy recommendations that form the proposed SSAD, including high-level principles, benefits for users, and an outline of the roles and responsibilities of the various parties involved in the operation and utilization of this system.

As you may recall, the SSAD is constructed using important building blocks that underpin its implementation. The building blocks address questions such as:

  • Who can request the nonpublic registration data?
  • What common elements must all requests contain?
  • What safeguards will be put into place to protect data subjects?
  • What actions do contracted parties (e.g., gTLD registries and ICANN-accredited registrars) need to take in response to an SSAD request?
  • Who is responsible for determining whether or not nonpublic data can be disclosed?

To understand the requirements of nonpublic registration data disclosure requests, the EPDP Team considered many questions, discussed a wide array of real-world use cases for users of the SSAD, and distilled the common themes that formed the building blocks.

These building blocks have evolved into 19 policy recommendations, which constitute the main body of our Initial Report. They cover various aspects including the accreditation of requestors, third party purposes and justifications, authorization, response requirements, variable SLAs, automation, and acceptable use policy.

It is important to note that all 19 of these policy recommendations are connected and should be considered holistically as the complete set provides the full details of the proposed SSAD.

The EPDP Team agreed to publish these preliminary recommendations for Public Comment, but no formal consensus call has taken place yet. The Initial Report also highlights areas where further input is requested and provides specific questions on which the public may provide comments to guide the EPDP Team's deliberations.

Acknowledgement

The publishing of the Phase 2 Initial Report is another great achievement for the EPDP Team. The Phase 2 Team of 31 members and 19 alternates held 42 fully-attended, multi-hour teleconferences in the past nine months. The Team also organized 100+ hours of intensive face-to-face meetings in Los Angeles, Marrakech, and Montréal. Small team meetings and mailing list discussions filled the brief intervals in between.

Everyone's dedication, willingness to compromise, and commitment to work through a multistakeholder process has pushed the EPDP one big step closer to our finish line.

We also appreciate the close engagement of the ICANN Board and ICANN organization (org), who provided us valuable input that informed our deliberations on the SSAD. If ICANN org receives further guidance from the European Data Protection Board, the EPDP Team will certainly consider this guidance as part of our deliberations towards our Final Report.

Last but not least, our thanks go to the EPDP Team's support staff, who worked tirelessly to advance our objectives every step along the way.

We look forward to hearing your feedback on the EPDP Phase 2 Initial Report. Thank you in advance for your contribution to the Public Comment.

Comments

    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."