Skip to main content
Resources

Approved Resolutions | Meeting of the New gTLD Program Committee

  1. Consent Agenda
    1. Approval of NGPC Meeting Minutes
  2. Main Agenda
    1. Remaining Items from Beijing and Durban GAC Advice
    2. Name Collision Discussion
    3. String Similarity Discussion
    4. AOB

 

  1. Consent Agenda:

    1. Approval of NGPC Meeting Minutes

      Resolved (2013.09.28.NG01), the Board approves the minutes of the

      13 August 2013 and 10 September 2013 New gTLD Program Committee Meetings.

  2. Main Agenda:

    1. Remaining Items from Beijing and Durban GAC Advice

      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 NGPC adopted a scorecard to respond to the GAC's advice in the Beijing Communiqué and the Durban Communiqué, which were adopted on 4 June 2013 and 10 September 2013, respectively.

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

      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.09.28.NG02), the NGPC adopts the "Remaining Items from Beijing and Durban GAC Advice: Updates and Actions" (28 September 2013), attached as Annex 1 [PDF, 94 KB] to this Resolution, in response to remaining items of GAC advice in the Beijing Communiqué and the Durban Communiqué as presented in the scorecard.

      Rationale for Resolution 2013.09.28.NG02

      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 and its Durban Communiqué dated 18 July 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. The NGPC is being asked to consider accepting remaining Beijing and Durban GAC advice items as described in the attached scorecard dated 28 September 2013.

      As part of its consideration of the GAC advice, on 18 April 2013, ICANN posted the Beijing 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. Additionally, on 1 August 2013, ICANN posted the Durban GAC advice and officially notified applicants of the advice <http://newgtlds.icann.org/en/announcements-and-media/announcement-01aug13-en>, triggering the 21-day applicant response period pursuant to the Applicant Guidebook Module 3.1. 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 response period, several of the applicants indicated that they have entered into dialogue with the affected parties, and they anticipated reaching agreement on the areas of concern. Some of the applicants noted that they have proposed additional safeguards to address the concerns of the relevant governments are unsure as to whether a settlement can be reached. These applicants asked that the ICANN Board allow their applications to proceed even if an agreement among the relevant parties cannot be reached. Additionally, inquiries have been made as to whether applicants and the relevant governments will have the opportunity to comment on conversations among the GAC, ICANN Board, and ICANN staff. There have been requests that that the GAC, NGPC, and ICANN staff consult with applicants before decisions regarding any additional safeguards are made.

      Other applicants noted the important role of governments in the multi-stakeholder model, but advised the NGPC that it should not allow governments to exercise veto power over ICANN policies adopted through the multi-stakeholder process.

      Additionally, some members of the community opposed the NGPC accepting the GAC's advice concerning safeguards. Opposing commenters generally expressed concern that this is new and unanticipated policy, contrary to the bottom-up process. They also indicated that the safeguards are vague and not adequately defined, and are therefore not possible to implement.

      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, the NGPC considered the applicant comments submitted, the GAC's advice transmitted in the Communiqués, and the procedures established in the AGB. The adoption of the GAC advice as provided in the attached scorecard will assist with resolving the GAC advice in a 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 Durban GAC advice and officially notified applicants of the advice on 1 August 2013. Likewise, ICANN posted the Beijing GAC advice and officially notified applicants of the advice on 18 April 2013. In each case, this triggered the 21-day applicant response period pursuant to the Applicant Guidebook Module 3.1.

    2. Name Collision Discussion

      No resolution taken.

    3. String Similarity Discussion

      No resolution taken.

    4. AOB

      No resolution taken.

Published on 1 October 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."