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. Update on String Similarity
    2. BGC recommendation on Reconsideration Request 13-5
    3. GAC Communiqué Durban – Scorecard
    4. GAC Communiqué Beijing – Scorecard
    5. GAC Communiqué Beijing – Category 1
    6. ALAC Statement on the Preferential Treatment for Community Applications in String Contention
    7. ALAC Statement on Community Expertise in Community Priority Evaluation
    8. AOB

 

  1. Consent Agenda:

    1. Approval of NGPC Meeting Minutes

      Resolved (2013.09.10.NG01), the Board approves the minutes of the 13 July 2013 and 17 July 2013 New gTLD Program Committee Meetings.

  2. Main Agenda:

    1. Update on String Similarity

      No resolution taken.

    2. BGC recommendation on Reconsideration Request 13-5

      Whereas, Booking.com B.V.'s ("Booking.com") Reconsideration Request, Request 13-5, sought reconsideration of the ICANN staff action of 26 February 2013, when the results of the String Similarity Panel were posted for the New gTLD Program, placing the applications for .hotels and .hoteis into a string similarity contention set.

      Whereas, the BGC considered the issues raised in Reconsideration Request 13-5.

      Whereas, the BGC recommended that Reconsideration Request 13-5 be denied because Booking.com has not stated proper grounds for reconsideration.

      Resolved (2013.09.10.NG02), the New gTLD Program Committee adopts the BGC Recommendation on Reconsideration Request 13-5, which can be found at http://www.icann.org/en/groups/board/governance/reconsideration/recommendation-booking-01aug13-en.pdf [PDF, 117 KB].

      Rationale for Resolution 2013.09.10.NG02

      ICANN's Bylaws call for the Board Governance Committee to evaluate and make recommendations to the Board with respect to Reconsideration Requests. See Article IV, section 3 of the Bylaws. The New gTLD Program Committee ("NGPC"), bestowed with the powers of the Board in this instance, has reviewed and thoroughly considered the BGC Recommendation on Reconsideration Request 13-5 and finds the analysis sound.

      Having a reconsideration process whereby the BGC reviews and, if it chooses, makes a recommendation to the Board/NGPC for approval positively affects ICANN's transparency and accountability. It provides an avenue for the community to ensure that staff and the Board are acting in accordance with ICANN's policies, Bylaws, and Articles of Incorporation.

      The Request seeks a reversal of the 26 February 2013 decision of the String Similarity Review Panel (the "Panel") to place Booking.com's application for .hotels in the same contention set as .hoteis. Specifically, Booking.com asserted that its applied for string of .hotels can co-exist in the root zone with the applied for string .hoteis without concern of confusability, and therefore, .hotels should not have been placed in the same contention set with .hoteis.

      The Request calls into consideration: (1) whether the Panel violated any policy or process in conducting its visual similarity review of Booking.com's application; and (2) whether the NGPC has the ability to overturn the Panel's decision on .hotels/.hoteis on the basis that the decision was provided as an "advice to ICANN" and that ICANN made the ultimate decision to accept that advice.

      The BGC noted that a similar reconsideration request was previously submitted by Booking.com on 28 March 2013 and placed on hold pending the completion of a request pursuant to ICANN's Documentary Information Disclosure Policy. Therefore, this Request relates back to the date of the original filing and should be evaluated under the Bylaws that were in effect from 20 December 2012 through 10 April 2013.

      In consideration of the first issue, the BGC reviewed the grounds stated in the Request, including the attachments, and concluded that Booking.com failed to adequately state a Request for Reconsideration of Staff action because they failed to identify any policy or process that was violated by Staff. The BGC noted that Booking.com does not suggest that the process for String Similarity Review set out in the Applicant Guidebook was not followed, or that ICANN staff violated any established ICANN policy in accepting the Panel's decision to place .hotels and .hoteis in the same contention set. Rather, Booking.com seeks to supplant what it believes the review methodology for assessing visual similarity should have been as opposed to the methodology set out in Section 2.2.1.1.2 of the Applicant Guidebook and asks that the BGC (and the Board through the New gTLD Program Committee) retry the 26 February 2013 decision based upon its proposed methodology. The BGC concluded that this is not sufficient ground for Reconsideration because the Reconsideration process is not available as a mechanism to re-try the decisions of the evaluation panels.

      With respect to Booking.com's contention that the 26 February 2013 decision was taken without material information, such as that of Booking.com's linguistic expert's opinion or other "information that would refute the mistaken contention that there is likely to be consumer confusion between '.hotels' and '.hoteis'", the BGC concluded that there is no process in the String Similarity Review for applicants to submit additional information. As ICANN has explained to Booking.com in response to its DIDP requests for documentation regarding the String Similarity Review, the Review was based upon the methodology in the Applicant Guidebook, supplemented by the Panel's process documentation; the process does not allow for additional inputs. The BGC noted that Booking.com's disagreement as to whether the methodology should have resulted in a finding of visual similarity does not mean that ICANN (including the third party vendors performing String Similarity Review) violated any policy in reaching the decision (nor does it support a conclusion that the decision was actually wrong).

      In consideration of the second issue, the BGC determined that Booking.com's suggestion that the Board (through the NGPC) has the ability to overturn the Panel's decision on .hotels/.hoteis because the Panel merely provided "advice to ICANN" and that ICANN made the ultimate decision to accept that advice is based upon inaccurate conclusions of the String Similarity Review process. As such, the BGC concluded that Booking.com has not stated sufficient grounds for reconsideration. The BGC noted that all applied for strings are reviewed the Panel according to the standards and methodology of the visual string similarity review set out in the Applicant Guidebook. The Guidebook clarifies that once contention sets are formed by the Panel, ICANN will notify the applicants and will publish results on its website. (AGB, Section 2.2.1.1.1.) Whether the results are transmitted as "advice" or "outcomes" or "reports", ICANN had always made clear that it would rely on the advice of its evaluators in the initial evaluation stage of the New gTLD Program, subject to quality assurance measures. The subsequent receipt and consideration of GAC advice on singular and plural strings does not change the established process for the development of contention sets based on visual similarity as the ICANN Board is required under the Bylaws to consider GAC Advice on issues of public policy, such as singular and plural strings. The BGC concluded that Booking.com is actually proposing a new and different process when it suggests that ICANN should perform substantive review (instead of process testing) over the results of the String Similarity Review Panel's outcomes prior to the finalization of contention sets.

      In addition to the above, the full BGC Recommendation that can be found at http://www.icann.org/en/groups/board/governance/reconsideration/recommendation-booking-01aug13-en.pdf [PDF, 117 KB] and that is attached to the Reference Materials to the Board Submission supporting this resolution, shall also be deemed a part of this Rationale.

      Adopting the BGC's recommendation has no financial impact on ICANN and will not negatively impact the systemic security, stability and resiliency of the domain name system.

      This decision is an Organizational Administrative Function that does not require public comment.

    3. GAC Communiqué Durban – Scorecard

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

      Whereas, on 1 August 2013, ICANN posted the Durban Communiqué 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.

      Whereas, the NGPC met on 12 August 2013 to consider a plan for responding to the GAC's advice on the New gTLD Program, transmitted to the Board through its Durban Communiqué.

      Whereas, the NGPC has considered the applicant responses submitted during the 21- day applicant response period, and the NGPC has identified items of advice in the attached scorecard where its position is consistent with the GAC's advice in the Durban Communiqué.

      Whereas, the NGPC developed a scorecard to respond to the GAC's advice in the Durban Communiqué similar to the one used to address the Beijing Advice as well as during the GAC and the 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.09.10.NG03), the NGPC adopts the "ICANN Board New gTLD Program Committee Scorecard in response to GAC Durban Communiqué" (10 September 2013), attached as Annex 1 [PDF, 119 KB] to this Resolution, in response to the items of GAC advice in the Durban Communiqué as presented in the scorecard.

      Rationale for Resolution 2013.09.10.NG03

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

      What is the proposal being considered?

      The NGPC is being asked to consider accepting the GAC's Durban advice as described in the attached ICANN Board New gTLD Program Committee Scorecard in response to GAC Durban Communiqué" (10 September 2013). As noted in the scorecard, most items of advice are scored as "1A," which indicates that the NGPC's position is consistent with GAC advice as described in the scorecard.

      Which stakeholders or others were consulted?

      On 1 August 2013, ICANN posted the 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/durban47. The NGPC has considered the applicant responses in formulating its response to the GAC advice as applicable.

      What concerns or issues were raised by the community?

      As part of the 21-day 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.

      What significant materials did the Board review?

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

      • Summary of Applicant Responses to GAC Advice in the Durban Communiqué (see reference materials).

      What factors did the Board find to be significant?

      In adopting its response to the GAC's advice in the Durban Communiqué, the NGPC considered the applicant comments submitted, the GAC's advice transmitted in the Durban 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 1 August 2013. This triggered the 21-day applicant response period pursuant to the Applicant Guidebook Module 3.1.

    4. GAC Communiqué Beijing – Scorecard

      No resolution taken.

    5. GAC Communiqué Beijing – Category 1

      No resolution taken.

    6. ALAC Statement on the Preferential Treatment for Community Applications in String Contention

      No resolution taken.

    7. ALAC Statement on Community Expertise in Community Priority Evaluation

      No resolution taken.

    8. AOB

      No resolution taken.

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