Skip to main content
Resources

Approved Board Resolutions | Special Meeting of the ICANN Board

  1. Main Agenda:
    1. Reaffirming the Temporary Specification for gTLD Registration Data

 

  1. Main Agenda:

    1. Reaffirming the Temporary Specification for gTLD Registration Data

      Whereas, on 17 May 2018, the Board adopted the Temporary Specification for gTLD Registration Data (the "Temporary Specification") to be effective 25 May 2018 for a 90-day period. The Temporary Specification establishes temporary requirements to allow ICANN and gTLD registry operators and registrars to continue to comply with existing ICANN contractual requirements and community-developed policies concerning gTLD registration data (including WHOIS) in light of the European Union's General Data Protection Regulation (GDPR).

      Whereas, the Board adopted the Temporary Specification pursuant to the procedures in the Registry Agreement and Registrar Accreditation Agreement for adopting temporary policies. This procedure requires that "[i]f the period of time for which the Temporary Policy is adopted exceeds ninety (90) calendar days, the Board shall reaffirm its temporary adoption every ninety (90) calendar days for a total period not to exceed one (1) year, in order to maintain such Temporary Policy in effect until such time as it becomes a Consensus Policy".

      Resolved (2018.08.21.01), the Board reaffirms the Temporary Specification for gTLD Registration Data pursuant to the procedures in the Registry Agreement and Registrar Accreditation Agreement concerning the establishment of temporary policies. In reaffirming this Temporary Specification, the Board has determined that:

      1. The modifications in the Temporary Specification to existing requirements concerning the processing of personal data in registration data continue to be justified and immediate temporary establishment of the Temporary Specification continues to be necessary to maintain the stability or security of Registrar Services, Registry Services or the DNS or the Internet.
      2. The Temporary Specification is as narrowly tailored as feasible to achieve the objective to maintain the stability or security of Registrar Services, Registry Services or the DNS or the Internet.
      3. The Temporary Specification will be effective for an additional 90-day period.

      Resolved (2018.08.21.02), the Board reaffirms the Advisory Statement Concerning Adoption of the Temporary Specification for gTLD Registration Data [PDF, 511 KB], which sets forth its detailed explanation of its reasons for adopting the Temporary Specification and why the Board believes such Temporary Specification should receive the consensus support of Internet stakeholders.

      Rationale for Resolutions 2018.08.21.01 - 2018.08.21.02

      The European Union's General Data Protection Regulation (GDPR) went into effect on 25 May 2018. The GDPR is a set of rules adopted by the European Parliament, the European Council and the European Commission that impose new obligations on all companies and organizations that collect and maintain any "personal data" of residents of the European Union, as defined under EU data protection law. The GDPR impacts how personal data is collected, displayed and processed among participants in the gTLD domain name ecosystem (including registries and registrars) pursuant to ICANN contracts and policies.

      On 17 May 2018, the Board adopted the Temporary Specification for gTLD Registration Data ("Temporary Specification") to establish temporary requirements to allow ICANN and gTLD registry operators and registrars to continue to comply with existing ICANN contractual requirements and community-developed policies concerning gTLD registration data (including WHOIS) in relation to the GDPR. The Temporary Specification, which became effective on 25 May 2018, was adopted utilizing the procedure for temporary policies established in the Registry Agreement and the Registrar Accreditation Agreement.

      As required by the procedure in the Registrar Accreditation Agreement and Registry Agreements for adopting a temporary policy or specification, "[i]f the period of time for which the Temporary Policy is adopted exceeds ninety (90) calendar days, the Board shall reaffirm its temporary adoption every ninety (90) calendar days for a total period not to exceed one (1) year, in order to maintain such Temporary Policy in effect until such time as it becomes a Consensus Policy."

      Today, the Board is taking action to reconfirm the Temporary Specification for an additional 90 days as the temporary requirements continue to be justified in order to maintain the stability or security of registry services, registrar services or the DNS. When adopting the Temporary Specification, the Board provided an Advisory Statement [PDF, 511 KB] to provide a detailed explanation of its reasons for adopting the Temporary Specification and why the Board believes such Temporary Specification should receive the consensus support of Internet stakeholders. The Board reaffirms the Advisory Statement, which is incorporated by reference into the rationale to the Board's resolutions.

      As required when a temporary policy or specification is adopted, the Board took action to implement the consensus policy development process and consulted with the GNSO Council on potential paths forward for considering the development of a consensus policy on the issues within the Temporary Specification. The consensus policy development process must be concluded in a one-year time period. The Board takes note that the GNSO Council launched an Expedited Policy Development Process on the Temporary Specification, and the Working Group has begun its deliberations. The Board will continue to engage with the GNSO Council on this matter and reconfirms its commitment to provide the necessary support to the work of the Expediated Policy Development Process to meet the deadline (see 7 August 2018 letter from Cherine Chalaby to GNSO Council Chair: https://www.icann.org/en/system/files/correspondence/chalaby-to-forrest-et-al-07aug18-en.pdf [PDF, 269 KB]).

      The Board's action to reaffirm the Temporary Specification is consistent with ICANN's mission "[…] to ensure the stable and secure operation of the Internet's unique identifier systems […]". As one of ICANN's primary roles is to be responsible for the administration of the topmost levels of the Internet's identifiers, facilitating the ability to identify the holders of those identifiers is a core function of ICANN. The Board's action today will help serve the public interest and further the requirement in ICANN's Bylaws to "assess the effectiveness of the then current gTLD registry directory service and whether its implementation meets the legitimate needs of law enforcement, promoting consumer trust and safeguarding registrant data." [Bylaws Sec. 4.6(e)(ii)]

      Also, this action is expected to have an immediate impact on the continued security, stability or resiliency of the DNS, as it will assist in continuing to maintain WHOIS to the greatest extent possible while the community works to develop a consensus policy. Reaffirming the Temporary Specification is not expected to have a fiscal impact on ICANN organization beyond what was previously identified in the Board's rationale for resolutions 2018.05.17.01 – 2018.05.17.09. If the resource needs are greater than the amounts currently budgeted to perform work on WHOIS- and GDPR-related issues, the President and CEO will bring any additional resource needs to the Board Finance Committee for consideration, in line with existing fund request practices.

      This is an Organizational Administrative Function of the Board for which public comment is not required, however ICANN's approach to addressing compliance with ICANN policies and agreements concerning gTLD registration data in relation to the GDPR has been the subject of comments from the community over the past year (https://www.icann.org/dataprotectionprivacy).

Published on 23 August 2018

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