Skip to main content

NGPC Adopts Resolution Accepting Nine Items of GAC Beijing Advice on New gTLDs

The ICANN Board New gTLD Program Committee (NGPC) met on 4 June 2013 and adopted a resolution accepting nine items of the GAC's Beijing advice with respect to New gTLD applications. The Resolution addresses most though not all of the GAC's non-Safeguard Advice and does not address any of the Safeguard Advice in Annex 1 of the GAC Beijing Communiqué. As such, this Resolution represents only the first of what will be a series of NGPC decisions addressing the GAC's Beijing advice.

The NGPC took action to adopt the Scorecard attached to the Resolution as Annex 1. The Scorecard does the following: 1) it lists the nine items of non-Safeguard Advice addressed by the NGPC to date; 2) it indicates that the NGPC accepts each of those items of advice; and 3) it describes how ICANN will implement the advice. You can find the Resolution and Annex 1 Scorecard here as well as the letter on the NGPC's action from Steve Crocker, Chair, ICANN Board of Directors to Heather Dryden, Chair, Governmental Advisory Committee here [PDF, 2.68 MB].

The NGPC also addressed the following additional matters from the GAC Beijing Communiqué:

  1. Written Briefing on the ability of an applicant to change its applied-for string

    In Section IV.1.d of the GAC Beijing Communiqué, the GAC requested a "written briefing about the ability of an applicant to change the string applied for in order to address concerns raised by a GAC Member and to identify a mutually acceptable solution." In response to the GAC's request, a written briefing on this matter is attached to the letter to Heather Dryden as Appendix 2.
  2. Protections for Intergovernmental Organizations

    In Section IV.1.g of the GAC Beijing Communiqué, the GAC reiterated its advice that "appropriate preventative initial protection for the IGO names and acronyms on the provided list be in place before any new gTLDs would launch." The GAC also noted that it was "mindful of outstanding implementation issues and commits to actively working with IGOs, the Board, and ICANN Staff to find a workable and timely way forward." The NGPC appreciates the GAC's willingness to collaborate to address the outstanding implementation issues. So that we may move forward, the NGPC formally requests that the GAC and a small number of NGPC members and ICANN staff begin a dialogue on the issues raised by the GAC. The NGPC's formal request was sent under separate cover and may be seen here [PDF, 285 KB].

  3. Public Interest Commitments Specifications

    In Section IV.5 of the GAC Beijing Communiqué, the GAC requested, "more information on the Public Interest Commitments Specifications on the basis of the questions listed in annex II." The NGPC's responses to these questions are attached to the letter to Heather Dryden as Appendix 3.

Future Work of the NGPC

As noted above, the 4 June 2013 Resolution only addresses a portion of the GAC's Beijing Advice. The NGPC has scheduled meetings on 11, 18 and 25 June to address the remaining items of advice, most notably the Safeguards Advice in Annex 1 of the GAC Beijing Communiqué.

The New gTLD evaluation and objection processes remain on track while the NGPC continues its deliberations. The NGPC is prioritizing its work in order to allow the greatest number of applications to move forward as soon as possible. We will continue to provide updates on the NGPC's progress in responding to the GAC Beijing Advice.

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