Skip to main content
Resources

Approved Resolutions | Meeting of the New gTLD Program Committee

12 – 14 October 2014

  1. Consent Agenda:
    1. Approval of Minutes
  2. Main Agenda:
    1. GAC Advice in Beijing Communiqué regarding Category 2 Safeguards – Exclusive Registry Access
    2. Perceived Inconsistent String Confusion Objection Expert Determinations
    3. Reconsideration Request 14-37, I-Registry Ltd
    4. GAC Advice regarding Protections for the Red Cross and Red Crescent – Singapore Communiqué
    5. Any Other Business

 

The ICANN Board New gTLD Program Committee meeting on 12 October 2014 was continued to 14 October 2014. The following resolutions were adopted during the meeting:

  1. Consent Agenda:

    1. Approval of Minutes

      Resolved (2014.10.12.NG01), the Board New gTLD Program Committee (NGPC) approves the minutes of its 8 September 2014 meeting.

  2. Main Agenda:

    1. GAC Advice in Beijing Communiqué regarding Category 2 Safeguards – Exclusive Registry Access

      No resolution taken.

    2. Perceived Inconsistent String Confusion Objection Expert Determinations

      Whereas, on 10 October 2013 the Board Governance Committee (BGC) requested that staff draft a report for the NGPC on String Confusion Objections (SCOs) "setting out options for dealing with the situation raised within this [Reconsideration] Request, namely the differing outcomes of the String Confusion Objection Dispute Resolution process in similar disputes involving Amazon's Applied – for String and TLDH's Applied-for String."

      Whereas, the NGPC considered potential paths forward to address perceived inconsistent Expert Determinations from the New gTLD Program SCO process, including possibly implementing a new review mechanism.

      Whereas, on 5 February 2014, the ICANN Board New gTLD Program Committee (NGPC) directed the ICANN President and CEO, or his designee, to initiate a public comment period on framework principles of a potential review mechanism to address perceived inconsistent String Confusion Objection Expert Determinations (the "proposed review mechanism"). The proposed review mechanism, if adopted, would have been limited to the String Confusion Objection Expert Determinations for .CAR/.CARS and .CAM/.COM, and would have constituted a change to the Objection process set forth in the New gTLD Applicant Guidebook.

      Whereas, the NGPC has carefully considered the report that the BGC asked staff to draft in response to Reconsideration Request 13-9, the received public comments to the proposed review mechanism, other comments provided to the NGPC for consideration, as well as the processes set out in the Applicant Guidebook.

      Whereas, as set out in the Applicant Guidebook, ICANN has reserved the right to individually consider any application for a new gTLD to determine whether approval would be in the best interest of the Internet community.

      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 (2014.10.12.NG02), the NGPC has identified the following String Confusion Objection Expert Determinations as not being in the best interest of the New gTLD Program and the Internet community:

      SCO Expert Determinations for Review String Related SCO Expert Determinations
      VeriSign Inc. (Objector) v. United TLD Holdco Ltd. (Applicant) .CAM [PDF, 5.96 MB]
      Commercial Connect LLC (Objector) v. Amazon EU S.à r.l. (Applicant) .通販 [PDF, 73 KB]1 Top Level Domain Holdings Limited [PDF, 721 KB](.购物)

      Resolved (2014.10.12.NG03), the NGPC directs the President and CEO, or his designee(s), take all steps necessary to establish processes and procedures, in accordance with this resolution and related rationale, pursuant to which the International Centre for Dispute Resolution (ICDR) shall establish a three-member panel to re-evaluate the materials presented, and the Expert Determinations, in the two objection proceedings set out in the chart above under the "SCO Expert Determinations for Review" column and render a Final Expert Determination on these two proceedings. In doing so, the NGPC recommends that the three-member panel also review as background the "Related SCO Expert Determinations" referenced in the above chart.

      Rationale for Resolutions 2014.10.12.NG02 – 2014.10.12.NG03

      Today, the NGPC is taking action to address perceived inconsistent and unreasonable Expert Determinations resulting from the New gTLD Program String Confusion Objections process. The NGPC's action today is part of its role to provide general oversight of the New gTLD Program. One component of the NGPC's responsibilities is "resolving issues relating to the approval of applications and the delegation of gTLDs pursuant to the New gTLD Program for the current round of the Program." (See NGPC Charter, Section II.D).

      The New gTLD Applicant Guidebook (AGB or Guidebook) identifies four grounds upon which a formal objection may be filed against an applied-for string. One such objection is a String Confusion Objection or SCO, which may be filed by an objector (meeting the standing requirements) if the objector believes that an applied-for gTLD string is confusingly similar to an existing TLD or to another applied-for gTLD string in the same round of applications. If successful, an SCO could change the configuration of the preliminary contention sets in that the two applied-for gTLD strings at issue in the objection proceedings will be considered in direct contention with one another (see AGB Module 4, String Contention Procedures). All SCO proceedings were administered by the International Centre for Dispute Resolution (ICDR), and Expert Determinations in all such proceedings have been issued.

      Some stakeholders have raised concerns about the perceived inconsistencies with or unreasonableness of certain SCO Expert Determinations. The NGPC has monitored these concerns over the past year, and discussed the issue at several of its meetings. On 10 October 2013, the Board Governance Committee (BGC) asked staff to draft a report for the NGPC on String Confusion Objections "setting out options for dealing with the situation raised within this Request, namely the differing outcomes of the String Confusion Objection Dispute Resolution process in similar disputes involving Amazon 's Applied – for String and TLDH's Applied-for String." (See http://www.icann.org/en/groups/board/governance/reconsideration/recommendation-amazon-10oct13-en.pdf [PDF, 131 KB]).

      In light of the BGC request following its consideration of Reconsideration Requests 13-9 and 13-10, and community-raised concerns about perceived inconsistent SCO Expert Determinations, the NGPC considered its options, including possibly implementing a review mechanism not contemplated in the Applicant Guidebook that would be available in limited circumstances.

      On 5 February 2014, the NGPC directed the ICANN President and CEO to initiate a public comment period on framework principles of a potential review mechanism to address the perceived inconsistent String Confusion Objection Expert Determinations. The proposed review mechanism, as drafted and posted for public comment, would be limited to the SCO Expert Determinations for .CAR/.CARS and .CAM/.COM. The public comment period on the proposed review mechanism closed on 3 April 2014, and a summary of the comments [PDF, 165 KB] has been publicly posted.

      At this time, the NGPC is taking action to address certain perceived inconsistent or otherwise unreasonable SCO Expert Determinations by sending back to the ICDR for a three-member panel evaluation of certain Expert Determinations. The NGPC has identified these Expert Determinations as not in the best interest of the New gTLD Program and the Internet community. The ICDR will be provided supplemental rules to guide the review of the identified Expert Determinations, which include the following:

      • The review panel will consist of three members appointed by the ICDR (the "Review Panel").

      • The only issue subject to review by the Review Panel shall be the SCO Expert Determinations identified in these resolutions.

      • The record on review shall be limited to the transcript of the proceeding giving rise to the original Expert Determination, if any, expert reports, documentary evidence admitted into evidence during the original proceeding, or other evidence relevant to the review that was presented at the original proceeding. No additional documents, briefs or other evidence may be submitted for consideration, except that it is recommended that the Review Panel consider the identified "Related SCO Expert Determinations" in the above chart as part of its review.

      • The standard of review to be applied by the Review Panel is: whether the original Expert Panel could have reasonably come to the decision reached on the underlying SCO through an appropriate application of the standard of review as set forth in the Applicant Guidebook and the ICDR Supplementary Procedures for ICANN's New gTLD Program.

      • ICANN will pay the applicable fees to conduct the review by the Review Panel.

      • The possible outcomes of the review are: (1) the original Expert Determination is supported by the standard of review and reference to the identified related Expert Determinations, and will stand as is; or (2) the original Expert Determination reasonably cannot be supported based on the standard of review and reference to the identified related Expert Determinations, and will be reversed. The Review Panel will submit a written determination including an explanation and rationale for its determination.

      As part of its months-long deliberations on this issue, the following are among the factors the NGPC found to be significant:

      1. The NGPC notes that the Guidebook was developed by the community in a multi-stakeholder process over several years. The NGPC considered whether it was appropriate to change the Guidebook at this time to implement a review mechanism to address certain perceived inconsistent Expert Determinations. On 18 April 2013, ICANN posted a proposed review mechanism for public comment. The NGPC carefully considered the public comments received. The NGPC notes that comments submitted during the public comment period generally fell into the following categories and themes, each of which is discussed more fully in the summary of public comments:

        1. Do not adopt the proposed review mechanism.

        2. Adopt the proposed review mechanism.

        3. Adopt a review mechanism with an expanded scope.

        4. Do not adopt the proposed review mechanism or expand the scope.

        5. Adopt some form of review, but not necessarily the one posted for public comment.

        6. Recommended modifications to the framework principles of the proposed review mechanism, if any review mechanism is adopted.

        The comments presented by various stakeholders highlight the difficulty of the issue and the tension that exists between balancing concerns about perceived inconsistent Expert Determinations, and the processes set forth in the Guidebook that were the subject of multiple rounds of public comment over several years.

        As highlighted in many of the public comments, adopting a review mechanism this far along in the process could potentially be unfair because applicants agreed to the processes included in the Guidebook, which did not include this review mechanism, and applicants relied on these processes. The NGPC acknowledges that, while on balance, a review mechanism is not appropriate for the current round of the New gTLD Program, it is recommended that the development of rules and processes for future rounds of the New gTLD Program (to be developed through the multi-stakeholder process) should explore whether a there is a need for a formal review process with respect to Expert Determinations.

      2. The NGPC considered its role and purpose to provide general oversight of the New gTLD Program. One component of the NGPC's responsibilities in providing general oversight of the New gTLD Program is "[r]esolving issues relating to the approval of applications and the delegation of gTLDs pursuant to the New gTLD Program for the current round of the Program." (See NGPC Charter, Section II.D). Additionally, the Applicant Guidebook (Section 5.1) provides that:

        ICANN's Board of Directors has ultimate responsibility for the New gTLD Program. The Board reserves the right to individually consider an application for a new gTLD to determine whether approval would be in the best interest of the Internet community. Under exceptional circumstances, the Board may individually consider a gTLD application. For example, the Board might individually consider an application as a result of GAC Advice on New gTLDs or of the use of an ICANN accountability mechanism.

        Addressing the perceived inconsistent and unreasonable String Confusion Objection Expert Determinations is part of the discretionary authority granted to the NGPC in its Charter regarding "approval of applications" and "delegation of gTLDs", in addition to the authority reserved to the Board in the Guidebook to consider individual gTLD applications under exceptional circumstances. The NGPC considers that the identified SCO Expert Determinations present exceptional circumstances warranting action by the NGPC because each of the Expert Determinations falls outside normal standards of what is perceived to be reasonable and just. While some community members may identify other Expert Determinations as inconsistent or unreasonable, the SCO Expert Determinations identified are the only ones that the NGPC has deemed appropriate for further review. The NGPC notes, however, that it also identified the String Confusion Objection Expert Determinations for .CAR/.CARS as not in the best interest of the New gTLD Program and the Internet community. Nonetheless, because the parties in the .CAR/.CARS contention set recently have resolved their contending applications, the NGPC is not taking action to send these SCO Expert Determinations back to the ICDR for re-evaluation to render a Final Expert Determination.

      3. The NGPC also considered whether there was a reasonable basis for certain perceived inconsistent Expert Determinations to exist, and particularly why the identified Expert Determinations should be sent back to the ICDR while other Expert Determinations should not. The NGPC notes that while on their face some of the Expert Determinations may appear inconsistent, including other SCO Expert Determinations, and Expert Determinations of the Limited Public Interest and Community Objection processes, there are reasonable explanations for these seeming discrepancies, both procedurally and substantively.

        First, on a procedural level, each expert panel generally rests its Expert Determination on materials presented to it by the parties to that particular objection, and the objector bears the burden of proof. Two panels confronting identical issues could – and if appropriate should – reach different determinations, based on the strength of the materials presented.

        Second, on a substantive level, certain Expert Determinations highlighted by the community that purportedly resulted in "inconsistent" or "unreasonable" results, presented nuanced distinctions relevant to the particular objection. These nuances should not be ignored simply because a party to the dispute disagrees with the end result. Further, the standard guiding the expert panels involves some degree of subjectivity, and thus independent expert panels would not be expected to reach the same conclusions on every occasion. However, for the identified Expert Determinations, a reasonable explanation for the seeming discrepancies is not as apparent, even taking into account all of the previous explanations about why reasonably "discrepancies" may exist. To allow these Expert Determinations to stand would not be in the best interests of the Internet community.

      4. The NGPC considered whether it was appropriate, as suggested by some commenters, to expand the scope of the proposed review mechanism to include other Expert Determinations, such as some resulting from Community and Limited Public Objections, as well as other String Confusion Objection Expert Determinations, and possibly singular and plural versions of the same string. The NGPC determined that to promote the goals of predictability and fairness, establishing a review mechanism more broadly may be more appropriate as part of future community discussions about subsequent rounds of the New gTLD Program. Applicants have already taken action in reliance on many of the Expert Determinations, including signing Registry Agreements, transitioning to delegation, withdrawing their applications, and requesting refunds. Allowing these actions to be undone now would not only delay consideration of all applications, but would raise issues of unfairness for those that have already acted in reliance on the Applicant Guidebook.

        It should also be noted that in response to advice from the Governmental Advisory Committee (GAC), the NGPC previously considered the question of whether consumer confusion may result from allowing singular and plural versions of the same strings. On 25 June 2013, the NGPC adopted a resolution resolving "that no changes [were] 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" http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.d. The NGPC again notes that the topic of singular and plural versions of the same string also may be the subject of further community discussion as it relates to future rounds of the New gTLD Program.

      5. The NGPC considered community correspondence on this issue in addition to comments from the community expressed at the ICANN meetings. The concerns raised in the ICANN meetings and in correspondence have been factored into the deliberations on this matter.

      The NGPC previously delayed its consideration of BGC Recommendations on Reconsideration Requests 13-9 and 13-10 pending the completion of the NGPC's review of the issues discussed above. Now that the NGPC has taken action as noted above, it will resume its consideration of the BGC Recommendations on Reconsideration Requests 13-9 and 13-10 as soon as feasible.

      There will be direct fiscal impacts on ICANN associated with the adoption of this resolution since certain proceedings will be sent back to the ICDR for re-review by a three-member expert panel. Approval of the resolution will not impact security, stability or resiliency issues relating to the domain name system.

      Taking this action is an Organizational Administrative Action that was the subject of public comment. The summary of public comments is available for review here: (https://www.icann.org/en/system/files/files/report-comments-sco-framework-principles-24apr14-en.pdf [PDF, 165 KB]).

    3. Reconsideration Request 14-37, I-Registry Ltd.

      Whereas, iRegistry Ltd. ("Requester") filed Reconsideration Request 14-37 asking the New gTLD Program Committee ("NGPC") to reverse Resolutions 2014.07.30.NG01 – 2014.07.30.NG04 (the "Resolution") "or at least amend[]" the Resolution, and to then put the decision as to how to address name collisions "on hold" until the issues the Requester raises have "been solved."

      Whereas, the BGC considered the issues raised in Reconsideration Request 14-37.

      Whereas, the BGC recommended that the Request be denied because the Requester has not stated proper grounds for reconsideration and the NGPC agrees.

      Resolved (2014.10.12.NG04), the NGPC adopts the BGC Recommendation on Reconsideration Request 14-37, which can be found at https://www.icann.org/en/system/files/files/recommendation-i-registry-04sep14-en.pdf [PDF, 150 KB].

      Rationale for Resolution 2014.10.12.NG04

      1. Brief Summary

        iRegistry Ltd. ("Requester") is a domain name registry that disputes the NGPC's adoption of the Name Collision Occurrence Management Framework (the "Framework").

        After conducting several independent studies regarding the name collision issue, ICANN implemented a public comment period from 26 February 2014 through 21 April 2014 where the community provided feedback on possible solutions to the name collision issue, including the issue of implementing a framework to manage and mitigate name collisions. ICANN received 28 comments, none of which were from the Requester.2

        After considering the public comments received, the detailed studies analyzing the issue, and advice from the relevant ICANN advisory committee, the NGPC approved Resolutions 2014.07.30.NG01 – 2014.07.30.NG04 (the "Resolution")3 on 30 July 2014, adopting the Framework. The Framework sets forth procedures that registries must follow to prevent name collisions from compromising the security or stability of the Internet.

        The Requester filed the instant Request (Request 14-37), arguing that the NGPC failed to sufficiently involve the public in its decision to adopt the Framework and contending that the Framework will lead to confusion amongst registrants, a lower volume of registrations, and thus adversely impact the Requester financially. The Board Governance Committee (BGC) considered Request 14-37 and concluded that: (i) there is no evidence that the NGPC's actions in adopting the Resolution support reconsideration; (ii) the Requester has not demonstrated that the NGPC failed to consider any material information in passing the Resolution or that the NGPC relied on false or inaccurate material information in passing the Resolution; and (iii) the Requester has not demonstrated that it has been materially and adversely affected by the Resolution. Therefore, the BGC recommended that Reconsideration Request 14-37 be denied (and the entirety of the BGC Recommendation is incorporated by reference as though fully set forth in this rationale). The NGPC agrees.

      2. Summary of Relevant Background Facts

        In furtherance of ICANN's core values aimed at "[p]reserving and enhancing the operational stability, reliability, security, and global interoperability of the Internet" (Bylaws, Art. 1, § 2.1), ICANN's Security and Stability Advisory Committee ("SSAC") published SAC057: SSAC Advisory on Internal Name Certificates on 15 March 2013.4 The report identified a Certificate Authority ("CA") practice that, if widely exploited, could pose risks to the privacy and integrity of secure Internet communications (name collisions). The SSAC advised ICANN to take immediate steps to mitigate the risks. The issues identified in SAC057 are part of the more general category of name collision issues. Accordingly, on 18 May 2013, the ICANN Board approved a resolution commissioning a study in response to the SSAC's advice in SAC057.5

        On 5 August 2013, ICANN released the study, prepared by Interisle Consulting Group, of the likelihood and potential consequences of collision between new public gTLD labels and existing private uses of the same strings.6

        On 7 October 2013, ICANN introduced the New gTLD Collision Occurrence Management Plan (the "Plan"), which permitted the use of an alternate path to delegation.7 As part of the Resolution adopting the Plan, the NGPC recommended that the ICANN Board "direct the ICANN President and CEO to develop a long term plan to manage name collision risks related to the delegation of new TLDs, and to work with the community to develop a long-term plan to retain and measure root-server data."8

        In November 2013, ICANN engaged JAS Global Advisors LLC ("JAS") to lead the development of the Framework, in cooperation with the community.9

        From 26 February 2014 through 21 April 2014, ICANN implemented a public comment period where the community provided feedback on possible solutions to the name collision issue, including the issue of implementing a framework to manage and mitigate name collisions; ICANN received 28 comments, none of which were from the Requester10 The Requester did not participate in the public comment forum. After collection of the public comments, JAS released the final version of its Phase One Report on Mitigating the Risk of DNS Namespace Collisions.11

        On 6 June 2014, SSAC published SAC066: SSAC Comment Concerning JAS Phase One Report on Mitigating the Risk of DNS Namespace Collisions, in which it offered advice and recommendations to the Board on the framework presented in the JAS Study and Name Collision Framework.12

        On 27 July 2014, the Requester sent a letter to ICANN: (i) asking ICANN to "thoroughly evaluate" a proposal for addressing the problem of name collisions; and (ii) providing five specific proposals as to the how the issue should be addressed. (Request, Ex. D.) ICANN acknowledged receipt of the Requester's letter on 29 July 2014. (Request, Ex. E.)

        On 30 July 2014, the NGPC approved Resolutions 2014.07.30.NG01 – 2014.07.30.NG04 (the "Resolution"), which adopted the Framework. The Framework sets forth procedures that registries must follow to prevent name collisions from compromising the security or stability of the Internet and directs the "President and CEO, or his designee(s), to take the necessary actions to implement" the Framework.13

        On 4 August 2014, ICANN's Global Domains Division issued each new gTLD registry operator a Name Collision Occurrence Assessment ("Assessment"), which identified which measures registries must take to avoid name collision issues, in accordance with the Framework.14 On that same date, the Requester received the Assessment via email. (Request, Ex. A.)

        On 12 August 2014, ICANN presented a webinar providing an overview of the Framework specifically geared towards registry operators.15

        On 13 August 2014, the Requester filed the instant Request, seeking reconsideration of the NGPC's Resolution.

        While how to treat one category of names affected by the name collision issue is not yet part of the Framework, ICANN is in the process of gathering public input on this topic. Specifically, ICANN has opened a public comment forum on this particular issue, which will run from 25 August 2014 through 7 October 2014.16

        On 4 September 2014, the Board Governance Committee ("BGC") issued its Recommendation regarding Reconsideration Request 14-37.17 On 11 September 2014, the Requester filed a Clarification to Reconsideration Request 14-37,18 containing further alleged details regarding how the Requester has been materially affected by the Resolution and the adoption of the Framework.

      3. Issues

        The issues for reconsideration are whether the NGPC:

        1. Failed to consider material input from the community in approving the Resolution (Request, § 8, Pg. 11); and
        2. Improperly underestimated the Resolution's potential negative consequences. (Id., § 8, Pgs. 7-8.).
      4. The Relevant Standards for Evaluating Reconsideration Requests

        ICANN's Bylaws call for the BGC to evaluate and, for challenged Board (or NGPC) action, make recommendations to the Board (or NGPC) with respect to Reconsideration Requests. See Article IV, Section 2 of the Bylaws. The NGPC, bestowed with the powers of the Board in this instance, has reviewed and thoroughly considered the BGC Recommendation on Request 14-37 and finds the analysis sound.19

      5. Analysis and Rationale

        The Requester has not demonstrated that the Board failed to consider material information or relied on false or inaccurate material information in passing the Resolutions; therefore, reconsideration is not appropriate.

        1. The Request Warrants Summary Dismissal.

          The BGC concluded, and the NGPC agrees, that the Requester does not have standing because the Requester "had notice and opportunity to, but did not, participate in the public comment period relating to the contested action[.]" (Bylaws, Art. IV, § 2.9.). Specifically, ICANN's Bylaws permit the BGC to summarily dismiss a request for reconsideration if "the requestor had notice and opportunity to, but did not, participate in the public comment period relating to the contested action[.]" (Bylaws, Art. IV, § 2.9.)

          From 26 February 2014 through 21 April 2014, ICANN implemented a public comment period, which was announced on ICANN's website, and where the community provided feedback on possible solutions, including a framework, to name collision issues20 The forum generated 28 comments, but the Requester did not participate in the public comment forum, and has offered no justification, excuse or explanation for its decision to refrain from doing so. The only communication it claims to have had with ICANN regarding name collisions is a letter dated 27 July 2014, which was well after the public comment period had closed.21 Given that the public comment period here is indisputably related to the Resolution, summary dismissal is warranted on the basis of the Requester's non-participation. However, in the interest of completeness, the NGPC will nonetheless address the merits of the Request.

        2. The NGPC Considered All Material Information.

          The BGC concluded, and the NGPC agrees, that the Requester has not demonstrated that the NGPC failed to consider material relevant information.

          In order to state a basis for reconsideration of a Board action, the Requester must demonstrate that the Board (or in this case the NGPC) failed to consider material information or considered false or inaccurate material information in adopting the Resolution. (Bylaws, Art. IV, § 2.2.) The Requester does not argue that the NGPC considered false or inaccurate material information, but it does claim that the NGPC failed to consider material information in two ways. First, the Requester claims that the NGPC did not sufficiently consult with the public prior to adopting the Resolution. Second, the Requester claims that the NGPC failed to consider how the Resolution will have material adverse effects on registries and internet users. Neither argument withstands scrutiny, and neither is grounds for reconsideration.

          1. The NGPC Considered Public Comments Solicited During A Lengthy Public Comment Period.

            The Requester claims that the NGPC "failed to take material input from the community into account." (Request, § 8, Pg. 11.) Contrary to the Requester's claims, the NGPC did consider feedback received in "the public comment forum"22 that was open from 26 February 2014 through 21 April 2014. The Requester does not explain why it failed to participate in that forum. Had it participated, its views would have been included along with the 28 detailed comments considered that were submitted by various stakeholders and members of the public, including other registries.23 Notably, the public comment period for this matter was actually longer than required. Typically, public comment periods are open 21 days, and if comments are received during that time, there is a 21-day reply period.24 Here, the public comment period was open for 33 days, with a 21-day reply period. In addition, ICANN facilitated an entire public session about the name collision issue at the London ICANN meeting on 23 June 2014 that provided yet another opportunity for public commentary and participation; the Requester again chose not to participate.25 As such, the Requester cannot reasonably claim that the NGPC did not consider public input before adopting the Resolution.

            In sum, the Requester does not persuasively argue that the NGPC failed to consider material information in the form of public comments in adopting the Resolution, and therefore has not stated proper grounds for reconsideration on that basis. (Bylaws, Art. IV, § 2.2.)

          2. The NGPC Considered All Material Information Relevant To The Resolution.

            The Requester seeks reconsideration of the Resolution because it claims the NGPC "did not properly assess the implications of the decision." (Request, § 8, Pg. 12.) The Requester's main basis for this assertion is that the issues raised in its own 27 July 2014 letter were not expressly addressed in the "Rationale" section of the Resolution. This argument fails to provide a basis for reconsideration for two reasons.

            First, the Resolution does take into account the substance of the information provided in the Requester's 27 July 2014 letter. The 27 July 2014 letter made five requests, all related to either the "RPM rules" or the Requester's view that one common set of rules should apply to all gTLDs. (Request, § 8, Pg. 10 & Ex. D.) Despite Requester's claims to the contrary, the same issues raised in the 27 July 2014 letter were all presented to the NGPC during the public comment period by other stakeholders and were addressed by the NGPC. The Resolution acknowledges that the NGPC considered the public comments that: (i) expressed concern regarding the "interaction between the name collision block lists and intellectual property rights protection mechanisms"26; (ii) referenced how the "name collision issue is creating an uneven competitive landscape"; and (iii) discussed the pros and cons of treating new gTLD operators differently from legacy operators.27 Furthermore, ICANN has already determined that the RPM issue requires further public comment before a decision can be made as to how to handle the issue. In fact, ICANN is currently soliciting comments, between 25 August 2014 and 7 October 2014, on the approach that should be taken "regarding the appropriate Rights Protection Mechanisms for release of SLD Block List names."28 In other words, the NGPC was not lacking any material information on the applicable issues, regardless of whether it specifically considered the Requester's 27 July 2014 letter.

            Second, the Requester's disagreement with the substance of the Framework does not form the proper basis for reconsideration. The NGPC considered independent, detailed studies discussing the name collision issue, including one prepared by JAS and one prepared by Interisle Consulting Group.29 Further, the NGPC took into account advice from the SSAC before adopting the Resolution. The SSAC's role is to "advise the ICANN community and Board on matters relating to the security and integrity of the Internet's naming and address allocation systems." (Bylaws, Art. XI, § 2.a.) In sum, the NGPC considered public comments, independent analytical reports, and advice from the relevant ICANN advisory committee. While the Requester complains that the NGPC "did not mention the letter" (that the Requester sent months after the public comment period had closed) and as such "did not properly address the implications of the decision" to approve the Framework, those allegations do not amount to a claim that the NGPC failed to consider any material information. As such, no reconsideration is warranted.

            As a final note, the Requester also claims reconsideration is warranted because "[t]here is no indication that the GAC30 has been given the opportunity to provide feedback" to the JAS reports or the SSAC advice. (Request, § 7, Pg. 7) The GAC provides "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." (Bylaws, Art. XI, § 2.1.) That the GAC did not issue any formal advice related to how ICANN should address name collisions does not mean the NGPC failed to consider any material information. Had the GAC issued such advice, the ICANN Board would have considered it, as is required under ICANN's Bylaws. (Bylaws, Art. XI, §§ 2.1.i, 2.1.j.) Further, in July 2013, the GAC Durban Communiqué did advise that the Board "[a]s a matter of urgency consider the recommendations contained in the SSAC Report on Dotless Domains (SAC053) and Internal Name Certificates (SAC057)," and the latter involved name collision issues.31 The Board did consider the SSAC's advice, and in turn, adopted the Framework.

            Again, as the Requester does not show that the NGPC failed to consider material information in adopting the Resolution, reconsideration is not appropriate. (Bylaws, Art. IV, § 2.2.)

        3. Alleged Confusion is not a Basis for Reconsideration.

          The BGC concluded, and the NGPC agrees, that the Requester has not demonstrated that the NGPC failed to consider material relevant information concerning the importance of educating the public about the Framework.

          The Requester complains that the NGPC failed to consider the supposed fact that the "overall majority" of registrants are not aware of the name collision problem and will therefore be "confus[ed] about the availability of domain names in general." (Request, § 7, Pg. 6.) However, it is evident that the NGPC did consider information concerning the importance of educating the public about the Framework. The Resolution dedicates an entire provision (section B.6) to "Informational Materials" and requires ICANN to "produce informational materials as needed . . . . [and] work to make this information available to parties potentially affected by name collision."32 Even though the Framework was just recently adopted, ICANN has already posted and provided a wide variety of informational materials, including webinars geared towards registry operators, handbooks and videos for IT professionals, and a "Frequently Asked Questions" page regarding the Framework.33 Moreover, ICANN has dedicated resources towards ensuring questions about the Assessment or the Framework will be answered promptly and accurately. In other words, far from failing to consider the potential for confusion regarding the Resolution, ICANN has taken proactive and significant steps to ensure that affected parties comprehend the Framework and the steps it requires.34 No reconsideration is warranted on the grounds that the NGPC did not consider information regarding public outreach, as it is clear that the NGPC did consider such information and acted on it by way of the aforementioned educational resources.

        4. The Requester Has Not Demonstrated It Has Been Materially Affected By The Resolution.

          The BGC concluded, and the NGPC agrees, that the Requester has not demonstrated that it has been materially and adversely affect by the Resolution.

          Absent evidence that the Requester has been materially and adversely affected by the Resolution, reconsideration is not appropriate. (Bylaws, Art. IV, §§ 2.1-2.2.) Here, the Requester argues it is materially affected by the Resolution for two reasons. (Request, § 6, Pgs. 4-5.) First, it contends that the Framework does not provide clear guidance as to how to prevent harms related to name collisions. (Id., Pg. 5.) Second, the Requester contends that it will suffer "lower registration rates" due to the confusion the Framework will purportedly cause, because the Requester predicts that registrars will "not offer domain name registrations from the Name Collision lists." (Id.) Neither of these concerns has yet come to fruition, however, and both are merely speculative at this point. 35 Again, only those persons who "have been adversely affected by" an ICANN action may file a request for reconsideration. (Bylaws, Art. IV, § 2.2) (emphasis added). Because the only harm the Requester identifies is, at this point, merely speculative and hypothetical, the request for reconsideration is premature.36

          As such, the Requester has failed to demonstrate it has been materially affected by the Resolution and, on that independent basis, reconsideration of the adoption of the Resolution is not warranted.

      6. Decision

        The NGPC had the opportunity to consider all of the materials submitted by or on behalf of the Requester or that otherwise relate to Request 14-37. Following consideration of all relevant information provided, the NGPC reviewed and has adopted the BGC's Recommendation on Request 14-37 https://www.icann.org/en/system/files/files/recommendation-i-registry-04sep14-en.pdf [PDF, 150 KB], which shall be deemed a part of this Rationale and is attached to the Reference Materials to the NGPC Submission on this matter.

        Adopting the BGC's recommendation has no direct 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.

    4. GAC Advice regarding Protections for the Red Cross and Red Crescent – Singapore Communiqué

      Whereas, the GAC met during the ICANN 49 meeting in Singapore and issued a Communiqué [PDF., 449 KB] on 27 March 2014 ("Singapore Communiqué").

      Whereas, in the Singapore Communiqué the GAC clarified its previous advice to the ICANN Board to permanently protect from unauthorized use the terms associated with the International Red Cross and Red Crescent Movement, and advised that the protections should also include "the 189 National Red Cross and Red Crescent Societies, in English and the official languages of their respective states of origin," and the "full names of the International Committee of the Red Cross and International Federation of the Red Cross and Red Crescent Societies in the six (6) United Nations Languages." The GAC Advice is identified in the GAC Register of Advice as 2014-03-27-RCRC.

      Whereas, the GNSO has developed policy recommendations to the Board concerning the Red Cross and Red Crescent names that are the subject of the GAC's Singapore Communiqué. The scope of protections in the GNSO policy recommendations differ from the GAC's advice, and the GAC, GNSO, Board, and ICANN community continue to actively work on resolving the differences.

      Whereas, the NGPC is responsible for considering the GAC advice 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 (2014.10.12.NG05), the President and CEO, or his designee(s), is directed to provide temporary protections for the names of the International Committee of the Red Cross and International Federation of the Red Cross and Red Crescent Societies, and the 189 National Red Cross and Red Crescent Societies, as identified in the GAC Register of Advice as 2014-03-27-RCRC while the GAC, GNSO, Board, and ICANN community continue to actively work on resolving the differences in the advice from the GAC and the GNSO policy recommendations on the scope of protections for the RCRC names.

      Rationale for Resolution 2014.10.12.NG05

      The NGPC is taking action to provide temporary protections for Red Cross/Red Crescent (RCRC) names identified in the GAC's advice in the Singapore Communiqué, while being mindful of the outstanding discussions among the GAC, GNSO, Board, and ICANN community to actively work on resolving the differences in the GAC advice and the GNSO policy recommendations on the scope of protections for the RCRC names.

      Article XI, Section 2.1 of the ICANN Bylaws permits 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 Singapore Communiqué dated 27 March 2014 ("Singapore Communiqué"). 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 the Singapore Communiqué, the GAC clarified its previous advice to the ICANN Board to permanently protect from unauthorized used the terms associated with the International Red Cross and Red Crescent Movement, and advised that the protections should also include "the 189 National Red Cross and Red Crescent Societies, in English and the official languages of their respective states of origin," and the "full names of the International Committee of the Red Cross and International Federation of the Red Cross and Red Crescent Societies in the six (6) United Nations Languages".

      The GNSO has also provided policy recommendations to the ICANN Board on the same RCRC names that are the subject of the GAC's advice in the Singapore Communiqué. Unlike the GAC's advice, the GNSO policy recommendations do not call for permanent protections for the set of RCRC names. Instead, the GNSO policy recommends that these names be protected by entering them into the TMCH for 90-days claims notification.

      On 30 April 2014, the ICANN Board adopted the GNSO Council's policy recommendations on IGO-INGO protections that were not inconsistent with the GAC's advice, and requested additional time to consider the remaining policy recommendations that are inconsistent with the GAC's advice on the same topic. The Board committed to facilitate discussions among the relevant parties to reconcile any remaining differences between the policy recommendations and the GAC advice on the topic, and previously tasked the NGPC to help with this process. The NGPC action today is to provide temporary protections for the RCRC names identified in the GAC's advice in the Singapore Communiqué, while being mindful of the outstanding discussions among the GAC, GNSO, Board, and ICANN community to actively work on resolving the differences in the advice from the GAC and the GNSO policy recommendations on the scope of protections for the RCRC names.

      The NGPC's action will have a positive impact on the community as it will allow for temporary protections for RCRC names, while allowing for discussions to continue. As part of its deliberations, the NGPC reviewed the following significant materials and documents:

      There are no foreseen fiscal impacts associated with the adoption of this resolution. Approval of the proposed resolution will not impact security, stability or resiliency issues relating to the DNS. This action is not a defined policy process within ICANN's Supporting Organizations or ICANN's Organizational Administrative Function decision requiring public comment or not requiring public comment. Subsequent actions related to protections for RCRC names may be subject to public comment.

    5. Any Other Business

      No resolution taken.

Published on 14 October 2014


1 Japanese translation of "online shopping"

2 See Report of Public Comments, available at https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 229 KB].

3 See Resolution, available at https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-07-30-en.

4 See https://www.icann.org/en/system/files/files/sac-057-en.pdf [PDF,1.13 MB].

5 See https://features.icann.org/ssac-advisory-internal-name-certificates.

6 See Addressing the Consequences of Name Collisions, available at https://www.icann.org/news/announcement-3-2013-08-05-en.

7 See New gTLD Collision Occurrence Management Plan Frequently Asked Questions, available at https://www.icann.org/news/announcement-2013-12-03-en.

8 See https://www.icann.org/resources/board-material/resolutions-new-gtld-2013-10-07-en#1.a.

9 See https://www.icann.org/resources/pages/name-collision-2013-12-06-en.

10 See Report of Public Comments, available at https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 229 KB].

