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. ALAC Statement on TMCH/Variants
    2. Safeguards Applicable to all New gTLDs
    3. Category 2 Safeguard Advice re Restricted and Exclusive Registry Access
    4. Singular & Plural Versions of the Same String as a TLD
    5. IGO Protection
    6. AOB

 

  1. Consent Agenda:

    1. Approval of NGPC Meeting Minutes

      Resolved (2013.06.25.NG01), the Board approves the minutes of the 4 June 2013 New gTLD Program Committee Meeting.

  2. Main Agenda:

    1. ALAC Statement on TMCH/Variants

      No resolution taken.

    2. Safeguards Applicable to all New gTLDs

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

      Whereas, the Beijing Communiqué included six (6) elements of safeguard advice applicable to all new gTLDs, which are identified in the GAC Register of Advice as: (a) 2013-04-11-Safeguards-1, (b) 2013-04-11-Safeguards-2, (c) 2013-04-11-Safeguards-3, (d) 2013-04-11-Safeguards-4, (e) 2013-04-11-Safeguards-5, and (f) 2013-04-11-Safeguards-6 (collectively, the "Safeguards Applicable to All Strings");

      Whereas, on 23 April 2013, ICANN initiated a public comment forum to solicit the community's input on how the NGPC should address 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>;

      Whereas, the NGPC met on 8 and 18 May and 4, 11 and 18 June 2013 to consider a plan for responding to the GAC's advice on the New gTLD Program, including the Safeguards Applicable to All Strings;

      Whereas, the NGPC met on 25 June 2013 to further discuss and consider its plan for responding the GAC's advice in the Beijing Communiqué on the New gTLD Program;

      Whereas, the NGPC has considered the public comments submitted during the public comment forum, and has determined that its position, as presented in Annex I [PDF, 72 KB] attached to this Resolution, is consistent with the GAC's advice regarding Safeguards Applicable to All Strings;

      Whereas, the NGPC proposes revisions to the final draft of the New gTLD Registry Agreement <http://www.icann.org/en/news/public-comment/base-agreement-29apr13-en.htm> as presented in Annex II [PDF, 64 KB] attached to this Resolution to implement certain elements of the GAC advice regarding Safeguards Applicable to All Strings; and

      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.06.25.NG02), the NGPC adopts the "NGPC Proposal for Implementation of GAC Safeguards Applicable to All New gTLDs" (19 June 2013), attached as Annex I [PDF, 72 KB] to this Resolution, to accept the GAC's advice regarding Safeguards Applicable to All Strings.

      Resolved (2013.06.25.NG03), the NGPC directs staff to make appropriate changes to the final draft of the New gTLD Registry Agreement, as presented in Annex II [PDF, 64 KB] attached to this Resolution, to implement certain elements of the GAC advice regarding Safeguards Applicable to All Strings.

      Rationale for Resolutions 2013.06.25.NG02 – 2013.06.25.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 Beijing Communiqué dated 11 April 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 a discrete grouping of the GAC advice as described in the attached "NGPC Proposal for Implementation of GAC Safeguards Applicable to All New gTLDs" (Annex I [PDF, 72 KB]; 19 June 2013), which includes the six (6) items of safeguard advice from the Beijing Communiqué applicable to all new gTLDs. This advice is identified in the GAC Register of Advice as: (a) 2013-04-11-Safeguards-1, (b) 2013-04-11-Safeguards-2, (c) 2013-04-11-Safeguards-3, (d) 2013-04-11-Safeguards-4, (e) 2013-04-11-Safeguards-5, and (f) 2013-04-11-Safeguards-6 (collectively, the "Safeguards Applicable to All Strings").

      Which stakeholders or others were consulted?

      On 23 April 2013, ICANN initiated a public comment forum to solicit input on how the NGPC should address 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 public comment forum closed on 4 June 2013. The NGPC has considered the community's comments in formulating its response to the GAC advice regarding Safeguards Applicable to All Strings. These comments also will serve as important inputs to the NGPC's future consideration of the other elements of GAC advice not being considered at this time in the attached annexes.

      What concerns or issues were raised by the community?

      ICANN received several responses from the community during the course of the public comment forum on broad categories of GAC safeguard advice. Of comments regarding safeguards applicable to all new gTLDs, approximately 29% of unique commenters expressed opposition whereas approximately 71% expressed support.

      Regarding support, commenters expressed general agreement with the safeguards. Those expressing support also expressed concern over the method of implementation and that the GAC should not dictate the specific procedures for implementation. Supporters also indicated that some of these safeguards are already inherent in the 2013 RAA.

      In adopting this Resolution, the NGPC specifically acknowledges comments from the community opposed to the NGPC accepting the GAC's advice. The NGPC takes note of comments asserting that adopting the GAC advice threatens the multi-stakeholder policy development process. ICANN's Bylaws permit the GAC to "consider and provide advice on the activities of ICANN as they relate to concerns of governments, particularly matters where there may be an interaction between ICANN's policies and various laws and international agreements or where they may affect public policy issues." (Art. XI, § 2.1.a) The GAC issued advice to the Board on the New gTLD Program through its Beijing Communiqué dated 11 April 2013. The ICANN Bylaws require the Board (and the NGPC) to take into account the GAC's advice on public policy matters in the formulation and adoption of the polices, and if the Board (and the NGPC) takes 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 parties must then try in good faith to find a mutually acceptable solution. Thus, the GAC's advice is part of the multi-stakeholder process.

      The posting of the Beijing Communiqué to solicit public comment on the broad categories of the GAC's safeguard advice demonstrates ICANN's commitment to a bottom-up, multi-stakeholder model, and provided stakeholders with approximately six weeks (including the public comment and reply periods) to analyze, review and respond to the proposed recommendations. The NGPC views finding a workable solution to the GAC's advice as a step forward as the community continues to respond to the needs of registrants, the community and all stakeholders.

      The NGPC also took note of the comments from the community in opposition to ICANN implementing the safeguard advice concerning WHOIS verification checks to be performed by registry operators. The NGPC acknowledges the ongoing work in the community on WHOIS verification. In response to these comments in opposition, the NGPC accepted the spirit and intent of the GAC's advice on the WHOIS verification checks by having ICANN, instead of registry operators, implement the checks. ICANN is concluding its development of a WHOIS tool that gives it the ability to check false, incomplete or inaccurate WHOIS data, as the Board previously directed staff in Board Resolutions 2012.11.08.01 - 2012.11.08.02 to begin to "proactively identify potentially inaccurate gTLD data registration in gTLD registry and registrar services, explore using automated tools, and forward potentially inaccurate records to gTLD registrars for action; and 2) publicly report on the resulting actions to encourage improved accuracy." <http://www.icann.org/en/groups/board/documents/resolutions-08nov12-en.htm>. Given these ongoing activities, the NGPC determined that ICANN (instead of Registry Operators) is well positioned to implement the GAC's advice.

      With respect to mitigating abusive activity, the NGPC acknowledges the comments noting that registries do not have relationships with registrants and should not be required to determine whether a registrant is in compliance with applicable laws. To address this concern, the NGPC included language in the PIC Specification that would obligate registry operators to include a provision in their Registry-Registrar Agreements that requires registrars to include in their Registration Agreements a provision prohibiting registered name holders from distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law, and providing (consistent with applicable law and any related procedures) consequences for such activities including suspension of the domain name.

      With respect to the safeguards regarding security checks, the NGPC considered that the comments in opposition raise important questions about the costs and timing of implementing this measure, and the scope and framework of the security checks. The NGPC is mindful that there are various ways a registry operator could implement the required security checks, and has taken these concerns into consideration in its response to the GAC's advice. The NGPC's response directs ICANN to solicit community participation (including conferring with the GAC) in a task force or through a policy development process in the GNSO, as appropriate, to develop the framework for Registry Operators to respond to identified security risks that pose an actual risk of harm, notification procedures, and appropriate consequences, including a process for suspending domain names until the matter is resolved, while respecting privacy and confidentiality. The proposed implementation of the GAC's advice is phased to account for the commenters' concerns. The proposed language in the PIC Specification will provide the general guidelines for what registry operators must do, but omits the specific details from the contractual language to allow for the future development and evolution of the parameters for conducting security checks.

      With respect to consequences in the safeguards applicable to all strings, the NGPC took note of the commenters' concerns that this item of safeguard advice is already addressed in the 2013 RAA and by the WHOIS Data Problem Report system. The GAC's concerns are addressed in the existing framework and the NGPC is not proposing to duplicate the existing enforcement models.

      The NGPC also takes note of the comments requesting that the GAC advice be rejected as "last-minute" or "untimely." The commenters asserted that this introduces uncertainty into the Program and the makes material changes to the AGB. As an alternative to accepting the advice, the NGPC considered the timing consequences if the NGPC rejected the advice. The NGPC took note of the procedure for any consultations that might be needed if the Board (and the NGPC) determines to take an action that is not consistent with GAC advice, which was developed by the ICANN Board-GAC Recommendation Implementation Working Group (BGRI-WG). The procedure was approved by the BGRI-WG in Beijing and would be used for any consultation on this GAC advice. The procedure says that the consultation process should conclude within six months, but that the GAC and the Board can agree to a different timetable. On balance, the NGPC determined that entering into a consultation process on this particular section of the safeguard advice would introduce greater uncertainty into the Program than if the NGPC found a workable solution to accept and implement the GAC's safeguard advice applicable to all strings.

      The complete set of comments can be reviewed at: http://www.icann.org/en/news/public-comment/gac-safeguard-advice-23apr13-en.htm.

      What significant materials did the NGPC review?

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

      GAC Beijing Communiqué: http://www.icann.org/en/news/correspondence/gac-to-board-18apr13-en.pdf [PDF, 156 KB]

      Public comments in response to broad categories of GAC safeguard advice: http://www.icann.org/en/news/public-comment/gac-safeguard-advice-23apr13-en.htm

      Report of Public Comments, New gTLD Board Committee Consideration of GAC Safeguard Advice dated 18 June 2013: http://www.icann.org/en/news/public-comment/report-comments-gac-safeguard-advice-19jun13-en

      What factors did the NGPC find to be significant?

      The Beijing Communiqué generated significant interest from the community and resulted in many comments. The NGPC considered the community comments, the GAC's advice transmitted in the Beijing Communiqué, and the procedures established in the AGB for addressing GAC advice to the New gTLD Program.

      Are there positive or negative community impacts?

      The adoption of the GAC advice as provided in the attached annexes 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?

      On 23 April 2013, ICANN initiated a public comment forum to solicit input on how the NGPC should address 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 public comment forum closed on 4 June 2013.

    3. Category 2 Safeguard Advice re Restricted and Exclusive Registry Access

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

      Whereas, the Beijing Communiqué included Category 2 safeguard advice, which is identified in the GAC Register of Advice as 2013-04-11-Safeguards-Categories-2 (the "Category 2 Safeguard Advice");

      Whereas, on 23 April 2013, ICANN initiated a public comment forum to solicit the community's input on how the NGPC should address 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>;

      Whereas, the NGPC met on 8 and 18 May and 4, 11 and 18 June 2013 to consider a plan for responding to the GAC's advice on the New gTLD Program, including the Category 2 Safeguard Advice;

      Whereas, the NGPC met on 25 June 2013 to further discuss and consider its plan for responding the GAC's advice in the Beijing Communiqué on the New gTLD Program;

      Whereas, the NGPC has considered the public comments submitted during the public comment forum, and proposes revisions to the final draft of the New gTLD Registry Agreement <http://www.icann.org/en/news/public-comment/base-agreement-29apr13-en.htm> as presented in Annex I [PDF, 52 KB] attached to this Resolution to implement the Category 2 Safeguard Advice for applicants not seeking to impose exclusive registry access; and

      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.06.25.NG04), the NGPC adopts the "Proposed PIC Spec Implementation of GAC Category 2 Safeguards" (20 June 2013), attached as Annex I [PDF, 52 KB] to this Resolution, to accept and implement the GAC's Category 2 Safeguard Advice for applicants not seeking to impose exclusive registry access.

      Resolved (2013.06.25.NG05), the NGPC directs staff to make appropriate changes to the final draft of the New gTLD Registry Agreement, as presented in Annex I [PDF, 52 KB] attached to this Resolution, to implement the GAC's Category 2 Safeguard Advice for applicants not seeking to impose exclusive registry access.

      Resolved (2013.06.25.NG06), the NGPC directs staff to defer moving forward with the contracting process for applicants seeking to impose exclusive registry access for "generic strings" to a single person or entity and/or that person's or entity's Affiliates (as defined in Section 2.9(c) of the Registry Agreement), pending a dialogue with the GAC.

      Rationale for Resolutions 2013.06.25.NG04 – 2013.06.25.06

      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 Beijing Communiqué dated 11 April 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 Category 2 safeguard advice identified in the GAC Register of Advice as 2013-04-11-Safeguards-Categories-2. For applicants not seeking to impose exclusive registry access, the NGPC is being asked to consider including a provision in the PIC Specification in the New gTLD Registry Agreement that would require TLDs to operate in a transparent manner consistent with general principles of openness and non-discrimination. Additionally, the proposed PIC Specification would include a provision to preclude registry operators from imposing eligibility criteria that limit registration of a generic string exclusively to a single person or entity and their "affiliates." The term "affiliate" is defined to mean a person or entity that, directly or indirectly, through one or more intermediaries, controls, is controlled by, or is under common control with, the person or entity specified, and "control" (including the terms "controlled by" and "under common control with") means the possession, directly or indirectly, of the power to direct or cause the direction of the management or policies of a person or entity, whether through the ownership of securities, as trustee or executor, by serving as an employee or a member of a board of directors or equivalent governing body, by contract, by credit arrangement or otherwise. [New gTLD Registry Agreement § 2.9(c) http://newgtlds.icann.org/en/applicants/agb/base-agreement-specs-29apr13-en.pdf [PDF, 600 KB]]

      For applicants seeking to impose exclusive registry access for "generic strings", the NGPC is being asked to defer moving forward with the contracting process for these applicants, pending a dialogue with the GAC. The term "generic string" is defined in the PIC Specification to mean "a string consisting of a word or term that denominates or describes a general class of goods, services, groups, organizations or things, as opposed to distinguishing a specific brand of goods, services, groups, organizations or things from those of others."

      To implement the advice in this way, the PIC Specification will define exclusive registry access as limiting registration of a generic string exclusively to a single person or entity and their affiliates (as defined above). All applicants would be required to respond by a specified date indicating whether (a) the applicant is prepared to accept the proposed PIC Specification that precludes exclusive registry access or (b) the applicant is unwilling to accept the proposed PIC Specification because the applicant intends to implement exclusive registry access.

      Which stakeholders or others were consulted?

      On 23 April 2013, ICANN initiated a public comment forum to solicit input on how the NGPC should address 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 public comment forum closed on 4 June 2013. The NGPC has considered the community comments in formulating its response to the GAC's Category 2 Safeguard Advice.

      What concerns or issues were raised by the community?

      ICANN received several responses from the community during the course of the public comment forum on broad categories of GAC safeguard advice. Of the limited number of comments specific to the Category 2, Restricted Access safeguards, approximately 60% expressed support versus approximately 40% expressing concern or opposition. Supporting comments generally agreed that, for certain strings, restricted access is warranted. Opposing comments generally indicated that this is unanticipated and wholly new policy without justification and that these strings would be unfairly prejudiced in the consumer marketplace. Of the comments specific to the Category 2, Exclusive Access safeguards, approximately 86% expressed support versus approximately 14% expressing concern or opposition. Supporting comments indicated that exclusive registry access should "serve a public purpose." Others indicated that "closed generics" should not be allowed at all.

      In adopting this Resolution, the NGPC specifically acknowledges comments from the community opposed to the NGPC accepting the GAC's advice. Opposing commenters generally expressed concern that this is new and unanticipated policy, contrary to the bottom-up process. They also indicated that the concept of public interest is vague and not adequately defined. The NGPC notes that the Beijing Communiqué was published to solicit public comment on the broad categories of the GAC's safeguard advice. This demonstrates ICANN's commitment to a bottom-up, multi-stakeholder model, and provided stakeholders with approximately six weeks (including the public comment and reply periods) to analyze, review and respond to the proposed recommendations. The NGPC views finding a workable solution to the GAC's advice as a step forward as the community continues to respond to the needs of registrants, the community and all stakeholders.

      For the comments specifically concerning restricted registry access (i.e. Paragraph 1 of the Category 2 Advice), the NGPC takes note of the concerns expressed in the comments regarding the "general rule" that a TLD should be operated in an open manner. The NGPC understands the GAC's advice for TLDs for which registration is restricted to generally be operated in an open manner to be a call for transparency, which is fundamental to providing consumers choice in the marketplace, and a goal that ICANN supports. In light of the comments raised, ICANN included new language in the PIC Specification to accept and respond to the GAC advice regarding restricted access in a way that balances the concerns raised in the public comments with the GAC's advice for restricted TLDs. The revised PIC Specification establishes what it means for a TLD to be operated consistent with principals of openness and non-discrimination. Specifically, by establishing, publishing and adhering to clear registration policies, the TLD would fulfill its obligation to be operated in a "transparent manner consistent with general principles of openness and non-discrimination."

      With respect to comments specifically regarding exclusive registry access safeguards (i.e. Paragraph 2 of the Category 2 Advice), the NGPC understands that the GAC and other members of the community have expressed concerns regarding "closed generic" TLDs. In February 2013, the NGPC directed ICANN staff to initiate a public comment period on the issue of closed generic TLD applications so that the NGPC could understand and consider all views and potential ramifications related to closed generic TLDs. <http://www.icann.org/en/news/announcements/announcement-2-05feb13-en.htm>. In light of the comments raised in this public comment forum, the closed generics public comment forum, and the GAC advice, ICANN is proposing a way for a large number of strings to move forward while the community continues to work through the issue.

      While respecting the community's comments, the NGPC revised the PIC Specification to address the GAC's advice regarding exclusive registry access. The proposed PIC Specification includes a provision to preclude registry operators from imposing eligibility criteria that limit registration of a generic string exclusively to a single person or entity and their "affiliates." The definition for "affiliates" is the definition in Section 2.9(c) of the New gTLD Registry Agreement. For applicants seeking to impose exclusive registry access for "generic strings", the NGPC agrees to defer moving forward with the contracting process for these applicants, pending a dialogue with the GAC to seek clarification regarding aspects of the advice, including key definitions, and its implementation. Revising the PIC Specification in this way permits the greatest number of strings to continue moving forward while recognizing the concerns raised in the community's comments, including additional policy work.

      The complete set of public comments can be reviewed at: http://www.icann.org/en/news/public-comment/gac-safeguard-advice-23apr13-en.htm.

      What significant materials did the NGPC review?

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

      GAC Beijing Communiqué: http://www.icann.org/en/news/correspondence/gac-to-board-18apr13-en.pdf [PDF, 156 KB]

      Public comments in response to broad categories of GAC safeguard advice: http://www.icann.org/en/news/public-comment/gac-safeguard-advice-23apr13-en.htm

      Report of Public Comments, New gTLD Board Committee Consideration of GAC Safeguard Advice dated 18 June 2013: http://www.icann.org/en/news/public-comment/report-comments-gac-safeguard-advice-19jun13-en

      What factors did the Board find to be significant?

      The Beijing Communiqué generated significant interest from the community and stimulated many comments. The NGPC considered the community comments, the GAC's advice transmitted in the Beijing Communiqué, and the procedures established in the AGB for addressing GAC advice to the New gTLD Program.

      Are there positive or negative community impacts?

      The adoption of the GAC advice as provided in the attached Annex I [PDF, 52 KB] 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. However, applicants seeking to impose exclusive registry access would not be able to progress to the contracting process at this time if the NGPC adopts the proposed Resolution. Those applicants would be on hold pending the outcome of the dialogue with the GAC.

      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?

      On 23 April 2013, ICANN initiated a public comment forum to solicit input on how the NGPC should address 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 public comment forum closed on 4 June 2013.

    4. Singular & Plural Versions of the Same String as a TLD

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

      Whereas, the NGPC met on 8 and 18 May and 4 and 11 June 2013, to consider a plan for responding to the GAC's advice on the New gTLD Program, transmitted to the Board through its Beijing Communiqué;

      Whereas, on 4 June 2013, the NGPC took action accepting GAC advice identified in the GAC Register of Advice as "2013-04-11-PluralStrings" and agreed to consider whether to allow singular and plural versions of the same string;

      Whereas, the NGPC met on 11 June 2013 to consider the GAC Beijing advice regarding singular and plural versions of the same string; and

      Whereas, after careful consideration of the issues, review of the comments raised by the community, the process documents of the expert review panels, and deliberations by the NGPC, the NGPC has determined that no changes to the ABG are needed to address potential consumer confusion specifically resulting from allowing singular and plural versions of the same strings;

      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.06.25.NG07), the NGPC has determined that no changes are needed to the existing mechanisms in the Applicant Guidebook to address potential consumer confusion resulting from allowing singular and plural versions of the same string.

      Rationale for Resolution 2013.06.25.NG07

      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 Beijing Communiqué dated 11 April 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.

      In its Beijing Communiqué, the GAC advised the Board that due to potential consumer confusion, the Board should "reconsider its decision to allow singular and plural version of the same strings." On 4 June 2013, the NGPC accepted the GAC's advice to consider this issue. The NGPC met on 11 June 2013 to discuss this advice, and to consider whether any changes are needed to the New gTLD Program to address singular and plural versions of the same string.

      What is the proposal being considered?

      The NGPC is considering whether any changes are needed to the New gTLD Program (i.e. the Applicant Guidebook) as a result of the NGPC considering whether to allow singular and plural versions of the same strings as requested by the GAC in its Beijing Communiqué.

      Which stakeholders or others were consulted?

      On 18 April 2013, ICANN posted the 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 <http://newgtlds.icann.org/en/applicants/gac-advice-responses>. The NGPC considered the applicant responses in considering this issue.

      To note, a handful of unique applicants, representing nearly 400 application responses, addressed this piece of GAC advice. Most were against changing the existing policy but with one identified in support of the GAC's concern. The supporting applicant has filed a string confusion objection. Those not supporting the GAC's concern indicated this topic was agreed as part of the AGB and is addressed in the evaluation processes. The full summary of applicant responses can be reviewed at: <http://newgtlds.icann.org/en/applicants/gac-advice-responses>.

      What concerns or issues were raised by the community?

      In September 2007, the GNSO issued a set of recommendations (approved by the ICANN Board in June 2008) to implement a process to allow for the introduction of new gTLDs. These include a recommendation that new gTLD strings must not be confusingly similar to an existing top-level domain or a reserved name. The GNSO constituency groups lodged comments during that time, and these comments were considered as part of the approval of the Program. The NGPC considered these community comments as part of its deliberations.

      More recently, ICANN posted the GAC's Beijing Communiqué 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 AGB Module 3.1. Multiple members of the ICANN and New gTLD applicant communities have raised concerns to the ICANN Board regarding the GAC's advice regarding singular and plural versions of the same string. Some of the concerns raised by the community are as follows:

      • Allowing singular and plural versions of the same string amounts to a "serious flaw" in the Program, and the Program should not rely on the self-interest of others to file objections to avoid string confusion.
      • The independent panels have ruled and it would not be appropriate for either ICANN or the Board to overturn these decisions. The findings of the independent string similarity review panel should not be upset, absent a finding of misconduct.
      • The Board approved the evaluation process, which included independent assessment of each application against AGB criteria, appropriately away from the interests of those with stakes in the outcome.
      • ICANN should not change course on this issue, as it would open the door to one stakeholder group undoing independently arrived-at results because it disagrees with the outcome.

      The concerns raised by the community highlight the difficulty of the issue and the tension that exists between minimizing user confusion while encouraging creativity, expression and competition. The NGPC weighed these comments during its deliberations on the issue.

      What significant materials did the NGPC review?

      The NGPC reviewed and considered the following significant materials as part of its consideration of the issue:

      What factors did the NGPC find to be significant?

      The NGPC considered several significant factors during its deliberations about whether to allow singular and plural version of the same strings. The NGPC had to balance the competing interests of each factor to arrive at a decision. The following are among the factors the NGPC found to be significant:

      • The NGPC considered whether it was appropriate to reject the work of the expert review panel and apply its own judgment to a determination of what rises to the level of probable user confusion. The NGPC considered whether the evaluation process would be undermined if it were to exert its own non-expert opinion and override the determination of the expert panel. It also considered whether taking an action to make program changes would cause a ripple effect and re-open the decisions of all expert panels.

        The NGPC considered that the objective of the string similarity review in the AGB is to prevent user confusion and loss of confidence in the DNS resulting from delegation of many similar strings. In the AGB, "similar" means strings so similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone. During the policy development and implementation design phases of the New gTLD Program, aural and conceptual string similarities were considered. These types of similarity were discussed at length, yet ultimately not agreed to be used as a basis for the analysis of the string similarity panels' consideration because on balance, this could have unanticipated results in limiting the expansion of the DNS as well as the reach and utility of the Internet. However, the grounds for string confusion objections include all types of similarity, including visual, aural, or similarity of meaning. All new gTLD applicants had standing to file a string confusion objection against another application.

      • The NGPC considered the objective function of the string similarity algorithm in the AGB (§ 2.2.1.1.2) and the results it produced. SWORD assisted ICANN with the creation of an algorithm that helped automate the process for objectively assessing similarity among proposed and existing TLD strings. Various patent and trademark offices throughout the world use SWORD's verbal search algorithms. The String Similarity Panel was informed in part by the algorithmic score for the visual similarity between each applied-for string and each of other existing and applied-for TLDs and reserved names. The score provided one objective measure for consideration by the panel, as part of the process of identifying strings likely to result in user confusion. However, this score was only indicative and the panel's final determination was based on careful review and analysis. A full consideration of potential consumer confusion issues is built into the procedures that have been applied in the analysis of the strings.

      • The NGPC reflected on existing string similarity in the DNS and considered the positive and negative impacts. The NGPC observed that numerous examples of similar strings, including singulars and plurals exist within the DNS at the second level. Many of these are not registered to or operated by the same registrant. There are thousands of examples including:

        auto.com autos.com
        car.com cars.com
        new.com news.com
        store.com stores.com
      • The NGPC considered the process used by the panel of experts from InterConnect Communications working in conjunction with the University College London to perform a visual similarity review to prevent used confusion and loss of confidence in the DNS resulting fro the delegation of similar strings. The panel made its assessments using the standard defined in the Applicant Guidebook: String confusion exists where a string so nearly resembles another visually that it is likely to deceive or cause confusion. For the likelihood of confusion to exist, it must be probable, not merely possible that confusion will arise in the mind of the average, reasonable Internet user. Mere association, in the sense that the string brings another string to mind, is insufficient to find a likelihood of confusion. This panel utilized its independent expertise, including in linguistics, to perform the review against the criteria in the Applicant Guidebook. ICANN did not provide any instructions to the panel outside of the criteria specified in the Applicant Guidebook, including any pre-judgment of whether singular or plural versions of strings should be considered visually similar.

      • The NGPC considered whether there were alternative methods to address potential user confusion if singular and plural versions of the same string are allowed to proceed. The NGPC discussed the String Confusion Objection mechanism in the AGB, and noted that string confusion objections are not limited to visual similarity, but may include any type of similarity, including visual, aural, or similarity of meaning. The DRSP panels reviewing string confusion objections use the following standard for assessing string confusion, as specified in the Applicant Guidebook: String confusion exists where a string so nearly resembles another that it is likely to deceive or cause confusion. For a likelihood of confusion to exist, it must be probable, not merely possible that confusion will arise in the mind of the average, reasonable Internet user. Mere association, in the sense that the string brings another string to mind, is insufficient to find a likelihood of confusion. The NGPC took note of the fact that in the case of a successful string confusion objection, either the application would not proceed (for an objection by an existing gTLD operator) or an existing contention set would be modified to include the application subject to the objection (for an objection by another gTLD applicant).

      • The NGPC took note of the objections filed during the objection period, which closed on 13 March 2013. All new gTLD applicants had standing to file a string confusion objection against another application. By the end of the objection period, a total of 67 string confusion objections were filed (see http://newgtlds.icann.org/en/program-status/odr/filings). Based on staff analysis, there were a total of 26 singular/plural applied-for, English language strings. The strings in these pairs had a total of 21 string similarity objections filed against them.

      Are there positive or negative community impacts?

      The string similarity review is the implementation of the GNSO's policy recommendation 2: "Strings must not be confusingly similar to an existing top-level domain or a Reserved Name." As noted above, the objective of the string similarity review is to prevent user confusion and loss of confidence in the DNS resulting from delegation of many similar strings. A full consideration of potential consumer confusion issues is built into the procedures that have been applied in the analysis of the strings. The adoption of the proposed resolution will assist with continuing to resolve 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?

      The security, stability and resiliency issues relating to the DNS were considered when the AGB was adopted. The NGPC's decision does not propose any changes to the existing program in the AGB, and thus there are no additional foreseen issues related to the security, stability or resiliency of 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 18 April 2013 <http://newgtlds.icann.org/en/announcements-and-media/announcement-18apr13-en>. This triggered the 21-day applicant response period pursuant to the Applicant Guidebook Module 3.1. No additional public comment is required as the NGPC's action does not propose any policy or program changes to the New gTLD Program.

    5. IGO Protection

      No resolution taken.

    6. AOB

      No resolution taken.

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