Skip to main content

Data Protection and Privacy Update – Plans for the New Year

As 2017 comes to an end, it's a good time to assess where we are and where we are going with our work to address potential compliance issues with ICANN agreements with generic top-level domain (gTLD) registries and registrars in light of the European Union's General Data Protection Regulation (GDPR).

A Look Back at 2017

We started out by working with an ad hoc group of community volunteers to help us create and populate a matrix of user stories of the personal data that gTLD registries and registrars collect, transmit, or publish pursuant to ICANN agreements or policies. The purpose for collecting this information was to inform discussions about whether there are potential compliance issues under ICANN agreements with registries and registrars because of the new law, and to engage with data protection authorities.

We continued this work by facilitating discussions within the multistakeholder community during ICANN Public Meetings, blogs, and webinars.

Also, we engaged the European law firm Hamilton to provide legal analysis on these issues. This analysis, developed in parts, aims to serve as building blocks for community discussions about how to approach GDPR issues in the domain name space. Ultimately, this data will help us outline a legal framework on which to build possible models for compliance with both the GDPR and ICANN's contracts with gTLD registries and registrars.

  • Part 1 [PDF, 252 KB], published on 16 October 2017, described the potential issues that could arise in relation to the WHOIS service in its current form as a result of the GDPR.
  • Part 2 [PDF, 577 KB], published on 15 December 2017, addressed questions that the ICANN community has raised with a goal of providing a better general understanding of the effects of the GDPR on the domain name space.
  • Part 3 [PDF, 440 KB], published today, elaborates on how the processing of data within the scope of WHOIS could possibly be changed to become compliant with the GDPR. This analysis lays out a legal framework to guide our approach to begin building potential compliance models with the community's input.

Charting a Path for the New Year

As we look to the new year, we are mindful that the May 2018 GDPR enforcement date is fast approaching. It's important to plot out where we're going so that we start the year with the energy and direction that we'll need to get us to our goal.

We've made it a high priority to find a path forward to ensure compliance with the GDPR while maintaining WHOIS to the greatest extent possible. Now, it is time to identify potential models that address both GDPR and ICANN compliance obligations.

We'll need to move quickly, while taking measured steps to develop proposed compliance models. Based on the analysis from Hamilton, it appears likely that we will need to incorporate the advice about using a layered access model as a way forward.

Before 15 January 2018, we want to publish for Public Comment proposed compliance models. As a first step, we'd like to hear your feedback and suggestions about the layered access approach described in Part 3 of the Hamilton legal analysis.

To help us meet this deadline, please submit your feedback before 10 January 2018. As we look to settle on a compliance model by the end of January, the community's continued participation and input will be instrumental in ensuring that we've appropriately shaped the model. Email your comments and suggestions to gdpr@icann.org.

To be clear, your feedback about the layered access approach outlined in the Hamilton memo is not intended to replace the ongoing process we published about how to submit a proposed compliance model in response to the 2 November 2017 Statement from Contractual Compliance. We have received one suggested model and know that many of you have been working to finalize your proposals. Your models will help us shape our proposal and we will continue to publish your submissions on our webpage as we receive them.

We look forward to continuing our engagement with the ICANN community in 2018 as we work together on this important issue. As before, we will continue to provide updates via blogs, webinars, and documents on our Data Protection/Privacy Issues webpage.

Comments

    biomanix  03:24 UTC on 19 January 2018

    saya sangat senang membaca artikelnya

    maiden  23:45 UTC on 06 February 2018

    generic top-level domain (gTLD

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