Data Protection/Privacy Update: Meeting with Contracted Parties on GDPR Compliance
On 27 April, a group of contracted parties met with me and others from ICANN org to discuss operational and technical aspects of ICANN's Proposed Interim Model [PDF, 922 KB] and compliance with the European Union's General Data Protection Regulation (GDPR). We had productive conversations during the working session and touched on topics that included technical and operational ramifications of implementing different aspects of the Interim Model, once finalized, via a temporary specification to include:
- How data controller responsibilities should flow through the registry and registrar accreditation agreements;
- Continued collection of all registration data from registrants;
- Continued transfer of thick data to registries, as well as escrow deposits;
- Registration data to be displayed in the public WHOIS and how it will appear, including operationalizing layered access via the Registry Data Access Protocol or RDAP;
- And the most efficient way to address amendments to registry-registrar agreements.
A few open issues remain to be discussed, however, this meeting was a good opportunity to hear directly from contracted parties about the work they are already doing to comply with GDPR by the 25 May 2018 enforcement deadline.
Input from the wider community, will help us refine ICANN's model to better reflect an appropriate balancing of the law's requirements and ICANN contracts. Our exchange with the contracted parties helped us take into account operational impacts. We aim to have a draft temporary specification to share with the community in the next few days.
As previously noted, our aim is to maintain the current WHOIS to the greatest extent possible while complying with the law. We look forward to the larger community process to provide us with a more comprehensive long-term solution for future registration directory services.
I encourage you to share your thoughts on this topic by emailing email@example.com. I also encourage you to visit our Data Protection/Privacy page for the latest updates.
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."