Reconsideration Request 14-37, I-Registry Ltd.

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

The issues for reconsideration are whether the NGPC:
Failed to consider material input from the community in approving the Resolution (Request, § 8, Pg. 11); and
Improperly underestimated the Resolution's potential negative consequences. (Id., § 8, Pgs. 7-8.).
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
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.
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.
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.
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.)
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.)
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.
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.
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-04... [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.