Skip to main content
Resources

Approved Resolutions | Meeting of the New gTLD Program Committee

  1. Main Agenda

 

  1. Main Agenda:

    1. Remaining Items from Beijing, Durban and Buenos Aires GAC Advice: Updates and Actions

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

      Whereas, the GAC met during the ICANN 47 meeting in Durban and issued a Communiqué on 18 July 2013 ("Durban Communiqué").

      Whereas, the GAC met during the ICANN 48 meeting in Buenos Aires and issued a Communiqué on 20 November 2013 ("Buenos Aires Communiqué").

      Whereas, the NGPC adopted scorecards to respond to certain items of the GAC's advice in the Beijing Communiqué and the Durban Communiqué, which were adopted on 4 June 2013, 10 September 2013, and 28 September 2013.

      Whereas, the NGPC has developed another iteration of the scorecard to respond to certain remaining items of GAC advice in the Beijing Communiqué and the Durban Communiqué, and new 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 (2014.02.05.NG01), the NGPC adopts the "GAC Advice (Beijing, Durban, Buenos Aires): Actions and Updates" (5 February 2014), attached as Annex 1 [PDF, 371 KB] to this Resolution, in response to open items of Beijing, Durban and Buenos Aires GAC advice as presented in the scorecard.

      Rationale for Resolution 2014.02.05.NG01

      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, its Durban Communiqué dated 18 July 2013, and its Buenos Aires Communiqué dated 20 November 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.

      The NGPC has previously addressed items of the GAC's Beijing and Durban advice, but there are some items that the NGPC continues to work through. Additionally, the GAC issued new advice in its Buenos Aires Communiqué that relates to the New gTLD Program. The NGPC is being asked to consider accepting some of the remaining open items of the Beijing and Durban GAC advice, and new items of Buenos Aires advice as described in the attached scorecard dated 28 January 2014.

      As part of its consideration of the GAC advice, 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 Beijing GAC advice was posted on 18 April 2013 http://newgtlds.icann.org/en/announcements-and-media/announcement-18apr13-en, the Durban GAC advice was posted on 1 August 2013 http://newgtlds.icann.org/en/announcements-and-media/announcement-01aug13-en, and the Buenos Aires GAC advice was posted on 11 December 2013. The complete set of applicant responses are provided at: http://newgtlds.icann.org/en/applicants/gac-advice/.

      In addition, on 23 April 2013, ICANN initiated a public comment forum to solicit input on how the NGPC should address Beijing 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 NGPC has considered the applicant responses in addition to the community feedback on how ICANN could implement the GAC's safeguard advice in the Beijing Communiqué in formulating its response to the remaining items of GAC advice.

      As part of the applicant responses, several of the applicants who were subject to GAC Category 1 Safeguard Advice have indicated that they support the NGPC's proposed implementation plan, dated 29 October 2013, and voiced their willingness to comply with the safeguards proposed in the plan. On the other hand, an applicant noted that the NGPC's plan to respond to the GAC's Category 1 Safeguard advice is a "step back from what the GAC has asked for" with regard to certain strings. Others contended that their applied-for string should not be listed among the Category 1 Safeguard strings. Some of the applicants for the .doctor string noted that the NGPC should not accept the new GAC advice on .doctor because the term "doctor" is not used exclusively in connection with medical services and to re-categorize the string as relating to a highly regulated sector is unfair and unjust.

      With respect to the Category 2 Safeguards, some applicants urged ICANN to ensure that any Public Interest Commitments or application changes based on safeguards for applications in contention sets are "bindingly implemented and monitored after being approved as a Change Request." Additionally, some applicants indicated their support for the GAC advice protections for inter-governmental organization acronyms, protection of Red Cross/Red Crescent names, and special launch programs for geographic and community TLDs.

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

      In adopting its response to remaining items of Beijing and Durban GAC advice, and the new Buenos Aires advice, the NGPC considered the applicant comments submitted, the GAC's advice transmitted in the Communiqués, and the procedures established in the AGB and the ICANN Bylaws. 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.

      There are no foreseen fiscal impacts associated with the adoption of this resolution, but fiscal impacts of the possible solutions discussed will be further analysed if adopted. Approval of the resolution will not impact security, stability or resiliency issues relating to the DNS.

      As part of ICANN's organizational administrative function, ICANN posted the Buenos Aires GAC advice and officially notified applicants of the advice on 11 December 2013. The Durban Communiqué and the Beijing Communiqué were posted on 18 April 2013 and 1 August 2013, respectively. In each case, this triggered the 21-day applicant response period pursuant to the Applicant Guidebook Module 3.1.

    2. Discussion of Report on String Confusion Expert Determinations

      Whereas, on 10 October 2013 the Board Governance Committee (BGC) requested staff to draft a report for the NGPC on String Confusion Objections "setting out options for dealing with the situation raised within this Request, namely the differing outcomes of the String Confusion Objection Dispute Resolution process in similar disputes involving Amazon 's Applied – for String and TLDH's Applied-for String."

      Whereas, the NGPC is considering potential paths forward to address the perceived inconsistent Expert Determinations from the New gTLD Program String Confusion Objections process, including implementing a review mechanism. The review will be limited to the String Confusion Objection Expert Determinations for .CAR/.CARS and .CAM/.COM.

      Whereas, the proposed review mechanism, if implemented, would constitute a change to the current String Confusion Objection process in the New gTLD Applicant Guidebook.

      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 (2014.02.05.NG02), the NGPC directs the President and CEO, or his designee, to publish for public comment the proposed review mechanism for addressing perceived inconsistent Expert Determinations from the New gTLD Program String Confusion Objections process.

      Rationale for Resolution 2014.02.05.NG02

      The NGPC's action today, addressing how to deal with perceived inconsistent Expert Determinations from the New gTLD Program String Confusion Objections process, is part of the NGPC's role to provide general oversight of the New gTLD Program. One core of that work is "resolving issues relating to the approval of applications and the delegation of gTLDs pursuant to the New gTLD Program for the current round of the Program." (See NGPC Charter, Section II.D).

      The action being approved today is to first direct the ICANN President and CEO, or his designee, to initiate a public comment period on the framework principles of a potential review mechanism to address the perceived inconsistent String Confusion Objection Expert Determinations.

      The effect of this proposal, and the issue that is likely to be before the NGPC after the close of the public comments, is to consider implementing a new review mechanism in the String Confusion Objection cases where objections were raised by the same objector against different applications for the same string, where the outcomes of the String Confusion Objections differ. If the proposal is eventually adopted after public comment and further consideration by the NGPC, ICANN would work with the International Centre for Dispute Resolution (ICDR) to implement the new review mechanism outlined in the proposal.

      There are no foreseen fiscal impacts associated with the adoption of this resolution, which would initiate the opening of public comments, but the fiscal impacts of the proposed new review mechanism will be further analyzed if adopted. Approval of the resolution will not impact security, stability or resiliency issues relating to the DNS. The posting of the proposal for public comment is an Organizational Administrative Action not requiring public comment, however follow on consideration of the proposal requires public comment.

    3. Staff Update on Reassignment of Registry Agreements

      Item not considered.

    4. Staff Update on Name Collision Framework

      Item not considered.

Published on 7 February 2014

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