Skip to main content
Resources

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

A Regular Meeting of the New gTLD Program Committee of the ICANN Board of Directors was held telephonically on 18 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, Gonzalo Navarro, George Sadowsky, Mike Silber, Judith Vazquez, and Kuo-Wei Wu.

Fadi Chehadé, Erika Mann, and Ray Plzak sent apologies.

Thomas Narten (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, Chief Operating Officer; John Jeffrey, General Counsel and Secretary; Megan Bishop; Michelle Bright; Samantha Eisner; Dan Halloran; 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 18 June 2013.

  1. Consent Agenda
    1. Approval of Minutes of 8 May 2013 and 18 May 2013
  2. Main Agenda
    1. Discussion of Safeguard Advice Items Applying to All Strings
    2. Category 2 Advice (Restricted and Exclusive Registries)

 

  1. Consent Agenda:

    The Chair introduced the consent agenda items. George Sadowsky suggested revisions to the Minutes of the 4 June 2012 meeting to further clarify the name of the Scorecard annex approved at the 4 June 2013 meeting in order to avoid confusion if additional iterations of the Scorecard are approved at future meetings. The Committee agreed to reconsider the 4 June 2013 Minutes at its next meeting. The Committee then took the following action:

    Resolved, the following resolutions in this Consent Agenda are approved:

    1. Approval of Minutes of 8 May 2013 and 18 May 2013

      Resolved (2013.06.18.NG01), the New gTLD Program Committee approves the minutes of the 8 May 2013 and 18 May 2013 Meetings of the New gTLD Program Committee.

      All members of the Committee in attendance approved Resolution 2013.06.18.NG01. Fadi Chehadé, Erika Mann and Ray Plzak were not available to vote on the resolution. The Resolution carried.

  2. Main Agenda:

    1. Discussion of Safeguard Advice Items Applying to All Strings

      The Committee and staff had a discussion regarding the GAC's safeguard advice applicable to all strings. Akram Atallah provided an overview of the six recommendations to respond to the safeguard advice applicable to all strings. Akram noted that the Board had already directed staff to develop and execute certain WHOIS initiatives that would satisfy the GAC's advice on WHOIS, and recommended that the best way to address the advice was to have ICANN, instead of registry operators, implement the advice. Kuo-Wei Wu asked whether implementing the safeguard advice concerning WHOIS would have any impact on existing gTLDs or ccTLDs.

      Thomas Narten questioned how ICANN planned to manage the significant responsibility it is proposing to undertake, while Judith Vazquez noted she was encouraged by the leadership position taken by ICANN management to address this advice. Thomas also inquired about whether the proposed changes to the Registry Agreement to accept the GAC's advice would be put out for public comment, and expressed concern regarding whether these new requirements would be posted for comment. Chris Disspain also asked whether the proposals had been socialized with potential new registry operators, and Olga agreed that it was important to make sure the proposals actually could be implemented by new registry operators. Akram noted that public comments were already solicited on how the NGPC could implement the GAC's safeguard advice, and many members of the community provided input.

      Chris questioned why some of the advice was being implemented in the Registry Agreement instead of the Registrar Accreditation Agreement, and Akram noted that the enforcement purposes drove why the language was proposed in this way.

      For safeguards to address security threats, Akram described a proposal for registry operators to conduct the periodic checks required by the GAC's advice, but noted that the community needs to develop a uniform way to conduct the checks. George Sadowsky and Olga Madruga-Forti asked for clarification about the spot checks to be undertaken, and noted that the proposal should clearly provide that the checks will be conducted in a manner that is statistically sound.

      Thomas raised concerns that the proposal to address security threats is very broad and may impose requirements on registry operators that cannot be implemented. Bill Graham agreed that "security threats" is a broad concept open to various interpretations, and shared similar implementation concerns expressed by Thomas. Bill suggested that the proposed public community consultation to develop the framework for registry operators to respond to security risks should include consulting with the GAC.

      Olga requested that the proposal be revised to address whether the reports required by the safeguard advice would be available to the community for review, and Thomas agreed that the reports should be publically available. Akram noted the need to make the information public, while respecting the need to be careful not to publish information that may constitute sensitive security information.

      Chris discussed how some of the advice would be enforced in the Registry Agreement, and Dan Halloran provided additional explanation of the enforcement mechanisms in the Registry Agreement for the PIC Specification.

      The Chair and Heather Dryden inquired about the summary of public comments on implementing the GAC's safeguard advice, and staff provided an update on when the summary would be published.

      The Committee agreed that it would consider this issue again at its next meeting.

    2. Category 2 Advice (Restricted and Exclusive Registries)

      The Committee and staff had a discussion regarding the continued work regarding addressing the GAC's advice concerning restricted and exclusive registries. Chris Disspain explained the new gTLD application did not require applicants to specify whether they intended to operate an exclusive registry, so the challenge is to develop a mechanism to determine this information so that it would be clear which applicants could move forward with contracting and which applicants would be on hold pending resolution of the GAC's advice on exclusive access registries.

      Chris also provided additional background on the issue of exclusive generic strings, and noted that the Committee should be careful to consider the specific wording from the GAC and not go beyond what was advised. Akram Atallah provided the Committee with an overview of the proposed scheme to address the advice, noting that the proposed revision to the PIC Specification in the Registry Agreement would put registry operators with generic exclusive strings on hold while allowing other strings to move forward.

      George Sadowsky raised a concern that the proposed approach may be susceptible to gaming, and proposed an alternative approach to looking at the GAC's advice. George suggested that strings should be reviewed by looking at registries that propose to be open, registries where the GAC has advised that there should be limitations on the registrations, and everything else.

      Bill Graham and Olga Madruga-Forti agreed that the proposed approach may be subject to gaming, and Olga suggested that perhaps "exclusive registry access" should be defined as access that is not completely open. Olga also recommended that additional attention be given to definition of "affiliate" as that may help resolve some of the lingering concerns. George noted that gaming could still be an issue.

      Thomas Narten asked for clarification on the definition of exclusive access. Akram noted some challenges with establishing where to draw the line between open, restrictive and exclusive registry access.

      Chris suggested that a smaller group of Committee members continue working through the issues and definitions and present a revised proposal for the Committee to consider at its next meeting. The Committee agreed that further discussion was necessary on this item. The Chair urged this matter to be ready for Committee consideration at its next meeting.

    The Chair then called the Meeting to a close.

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