Skip to main content

Minutes | New gTLD Program Committee

Note: On 10 April 2012, the Board established the New gTLD Program Committee, comprised of all voting members of the Board that are not conflicted with respect to the New gTLD Program. The Committee was granted all of the powers of the Board (subject to the limitations set forth by law, the Articles of incorporation, Bylaws or ICANN's Conflicts of Interest Policy) to exercise Board-level authority for any and all issues that may arise relating to the New gTLD Program. The full scope of the Committee's authority is set forth in its charter at

A Regular Meeting of the New gTLD Program Committee of the ICANN Board of Directors was held telephonically on 4 June 2013 at 13:00 UTC.

Committee Chairman Cherine Chalaby promptly called the meeting to order.

In addition to the Chair the following Directors participated in all or part of the meeting: Chris Disspain, Bill Graham, Olga Madruga-Forti, Ray Plzak, George Sadowsky, Mike Silber, Judith Vazquez, and Gonzalo Navarro.

Thomas Narten, IETF Liaison was in attendance as a non-voting liaison to the Committee. Heather Dryden was in attendance as an observer to the Committee.

Erika Mann, Francisco da Silva (TLG Liaison), and Kuo-Wei Wu sent apologies.

ICANN Staff in attendance for all or part of the meeting: Akram Atallah, Chief Operating Officer; John Jeffrey, General Counsel and Secretary; Megan Bishop, Michelle Bright, Samantha Eisner, Allen Grogan, Dan Halloran, Jamie Hedlund, Liz Le, Karen Lentz, Cyrus Namazi, Erika Randall, Amy Stathos, and Christine Willett.

These are the Minutes of the Meeting of the New gTLD Program Committee, which took place on 04 June 2013.

  1. GAC Advice Items
    1. Consideration of Non-Safeguard Advice in the GAC's Beijing Communiqué


  1. GAC Advice Items

    The Chair introduced the item on the main agenda regarding responding the GAC advice issued in the Beijing Communiqué. The Chair briefly outlined the proposed course of action for the meeting. The Chair noted that the Committee received a letter from ALAC, which will be placed on the agenda for discussion at the next meeting.

    At the request of the meeting shepherd, Chris Disspain, Jamie Hedlund walked the Committee through each of the items on the proposed "NGPC Scorecard of 1As Regarding Non-Safeguard Advice in the GAC Beijing Communiqué (4 June 2013)" (the "1A Scorecard"), which is Annex 1 [PDF, 564 KB] of the proposed resolution and attached to the minutes for reference.

    The Committee discussed accepting the GAC advice regarding application number 1-1165-42560 for .AFRICA and application number 1-1936-2101 for .GCC. Olga Madruga-Forti inquired whether the applicants would be permitted to withdraw their applications within a certain amount of time if the Committee accepted the GAC advice. After further discussion of the appropriate language to include in the 1A Scorecard and consultation with the General Counsel, the Committee agreed that the 1A Scorecard should indicate that the applicants may withdraw or may wish to seek relief via ICANN's accountability mechanisms, subject to the appropriate standing and procedural requirements.

    The Committee discussed its proposed response on the GAC advice regarding the .HALAL and .ISLAM strings, and decided to accept the advice. The Committee agreed that its response should note that it stands ready to enter into a dialogue with the GAC. The Chair questioned whether the Committee needed to write a formal letter to the GAC transmitting this response. Heather Dryden suggested that this was not necessary. The proposed response informs the GAC that the Committee looks forward to liaising with the GAC as to how such dialogue should be conducted.

    Olga Madruga-Forti raised a concern about acting on GAC advice that is non-consensus advice. Chris provided a brief history of the genesis of the language in the Applicant Guidebook (AGB) regarding GAC advice where the GAC expresses concerns—citing to the experience with the application for the .XXX string where there were number of governments who had concerns. The provision in the AGB provides governments who have deep concerns on certain strings (even if not a GAC consensus) a mechanism to have a dialogue with the Committee about its concerns.

    Jamie commented that staff looked into the issue and determined that pursuant to AGB Section 3.1.2, it does not make a different whether the concerns are raised by the entire GAC or a few members; the Committee is expected to enter into a dialogue to understand the scope of the concerns.

    The Committee engaged in discussions regarding accepting the GAC's advice on the list of strings that it advised should not proceed beyond initial evaluation. Thomas questioned whether the proposed response was too open-ended. Chris confirmed that the Committee's proposed response is crafted to indicate that it will not proceed beyond initial evaluation and any dispute resolution until the Committee hears back from the GAC.

    The Committee also discussed the proposed response on the GAC's advice regarding singular and plural strings. Bill Graham and the Chair suggested text edits to the 1A Scorecard to make it clear that the NGPC is accepting the advice to consider the issue of singular and plural strings. Mike Silber agreed that the response should be that the Committee will consider whether to allow single and plural versions of the same string.

    The Committee decided that its response to the GAC's advice regarding protections for IGO names and acronyms was more appropriate to be sent in a letter and not within the 1A Scorecard. Jamie confirmed that the letter would be sent out under separate cover to the GAC.

    The Committee agreed to accept the GAC's advice to finalize the RAA before approving any new gTLD contracts, and to advise the expert working group to take into account the GAC principles regarding WHOIS. After a review of the briefing materials, the Committee also agreed to accept the advice regarding protections for the IOC/RCRC names.

    Jamie noted that the Committee was provided responses to the Annex II questions raised by the GAC in its Beijing Communiqué. The Committee agreed that it would transmit the responses to the GAC. Jamie also noted that the advice from the GAC requesting a written briefing on the ability to change strings was not included in the 1A Scorecard because it will be a separate briefing paper to the GAC.

    Ray Plzak inquired whether the formulation of the responses to the GAC should reference the "Committee accepts this advice," or the "Board accepts this advice." The General Counsel responded that a whereas clause would be added to the proposed resolution to indicate that the Committee has the Board's authority to act on the GAC advice. George Sadowsky raised the issue that the 1A Scorecard being adopted by the Committee should be clearly labeled and identified so that it clear to the Committee and to the community which version of the 1A Scorecard is the final version adopted. The Chair, along with Chris and Ray concurred with this point and suggested that the 1A Scorecard be given a document number or other identifying information to give as much specificity as possible. The General Counsel read the proposed resolution as revised.

    The Committee then took the following action:

    1. Consideration of Non-Safeguard Advice in the GAC's Beijing Communiqué

      Whereas, the GAC met during the ICANN 46 meeting in Beijing and issued a Communiqué on 11 April 2013 ("Beijing Communiqué");

      Whereas, on 18 April 2013, ICANN posted the Beijing Communiqué and officially notified applicants of the advice, triggering the 21-day applicant response period pursuant to the Applicant Guidebook Module 3.1;

      Whereas, the NGPC met on 8 May 2013 to consider a plan for responding to the GAC's advice on the New gTLD Program, transmitted to the Board through its Beijing Communiqué;

      Whereas, the NGPC met on 18 May 2013 to further discuss and consider its plan for responding the GAC's advice in the Beijing Communiqué on the New gTLD Program;

      Whereas, the NGPC has considered the applicant responses submitted during the 21-day applicant response period, and the NGPC has identified nine (9) items of advice in the attached scorecard where its position is consistent with the GAC's advice in the Beijing Communiqué.

      Whereas, the NGPC developed a scorecard to respond to the GAC's advice in the Beijing Communiqué similar to the one used during the GAC and Board meetings in Brussels on 28 February and 1 March 2011, and has identified where the NGPC's position is consistent with GAC advice, noting those as "1A" items.

      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 (2013.06.04.NG01), the NGPC adopts the "NGPC Scorecard of 1As Regarding Non-Safeguard Advice in the GAC Beijing Communiqué" (4 June 2013), attached as Annex 1 to this Resolution, in response to the items of GAC advice in the Beijing Communiqué as presented in the scorecard.

      Rationale for Resolution 2013.06.04.NG01

      Why the NGPC is addressing the issue?

      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 through its Beijing Communiqué dated 11 April 2013. 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.

      What is the proposal being considered?

      The NGPC is being asked to consider accepting a discrete grouping of the GAC advice as described in the attached "NGPC Scorecard of 1As Regarding Non-Safeguard Advice in the GAC Beijing Communiqué (4 June 2013)" (the "1A Scorecard"), which includes nine (9) items of non-safeguard advice from the Beijing Communiqué as listed in the GAC Register of Advice. These items are those for which the NGPC has a position that is consistent with the GAC's advice.

      Which stakeholders or others were consulted?

      On 18 April 2013, ICANN posted the GAC advice and officially notified applicants of the advice, triggering the 21-day applicant response period pursuant to the Applicant Guidebook Module 3.1 The NGPC has considered the applicant responses in formulating its response to the GAC advice as applicable.

      To note, on 23 April 2013, ICANN initiated a public comment forum to solicit input on how the NGPC should address GAC advice regarding safeguards applicable to broad categories of new gTLD strings The public comment forum on how the NGPC should address GAC advice regarding safeguards is open through 4 June 2013. These comments will serve as important inputs to the NGPC's future consideration of the other elements of GAC advice not being considered at this time in the 1A Scorecard.

      What concerns or issues were raised by the community?

      As part of the 21-day applicant response period, ICANN received 383 applicant response documents representing 745 unique applications. Twenty-three responses were withdrawn and eleven were submitted after the deadline. Applicants appear to generally support the spirit of the GAC advice. The responses expressed concerns that the advice was too broad in its reach and did not take into account individual applications. Some applicant responses expressed concern that some elements of the advice seem to circumvent the bottom-up, multi-stakeholder model, while others proposed that the NGPC reject specific elements of the advice. A review of the comments has been provided to the NGPC under separate cover. The complete set of applicant responses can be reviewed at:

      What significant materials did the Board review?

      As part of its deliberations, the NGPC reviewed the following materials and documents:

      What factors did the Board find to be significant?

      The Beijing Communiqué generated significant interest from applicants and resulted in many comments. The NGPC considered the applicant comments, the GAC's advice transmitted in the Beijing Communiqué, and the procedures established in the AGB.

      Are there positive or negative community impacts?

      The adoption of the GAC advice as provided in the 1A Scorecard will assist with resolving the GAC advice in manner that permits the greatest number of new gTLD applications to continue to move forward as soon as possible.

      Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget); the community; and/or the public?

      There are no foreseen fiscal impacts associated with the adoption of this resolution.

      Are there any security, stability or resiliency issues relating to the DNS?

      Approval of the proposed resolution will not impact security, stability or resiliency issues relating to the DNS.

      Is this either a defined policy process within ICANN's Supporting Organizations or ICANN's Organizational Administrative Function decision requiring public comment or not requiring public comment?

      ICANN posted the GAC advice and officially notified applicants of the advice on 18 April 2013 This triggered the 21-day applicant response period pursuant to the Applicant Guidebook Module 3.1.

    The Chair took a roll call vote. All members of the Committee voted in favor of Resolution 2013.06.04.NG01. The Resolution carried.

    Chris noted that the Committee's communications should be clear that the action taken is not the sum total of the 1As and that there could be additional iterations of the scorecard to address the other advice. Heather commented that it should be communicated to the GAC that this resolution is not related to the safeguard advice.

    The Chair then called the meeting to a close.

Published on 26 June 2013

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