Skip to main content

EPDP Phase 2 Team Publishes Final Report

On behalf of the Expedited Policy Development Process (EPDP) Team on the Temporary Specification for generic top-level domain (gTLD) Registration Data, I am pleased to announce the publication of the Team's Phase 2 Final Report.

The Final Report sets out the EPDP Team's recommendations for a System for Standardized Access/Disclosure (SSAD) to nonpublic gTLD registration data and recommendations and conclusions for so-called "Priority 2" topics, which include topics such as city field redaction, among others.

Final Report Highlights

As part of its deliberations, the EPDP Team considered both a centralized model, in which both requests and disclosure decisions would be handled by ICANN org or its delegated processor, and a decentralized model, in which both requests and disclosure decisions would be handled by contracted parties (ICANN accredited registrars and gTLD registry operators). The team was not able to agree on either option, and instead put forward a hybrid model in which requests would be centralized and disclosure decisions would typically, at least in the initial implementation, be made by contracted parties.

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, defined building blocks, and distilled the common themes to draft its preliminary recommendations. Following a detailed review of all public comments received and further related discussions, the EPDP Team is putting forward 18 SSAD-related policy recommendations in its final report and four Priority 2 recommendations.

The 18 SSAD-related policy recommendations broadly address, among others, the following areas:

  • Accreditation of SSAD requestors, including governmental entities
  • Required criteria and content of SSAD requests
  • Response requirements
  • Required Service Level Agreements (SLAs)
  • Automation of SSAD processing
  • Terms and conditions of SSAD
  • Logging, auditing, and reporting requirements
  • Implementation of a GNSO Standing Committee, which is a committee charged with evaluating SSAD operational issues and proposing recommendations for improvement to the GNSO Council

It is important to note that the EPDP Team considers the 18 SSAD-related recommendations as interdependent, and, as a result, the team recommends that these recommendations be considered as one package by the GNSO Council and subsequently the ICANN Board.

The EPDP Team also put forward four Priority 2 recommendations related to the following topics:

  • Display of information of affiliated privacy / proxy providers
  • City field
  • Data retention
  • Purpose 2

Next Steps

On 3 September 2020 at 21:00 UTC, the GNSO Council will hold a webinar to provide details about the EPDP Phase 2 Final Report. Access information will be posted here.

Acknowledgement

The publication of the Phase 2 Final Report is another great achievement for the EPDP Team. The Phase 2 Team of 31 members and 19 alternates held 74 multi-hour teleconferences, in addition to a number of face-to-face meetings, over the past year.

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

We thank all of those who contributed to the public comment period. We also appreciate the close engagement of the ICANN Board and ICANN org, who provided valuable input that informed our deliberations on the SSAD.

Our thanks also goes to the EPDP Team's support staff, who worked tirelessly to advance our objectives every step along the way.

Lastly, I would be remiss if I failed to thank Janis Karklins, our Phase 2 Chair, who provided countless volunteer hours and the facilitation and leadership skills needed to get the team to this point.

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