Skip to main content

Data Protection/Privacy Issues Update: More Details Published on ICANN-proposed Interim Model

Gdpr data protection privacy proposed interim model 750x424 08mar18 en

As we prepare for discussions about the European Union's General Data Protection Regulation (GDPR) at ICANN61 next week in San Juan, today we are publishing [PDF, 923 KB] additional details on ICANN's Proposed Interim Model for compliance with the law and ICANN's contracts. We encourage you to review the document and are asking for your feedback.

This is a living document and builds on the summary we published [PDF, 727 KB] on 28 February 2018. It will be updated as our conversations with the community and data protection authorities (DPAs) progress, in particular with respect to competing community views on some elements. This proposal also delves further into each of the key elements of the Proposed Interim Model, community comments received on those elements, and the legal justifications underpinning the model. We hope this will help advance our conversation as we come to consensus on a single, unified interim model.

As I've previously mentioned, our goal is to identify the appropriate balance for a common path forward to ensure compliance with the GDPR while maintaining the existing WHOIS system to the greatest extent possible. With that in mind, the Proposed Interim Model maintains current requirements for the collection of registration data (including registrant, administrative, and technical contact information), but restricts most personal data to tiered/layered access via an accreditation program to be developed in consultation with the Governmental Advisory Committee (GAC), DPAs and contracted parties with full transparency to the ICANN community. Tiered/layered access is a key feature of the model and is a significant change to the current WHOIS. ICANN org has engaged with its community members, including contracted parties, governments, including DPAs, law enforcement, intellectual property representatives, and civil society to address the GDPR's impact on ICANN's contracts, particularly as it relates to the collection, retention, and display of registration data in the WHOIS services.

In addition to the community discussions at ICANN61, I indicated in a blog on 7 March 2018 that we will share this detailed description of the Proposed Interim Model with the Article 29 Working Party. We plan to discuss it in greater detail with them later this month and into April when the Working Party holds its next plenary meeting, after which we hope to publish their feedback.

We welcome your feedback, as well as encourage you to continue dialogue with each other to arrive at consensus on a single, unified interim model. Please share your thoughts by emailing or at the ICANN61 meeting in San Juan next week, where there are several sessions devoted to GDPR. We hope you can participate in the discussions either remotely or in person. And please check back on our Data Protection/Privacy Issues page for the latest updates on this important topic.


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