Skip to main content
Resources

Approved Resolutions | Meeting of the New gTLD Program Committee

  1. Consent Agenda:
    1. Approval of Minutes
  2. Main Agenda:
    1. Conclusion of the Current Round of the New gTLD Program by the end of FY2017
    2. GAC Advice: Buenos Aires Communiqué (June 2015)

 

  1. Consent Agenda:

    1. Approval of Minutes

      Resolved (2015.10.18.NG01), the Board New gTLD Program Committee (NGPC) approves the minutes of its 28 September 2015 meeting.

  2. Main Agenda:

    1. Conclusion of the Current Round of the New gTLD Program by the end of FY2017

      No resolution taken.

    2. GAC Advice: Buenos Aires Communiqué (June 2015)

      Whereas, the Governmental Advisory Committee (GAC) met during the ICANN 54 meeting in Buenos Aires and issued a Communiqué [PDF, 106 KB] on 24 June 2015 ("Buenos Aires Communiqué").

      Whereas, the NGPC has adopted a series of scorecards to respond to certain items of the GAC's advice concerning the New gTLD Program. The NGPC has developed another iteration of the scorecard to respond to the advice in the Buenos Aires Communiqué.

      Whereas, the NGPC is undertaking this action pursuant to the authority granted to it by the Board on 10 April 2012, to exercise the ICANN Board's authority for any and all issues that may arise relating to the New gTLD Program.

      Resolved (2015.10.18.NG02), the NGPC adopts the scorecard titled "GAC Advice – Buenos Aires Communiqué 24 June 2015: Actions and Updates (18 October 2015)", attached as Annex 1 [PDF, 264 KB] to the resolution, in response to items of GAC advice in the Buenos Aires Communiqué concerning new gTLDs.

      Rationale for Resolution 2015.10.18.NG02

      Article XI, Section 2.1 of the ICANN Bylaws permit the GAC to "put issues to the Board directly, either by way of comment or prior advice, or by way of specifically recommending action or new policy development or revision to existing policies." The GAC issued advice to the Board on the New gTLD Program in its Buenos Aires Communiqué 24 June 2015. The ICANN Bylaws require the Board to take into account the GAC's advice on public policy matters in the formulation and adoption of the polices. If the Board decides to take an action that is not consistent with the GAC advice, it must inform the GAC and state the reasons why it decided not to follow the advice. The Board and the GAC will then try in good faith to find a mutually acceptable solution. If no solution can be found, the Board will state in its final decision why the GAC advice was not followed.

      The NGPC has previously addressed items of the GAC's advice concerning new gTLDs issued in Communiqués from Beijing (April 2013), Durban (July 2013), Buenos Aires (November 2013), Singapore (March 2014), London (June 2014), Los Angeles (October 2014), and Singapore (February 2015). The NGPC is taking action to address the new advice from the GAC in the Buenos Aires Communiqué as described in scorecard dated 18 October 2015.

      In adopting its response to the GAC advice in the Buenos Aires Communiqué, the NGPC reviewed various materials, including, but not limited to, the following materials and documents:

      The NGPC also considered the procedures established in the Applicant Guidebook and the ICANN Bylaws concerning the Board's consideration of advice from the GAC, in addition to the 26 September 2015 letter [PDF, 183 KB] from the GAC clarifying certain terminology used in the Buenos Aires Communiqué. The adoption of the GAC advice as provided in the scorecard will have a positive impact on the community because it will assist with resolving the GAC advice concerning the New gTLD Program.

      There are no foreseen fiscal impacts associated with the adoption of this resolution. Approval of the resolution will not impact security, stability or resiliency issues relating to the DNS. This is an Organizational Administrative function that does not require public comment.

Published on 21 October 2015

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