Skip to main content
Resources

Preliminary Report | Meeting of the 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 http://www.icann.org/en/groups/board/new-gTLD.

Formal Minutes are still to be approved by the New gTLD Program Committee. This has not been approved by the New gTLD Program Committee and does not constitute minutes but does provide a preliminary attempt setting forth the unapproved reporting of the resolutions from that meeting. Details on voting and abstentions will be provided in the Minutes, when approved at a future meeting.

NOTE ON ADDITIONAL INFORMATION INCLUDED WITHIN PRELIMINARY REPORT – ON RATIONALES — Where available, a draft Rationale for each of the Board's actions is presented under the associated Resolution. A draft Rationale is not final until approved with the minutes of the Board meeting.

A Regular Meeting of the New gTLD Program Committee of the ICANN Board of Directors was held in Los Angeles, California on 28 September 2013 at 16:40 local time.

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: Fadi Chehadé (President and CEO, ICANN), Chris Disspain, Bill Graham, Olga Madruga-Forti, Erika Mann, Gonzalo Navarro, Ray Plzak, George Sadowsky, Mike Silber, and Kuo-Wei Wu.

Jonne Soininen (IETF Liaison) and Francisco da Silva (TLG Liaison) were in attendance as non-voting liaisons to the Committee. Heather Dryden was in attendance as an observer to the Committee.

ICANN Staff in attendance for all or part of the meeting: Akram Atallah, President, Generic Domains Division; Francisco Arias; Megan Bishop; Michelle Bright; Samantha Eisner; Allen Grogan; Dan Halloran; Jamie Hedlund; Elizabeth Le; Karen Lentz; Cyrus Namazi; David Olive; Karine Perset; Erika Randall; Amy Stathos; and Christine Willett.

This is a preliminary report the Meeting of the New gTLD Program Committee, which took place on 28 September 2013.

  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. Update on String Similarity

 

  1. Consent Agenda

    1. Approval of NGPC Meeting Minutes

      The Committee took the following action:

      Resolved (2013.09.28.NG01), the NGPC approves the minutes of the 13 August 2013 and 10 September 2013 New gTLD Program Committee Meetings.

      All members of the Committee present voted in favor of Resolution 2013.09.28.NG01. The Resolution carried.

  2. Main Agenda

    1. Remaining Items from Beijing and Durban GAC Advice

      The Committee discussed each of the items on the proposed iteration of the scorecard to address the remaining open items of the GAC's advice in the Beijing and Durban Communiqués.

      The Committee discussed the new correspondence from the GAC regarding .WINE and .VIN, noting that the GAC advised the ICANN Board that the GAC finalized its consideration of the .WINE and .VIN, and further advised that the applications should proceed through the normal evaluation process. The Committee discussed how it would like to respond to the GAC's communication in light of the language in the communication noting that there are a range of views of GAC members on .WINE and .VIN. The Committee considered whether and how to facilitate a dialogue to better understand the range of views, the timing for such a dialogue, and additional information that may be needed for the Committee to enhance its understanding of the issue.

      The Committee also discussed a proposed path forward for considering its position on the GAC consensus objection advice concerning .AMAZON given the information presented in the applicant's response.

      The Committee then took the following action:

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

      All members of the Committee present voted in favor of Resolution 2013.09.28.NG02. The Resolution carried.

    2. Name Collision Discussion

      The Committee was provided with an overview of the public comments received on the study regarding the use of TLDs that are not currently delegated at the root level of the public DNS, and the companion proposal to manage the risks identified in the study.

      The Committee discussed a proposed framework for additional study in response to the public comments to examine the severity of the collision occurrences, and a potential path forward to delegation while the additional study is being completed. Staff noted that among other things, the proposed plan to manage the collision occurrences would require registry operators to provide a point of contact to enable an affected party to report second level domains that are causing severe harm as a consequence of name collision occurrences, and would establish a targeted public outreach campaign.

      Some members of the Committee noted the importance of working with and communicating with SSAC on the proposed name collision management plan. A member of the Committee also reminded the Committee of its agreement to send a written briefing to the GAC on the name collision matter prior to delegation of new gTLDs.

      The Committee agreed to consider this topic further at its next meeting.

    3. Update on String Similarity

      The Committee continued its discussions on some of the recent expert determinations made by the dispute resolution service provider on string confusion objections. The Committee was provided with a summary of the process for reviewing visual similarity and the string similarity objection process.

      The Committee discussed the filings of Reconsideration Requests by parties aggrieved by the string similarity objection decisions, and noted that all of the objections are either completed or waiting for final decision.

      The Committee requested that staff continue to provide updates on the string similarity objection decisions so that the Committee could continue to monitor the concerns expressed by the community.

      The Chair called the meeting to a close.

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