Skip to main content
Resources

Approved Resolution | Meeting of the New gTLD Program Committee

  1. Main Agenda
    1. Consideration of Non-Safeguard Advice in the GAC's Beijing Communiqué
      1. Rationale for Resolution 2013.06.04.NG01

 

  1. Main Agenda:

    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, http://newgtlds.icann.org/en/announcements-and-media/announcement-18apr13-en 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 [PDF, 564 KB] 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 http://www.icann.org/en/about/governance/bylaws#XI 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), 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, http://newgtlds.icann.org/en/announcements-and-media/announcement-18apr13-en triggering the 21-day applicant response period pursuant to the Applicant Guidebook Module 3.1 http://newgtlds.icann.org/en/applicants/gac-advice-responses. 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 http://www.icann.org/en/news/public-comment/gac-safeguard-advice-23apr13-en.htm.  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 attached 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: http://newgtlds.icann.org/en/applicants/gac-advice-responses.

      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 attached 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 http://newgtlds.icann.org/en/announcements-and-media/announcement-18apr13-en. This triggered the 21-day applicant response period pursuant to the Applicant Guidebook Module 3.1.

Published on 6 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""icann.org"" is not an IDN."