Skip to main content

Guidelines for Proposed Models to Address the General Data Protection Regulation (GDPR)

On 2 November 2017, the ICANN org published the Statement from Contractual Compliance regarding the ability of registries and registrars to comply with their WHOIS and other contractual requirements related to domain name registration data in light of the European Union's General Data Protection Regulation (GDPR). Under the conditions outlined in the statement and as indicated in the Data Protection/Privacy Activity Recap published on 17 November 2017, ICANN Contractual Compliance will defer taking action against any registry or registrar for noncompliance with contractual obligations related to the handling of registration data on a temporary basis during this period of uncertainty.

To be eligible for deferral, a contracted party that intends to deviate from its existing obligations must first share its model with ICANN. As such, ICANN is seeking proposed implementation models from the community that we can submit to the Hamilton law firm to incorporate in their follow-up legal analysis. Ultimately, these submissions will inform the publication of models for compliance with the GDPR as well as our contracts. As a point of clarity, submission of a model does not mean that it will qualify for deferral or that any deferral granted will be permanent.

When possible, we encourage alignment of models prior to submission. Fewer models will ease the impact on end-users and operational processes for all of us.

Requirements for Submissions

Each proposal should contain the following items:

  1. Cover Page for Proposed Models to Address the GDPR: download and complete this form to submit with any proposed model;
  2. Executive Summary: provide an overview of the proposed model;
  3. Details of the Proposal: provide complete information according to the Details of the Proposal below.

Please submit a completed proposal to ICANN's Global Support Center by emailing

Details of the Proposal

Please ensure the proposed plan includes consideration of at least the following:

  1. Analysis of how the model accommodates existing contractual obligations while reconciling them with the GDPR, including:
    1. A description of the proposed change and how it differs from the current implementation;
    2. Identification of how the model impacts current ICANN contractual obligations and specification of the contract provision or policy that is impacted by the cited law;
    3. Identification of the applicable section(s) of the GDPR;
    4. A description of how this change will comply with the applicable law.
  2. Changes to the collection, storage, display, transfer, and retention of data.
  3. Who will be impacted by the change and how (for example: registrants, users of WHOIS data, other contracted parties).
  4. Interoperability between registry operators and registrars.
  5. How users with a legitimate need for data will request and obtain data if it is no longer available in public WHOIS.
  6. Whether data handling will be uniform or if there will be variation based on things such as "natural person" vs. an organization, physical address of a point of contact, location of the registry operator or registrar, etc.
  7. Whether this model has been reviewed by a data protection authority. If so, indicate which data protection authority, when, and any details of their response.
  8. High-level description of any changes to other agreements beyond the Registry Agreement and Registrar Accreditation Agreement (for example: Registry-Registrar Agreement, Data Escrow Agreement, Registration Agreement, Registrar Reseller Agreement, Privacy Policies, etc.).
  9. If applicable, how this differs from other models and whether you endorse any other model. If you endorse another model, please identify whether you endorse the entire model or specific sections.

Next Steps

Upon receipt of proposed models, we will conduct a completeness check and follow up with clarifying questions, if necessary. We will then publish the models on and submit them to Hamilton to consider in its legal analysis. Ultimately, the work by Hamilton combined with the community discussions and its proposals will inform the publication of models for compliance with the GDPR as well as with our contracts. As noted in our prior blog, we will solicit public comment on these proposed models, which ICANN org will consider before settling on a decision. As we continue to learn more, we will provide further details of next steps.

Alignment with Contractual and Consensus Policy Obligations

ICANN's agreements with registries and registrars contain certain contractual and consensus policy obligations including Registry Service Evaluation Policy and the Revised ICANN Procedure for Handling WHOIS conflicts with Privacy Law. At this time, contracted parties do not need to initiate these service requests to share a proposed model with ICANN for analysis unless they plan to imminently deploy the model. Any deviation from ICANN contractual requirements must be approved or authorized in advance of deployment.

Related Resources

ICANN Disclaimer

These guidelines are provided as a reference for the submission of proposed implementation models for review by the ICANN org and Hamilton law firm. This is for informational purposes only and should not be relied upon to provide legal advice or determine how data protection regulation may apply to you and your organization. Submission of a model does not provide any legal rights to the Contracted Parties under your current agreement with ICANN nor does it constitute approval or deferral from contractual obligations.

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"""" is not an IDN."