11 See JAS Report, available at https://www.icann.org/en/system/files/files/name-collision-mitigation-study-06jun14-en.pdf [PDF, 391 KB].

12 See https://www.icann.org/en/system/files/files/sac-066-en.pdf [PDF, 305 KB].

13 See Resolution, available at https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-07-30-en.

14 See Name Collision Occurrence Assessment, available at http://newgtlds.icann.org/sites/default/files/agreements/name-collision-assessment-04aug14-en.pdf [PDF, 91 KB].

15 See https://www.icann.org/resources/pages/name-collision-2013-12-06-en.

16 See Implementing Rights Protection Mechanisms in the Name Collision Mitigation Framework, available at https://www.icann.org/public-comments/name-collision-rpm-2014-08-25-en.

17 https://www.icann.org/en/system/files/files/recommendation-i-registry-04sep14-en.pdf [PDF, 150 KB]

18 https://www.icann.org/en/system/files/files/clarification-i-registry-11sep14-en.pdf [PDF, 59 KB]

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

20 See Report of Public Comments, available at https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 229 KB].

21 The Requester states that it sent a letter to the NGPC "well in advance" of the NGPC meeting, but that statement is wrong given the mere three days between the date of the letter and the 30 July 2014 NGPC meeting. (See Request, § 8, Pg. 9.)

