Skip to main content

Collaboration and Consensus: Understanding the EPDP’s Work

This August, the Expedited Policy Development Process Phase 2 team submitted its Phase 2 Final Report, which outlines 22 recommendations for a System for Standardized Access/Disclosure (SSAD) for nonpublic generic top-level domain (gTLD) registration data, as well as additional recommendations unrelated to the SSAD.

The development of this report was no small feat, and I want to thank each person who participated in this process for their dedication and determination. Most of the recommendations received either full consensus or consensus designations – a testament to the working group's ability to come together and develop solutions in a multistakeholder, bottom-up fashion.

In July 2018, following the ICANN Board's decision to adopt the Temporary Specification for gTLD Registration Data, the GNSO Council initiated and chartered the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data – the first EPDP in ICANN's history. Over the past two years, the EPDP team has worked tirelessly to draft policy that would bring Registration Directory Services (RDS) into compliance with the European Union's General Data Protection Regulation (GDPR).

The EPDP's objective was to draft a policy that allows ICANN to be in compliance with the law. The work that went into the development of the Final Report was significant; what they were able to accomplish, in such a short time, is both remarkable and commendable.

Last month, the GNSO Council accepted the Final Report's recommendations, and is now preparing a report for the ICANN Board's consideration. In its resolution, the GNSO Council also requested a consultation with the Board as part of the delivery of the GNSO Council Recommendations Report to discuss the financial sustainability of the proposed SSAD and some of the concerns expressed within the various minority statements.

At the same time, ICANN org is working on a proposed Operational Design Phase (ODP) that would become a part of the policy and implementation lifecycle and is intended to transparently help the Board prepare for its consideration of GNSO Council-approved consensus policy recommendations. In this phase, the org would assess the impact of the proposed policy recommendations in terms of risk, anticipated costs, resource requirements, and potential timelines for implementation. The community would then have the opportunity to provide feedback on the assessment prior to the Board's decision on whether to adopt the policy recommendations.

ICANN org continues to seek greater legal clarity from the European Data Protection Board (EDPB) on several outstanding questions and issues. On 2 October, I sent a letter to three European Commission Directors General to update them on the progress made thus far and stressed the importance of their feedback in developing a centralized, predictable solution for disclosing nonpublic registration data.

This is not the first time ICANN org has solicited feedback from the European Data Protection Authorities (DPAs). On 14 February 2020, we met with the Belgian DPA for a productive discussion regarding a Unified Access Model (UAM), and the positive progress made by the team on the SSAD. The EDPB's ongoing input, insight, and engagement is critical to ensuring that the hybrid model proposed by the EPDP keeps ICANN in compliance with the GDPR.

The community has gone above and beyond, pushing the multistakeholder model to its limit to get to the finish line. While the members of the EPDP take a much-needed moment to breathe, ICANN org will continue seeking input from European stakeholders on the proposed model.

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