Skip to main content

Data Protection/Privacy Update: Guidance on Proposed Model Submissions Now Available

Gdpr proposed models guidelines 750x426 08dec17 en

We are writing to update you on our progress since our last blog. Today we published more details on how to submit a proposed model for providing registration directory services and meeting other data retention requirements while remaining compliant with the European Union's General Data Protection Regulation (GDPR). As we move ahead, we outline below our planned next steps for receiving and assessing those models, which will enable us to be compliant with the law.

We look forward to receiving the proposed models from all community members, submitted in response to the 2 November 2017 Statement from Contractual Compliance. The statement indicated ICANN org would consider deferring action against any gTLD registry or registrar for noncompliance with contractual obligations related to the handling of registration data. The guidance we just published provides full details on what to include in the proposals, such as how the model accommodates existing contractual obligations, while reconciling them with the GDPR. As a reminder, submission of a model does not guarantee approval or temporary deferral from contractual obligations.

Göran Marby, our president and chief executive officer, has emphasized that finding a path forward to ensure compliance with the GDPR, while maintaining access to registration directory services to the greatest extent possible, is a high priority. When possible, we encourage the community to work together to align its models prior to submission. Fewer models will ease the impact on end-users and operational processes for all. Those models will be published on ICANN's website and shared with Hamilton, the European law firm engaged to assist ICANN org, for their consideration.

By the end of this calendar year, we plan to publish a second iteration of the legal analysis by Hamilton. This second iteration of the legal assessment takes into consideration additional inputs and questions from the community since the first iteration [PDF, 1.13 MB]. The community discussions, the work by Hamilton and relevant 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.

Recently, we also received a letter [PDF, 110 KB] from the Article 29 Working Party, which is published on our correspondence page. This communication is also useful for the community to consider and will factor into our work.

As previously noted, in parallel, the Registration Directory Services Policy Development Process Working Group is working to provide recommendations on the next generation of WHOIS, which will provide the long-term solution to ensure compliance with the GDPR as well as other local data privacy laws.

We look forward to receiving input and continuing to engage with the ICANN community as we work together to address the GDPR's impact on ICANN's contracts and registration directory services. We will keep you posted via these blogs, and provide up-to-date correspondence and other documents on our Data protection/Privacy Issues page.

Comments

    Creative Design Agency Jakarta  23:33 UTC on 12 December 2017

    Woaw,amazing! Thank you for sharing:D

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