Skip to main content
Resources

Interim Registration Data Policy for gTLDs

Please note that the English language version of all translated content and documents are the official versions and that translations in other languages are for informational purposes only.

This Interim Registration Data Policy for gTLDs (Interim Policy) is a Consensus Policy that implements Generic Names Supporting Organization (GNSO) policy recommendations adopted by the ICANN Board on 15 May 2019 concerning data protection requirements for generic top-level domains (gTLDs). This Interim Policy implements one, out of a total of 29, of the Expedited Policy Development Process (EPDP) Team's recommendations, as described in the background section below. A subsequent Registration Data Policy for gTLDs (Registration Data Policy) will implement the Board-approved recommendations and following the end of Stage 2 will replace this Interim Policy.

This Interim Policy is effective on 20 May 2019. This Interim Policy requires gTLD registry operators and ICANN-accredited registrars (collectively, the "contracted parties"), effective 20 May 2019, to continue to implement measures that are consistent with the Temporary Specification for gTLD Registration Data on an interim basis, pending the implementation of the Registration Data Policy.

  1. Stage One
  2. Effective 20 May 2019, contracted parties must continue to implement measures consistent with the Temporary Specification for gTLD Registration Data (Temporary Specification), as adopted by the ICANN Board on 17 May 2018.

  3. Stage Two
  4. After ICANN org's (a) completion of the Registration Data Policy document, in consultation with the Implementation Review Team, (b) publication of the Registration Data Policy document, and (c) formal notice to the contracted parties of the publication of the Registration Data Policy, the contracted parties must either continue to implement measures consistent with the Temporary Specification or implement measures consistent with the Registration Data Policy document.

    During this stage, the contracted parties may implement either the Interim Policy or the Registration Data Policy in its entirety, or elements of both, as they prepare for the effective date of the Registration Data Policy document.

  5. Stage Three
  6. As of the Registration Data Policy's effective date (which the EPDP Team recommended to be 29 February 2020), contracted parties must comply with the Registration Data Policy.

Implementation Notes

ICANN Contractual Compliance will enforce contracted parties' obligations to comply with this Interim Policy as follows:

Stage 1: ICANN Contractual Compliance will enforce contracted parties' obligations to continue to implement measures that are consistent with the Temporary Specification.

Stage 2: ICANN Contractual Compliance will enforce contracted parties' obligations to (a) continue to implement measures consistent with the Temporary Specification or (b) implement measures that are consistent with the Registration Data Policy document. In response to a Compliance inquiry, a contracted party would be required to demonstrate how its activities satisfy this obligation. The pace of transitioning from the Temporary Specification to the Registration Data Policy is at the discretion of the contracted party.

Stage 3: ICANN Contractual Compliance will enforce contracted parties' obligations to comply with the Registration Data Policy. At this stage, the Registration Data Policy becomes operative and the Interim Policy is no longer in force.

Contracted parties must continue to comply with unchanged portions of the Registry Agreement and Registrar Accreditation Agreement throughout all three stages.

Background

On 17 May 2018, the ICANN Board of Directors (ICANN Board) adopted the Temporary Specification for gTLD Registration Data. The Temporary Specification modified existing requirements in the Registrar Accreditation and Registry Agreements to comply with the European Union's General Data Protection Regulation (GDPR). In accordance with the ICANN Bylaws and the Consensus Policies and Temporary Policies specifications in the Registry Agreement (RA) and Registry-Registrar Agreement (RAA), the Temporary Specification will expire on 20 May 2019.

On 19 July 2018, the GNSO Council initiated an EPDP and chartered the EPDP on the Temporary Specification for gTLD Registration Data team. All GNSO Stakeholder Groups, Constituencies, and ICANN Advisory Committees, that indicated interest in participating, are represented on the EPDP Team, although the charter limits the number of members per group.

The charter asked the EPDP to determine if the Temporary Specification for gTLD Registration Data should become an ICANN Consensus Policy as is, or with modifications. In addition, the charter directed that the result must comply with the GDPR and take into account other relevant privacy and data protection laws. The EPDP Team's charter also required discussion of a standardized access model to nonpublic registration data, following the EPDP Team's completion of policy recommendations and discussion of gating questions.

On 21 November 2018, the EPDP Team published its Initial Report for public comment. The Initial Report contained the EPDP Team's preliminary recommendations and a set of questions for public comment. The EPDP Team also examined and made recommendations about: (i) the validity, legitimacy and legal basis of the purposes outlined in the Temporary Specification, (ii) the legitimacy, necessity and scope of (x) the registrar collection of registration data and (y) the transfer of data from registrars to registries, each as outlined in the Temporary Specification, and (iii) the publication of registration data by registrars and registries as outlined in the Temporary Specification.

The Initial Report also provided preliminary recommendations and questions for the public to consider: (i) the transfer of data from registrars and registries to escrow providers and ICANN, (ii) the transfer of data from registries to emergency back-end registry operators (EBERO), (iii) the definition and framework for reasonable access to registration data, (iv) respective roles and responsibilities under the GDPR, i.e., the responsible parties, (v) applicable updates to ICANN Consensus Policies, and (vi) future work by the GNSO to ensure relevant Consensus Policies are reassessed to become consistent with applicable law.

The EPDP Team documented each of the data processing steps, and the purpose and the legal basis for each. This foundational work was necessary to develop GDPR-compliant solutions and is available in the Report's Appendix.

After the publication of the Initial Report, the EPDP Team: (i) sought guidance on legal issues, (ii) carefully reviewed public comments received in response to the publication of the Initial Report, (iii) reviewed the work-in-progress with the community groups the Team members represent, and (iv) deliberated for the production of its Final Report. Consensus calls on the recommendations contained in this Final Report, as required by the GNSO Working Group Guidelines, was carried out by the EPDP Team Chair, as described here: https://mm.icann.org/pipermail/gnso-epdp-team/2019-February/001436.html.

The GNSO Council adopted the Final Report on 4 March 2019. ICANN org commenced a public comment period on Final Report on 4 March 2019. The Summary and Analysis report for the public comment was published on 23 April 2019. The Board resolved to adopt the recommendations, with some exceptions, on 15 May 2019.

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