22 See Resolution, available at https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf [PDF, 634 KB].

23 See Report of Public Comments, available at https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 229 KB].

24 See https://www.icann.org/resources/pages/how-2014-03-17-en

25 See Name Collision Presentation, London: ICANN 50, available at https://london50.icann.org/en/schedule/mon-name-collision/presentation-name-collision-23jun14-en.

26 See Resolution, available at https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf [PDF, 634 KB].

27 See Report of Public Comments, at Pg. 11, available at https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 229 KB].

28 See Implementing Rights Protection Mechanisms in the Name Collision Mitigation Framework, available at https://www.icann.org/public-comments/name-collision-rpm-2014-08-25-en

29 See Resolution, available at https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-07-30-en.

30 Governmental Advisory Committee.

31 See GAC Communiqué Issued at ICANN 47, available at https://www.icann.org/news/announcement-2013-07-18-en; SAC057, available at https://www.icann.org/en/system/files/files/sac-057-en.pdf [PDF, 1.13 KB].

32 See Resolution, available at https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf [PDF, 634 KB].

33 See Name Collision Resources & Information, available at https://www.icann.org/resources/pages/name-collision-2013-12-06-en.

34 ICANN has also engaged in significant outreach activities on LinkedIn and via various media outlets, as well as launching a Google Adwords promotion.

35 In fact, the Framework will permit names to be activated in the DNS now that were previously not allowed to be activated. As such, the Framework may well lead to an increase in registrations.

36 On 11 September 2014, after the BGC issued its Recommendation, the Requester filed a Clarification to Reconsideration Request 14-37, purportedly providing additional details regarding ways in which the Requester has been materially and adversely affected by the Resolution. Despite its claims to the contrary, the Requester's continued allegations of potential harm are still speculative and hypothetical.

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