In connection with the recent publication of the IANA RFP, there have been some commenters that have proclaimed that removing the requirement of the Contractor to document the consensus of relevant stakeholders in connection with the delegation of new gTLDs from the original draft Statement of Work as a win for ICANN. However, when reading the recently revised IANA RFP language in light of the Government Advisory Committee (GAC) Dakar Communiqué, a rather compelling legal case can be made that when the IANA contract is awarded in March 2012 the net result will be a GAC veto power over gTLD delegations and re-delegations requests which, significantly, cannot be overridden under the ICANN bylaws.
Amended Guidelines on GAC Advise
Before dissecting the IANA RFP language, one needs to begin with a side by side comparison of GAC's advice provisions contained in the Dakar Communiqué versus those provisions currently contained in the Applicant Guidebook. This comparison identifies the three classifications ("baskets") of advice the GAC is proposing to provide in connection with new gTLD applications, each of which is discussed in detail below.
For those readers with an institutional knowledge of ICANN's new gTLD program, particularly the 2000 proof-of-concept round, the use of the word "basket" is an intended pun on the ICANN Board's shopping basket reference during the 2000 selection process.
The first basket is incredibly straightforward. When the GAC provides consensus advice that an application should not proceed, there is a strong presumption that the ICANN Board will not approve that application. If a new gTLD application falls into this basket, it is checkmate/game over for that applicant.
However, baskets two and three are where things get far more interesting as GAC advice on its face does not appear explicitly constrained to just consensus advice.
For this basket, the GAC has removed the text from the current Applicant Guidebook which states that this advice will not "create the presumption that the application should be denied" nor "require the Board to undertake the process for attempting to find a mutually acceptable solution with the GAC should the application be approved." Instead, the alternative language requires the ICANN Board "to enter into dialog with the GAC to understand the scope of concerns." This broader remit on its face is absent of any limitation of how such advice should be submitted by the GAC or received by the Board. The ability for this type of GAC advice to potentially block a new gTLD application becomes much clearer within the context of the IANA RFP language.
The third type of advice that the GAC can provide is in connection with applications that require remediation. The current guidebook appears to limit remediation to methods specified in the guidebook, and state the fact that material amendments to applications are generally prohibited, and that if no remediation method is available the application will not go forward and the applicant can re-apply in the second round. However, the proposed alternative text which the GAC has provided removes the apparent limitation on material amendments and the requirement that applicants re-apply in the second round. The proposed wording by GAC regarding this type of advice appears to leave open the option for future remediation methods to be added to Guidebook during the pendency of the application process. In fact this is exactly what happened in connection with the .ASIA and .CAT gTLD applications in the 2004 round to address GAC concerns.
Although most have feared GAC advice as serving as a higher bar to potential gTLD applications from being approved, this basket of advice on its face appears designed to allow remediation (and or material amendments) of applications that ICANN staff initially preferred to push toward the second round.
Those Who Fail to Learn From History Are Doomed to Repeat It
To properly interpret how GAC advice in connection with new gTLDs will be interpreted, it is constructive to revisit the GAC advice in connection with the ICM Registry application for the XXX domain name. Although there were some within the GAC that were seeking a consensus statement against the approval of the ICM Registry application (Basket 1), the GAC was only able to achieve consensus on the following advice:
Despite this clear advice expressing no support for the ICM Registry application, the ICANN Board decided to approve it absent any clear consensus advice from the GAC to reject it. This was a learning moment for the GAC and when coupling the Dakar communiqué with the current IANA RFP, one can see that the GAC now has the means to ensure that it its advice is never misinterpreted again.
Changes in the IANA Statement of Work (SOW)
When the USG issued the IANA Further Notice of Inquiry (FNOI) this past summer there was a proposed requirement in section C.220.127.116.11.2 pretaining to new gTLDs that would have required the contractor to document "how the proposed string has received consensus support from relevant stakeholders and is supported by the global public interest." However, the revised IANA RFP contained the following language;
the Contractor must provide documentation verifying that ICANN followed its own policy framework including specific documentation demonstrating how the process provided the opportunity for input from relevant stakeholders and was supportive of the global public interest.
While some people touted the removal of the language regarding documenting "consensus support from relevant stakeholders" as a win for ICANN, for the reasons set forth below this change in the language actually represents a coup for the USG and GAC.
Consensus is in the Eye of the Beholder
The problem with proving or disproving consensus is that it has different meanings to different communities. In the private sector consensus is broadly defined as general agreement (not unanimity) among a group of participants, which is different from consensus within an intergovernmental body. Per the GAC Dakar advice, "consensus is understood to mean the practice of adopting decisions by general agreement in the absence of any formal objection." Simply put, if a government is not happy and continues to make interventions on a issue, consensus cannot be achieved.
Public Sector Consensus versus Private Sector Consensus
Under the original IANA SOW the legal obligation was for the Contractor (ICANN) to "include documentation to demonstrate how the proposed string has received consensus support from relevant stakeholders and is supported by the global public interest." As noted above since consensus was never defined, there was a potential ambiguity in what definition of consensus should be applied. This ambiguity actually worked to ICANN's favor as it would have been able to document and provide a factual basis for its consensus finding. The burden of proof would have then fallen on the shoulders of the USG as the moving party to disprove consensus in order to reject the delegation of a new gTLD. In the ever increasing political internet governance debate, the USG did not want to have its finger prints on the smoking gun that killed a gTLD application.
In the published IANA RFP, the potential ambiguity of the consensus requirement has been removed. Instead, the legal requirement now imposed upon the Contractor (ICANN) in making "a delegation or redelegation recommendation" is to "provide documentation verifying that ICANN followed its own policy framework including specific documentation demonstrating how the process provided the opportunity for input from relevant stakeholders and was supportive of the global public interest." While some will argue that the removal of the specific text "the proposed string" from the draft SOW in the FNOI points to the Contractor only needing to document the "global public interest" with regard to the new gTLD program. However, that argument is difficult to reconcile with the actual words of the IANA RFP and current IANA practices.
The IANA RFP text requiring the Contractor to provide documentation appears in the sentence beginning with a reference to a delegation or redelegation recommendation. The current IANA practice is only to make new gTLD delegation request per each unique string; therefore it is reasonably to imply that that the documentation requirement is per each gTLD string request and not to the ICANN policy as a whole.
While this broader policy documentation requirement might have been consistent with the IANA standard operating procedures in 2000 when ICANN issued a single IANA report for both the .INFO and .BIZ gTLDs, the trend since then has been to provide increasing levels of factual detail in each new gTLD delegation request. By way of example, the .ASIA, .CAT and .XXX IANA delegation reports each document a detail list of actions taken to address GAC concerns that went above and beyond just a mere summary of the gTLD process.
Global Public Interest versus Public Policy
While the USG removed one potential ambiguity in defining consensus, the perhaps more difficult task of defining the "global public interest" remained. In fact US Senator John Rockefeller IV appears to be struggling with the same issue, as evidence by his recent correspondence to the Department of Commerce asking for clarification as to "what evaluation criteria a contractor should consider to determine whether a generic top level domain is supported by the global public interest." While there may be many potential opinions as to what is the authority body/standard to answer this question, it is respectfully submitted that within ICANN the GAC is the most authoritative body to speak on this issue. In addition to numerous citations in the ICANN bylaws regarding the role of the GAC in connection with public policy issues, the GAC provided a timely reminder to ICANN of the important role that it plays in its Dakar communiqué:
ICANN's Governmental Advisory Committee was formed 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. (emphasis added)
While there will be many within the ICANN community that will vehemently reject this potential interpretation of this IANA RFP provision, the only two entities that really matter are the USG and the GAC and how they define that phase.
To better understand how this new standard might be applied; consider a scenario where the GAC was to provide advice similar to the one that it provided in connection with ICM Registry application, e.g. "there is no active support within the GAC that [dot-example] is in the global public interest." It would appear on its face that it would be checkmate/game over that gTLD applicant. As it is hard to conceive how the ICANN Board would be able to document "global public interest" to supersede this GAC advice.
In connection with the ICM Registry decision, the ICANN Board was briefed of its legal obligations under the bylaws, and how it could disregard GAC advice. However, in the scenario outlined above this bylaw provision permitting the ICANN Board to disregard GAC advice does not exist, as the legal burden to document "global public policy" rests solely as a contractual obligation to the USG in the IANA contract.
Also lost on most commentators is the fact the USG and the GAC have potentially increased their scope of review in providing "global public policy." No longer is the burden imposed upon the Contractor (ICANN) solely in connection with new gTLD delegation requests, but now it also involves redelegation requests as well.
Which Came First the Chicken or the Egg
Over the course of the past year the USG had become quite adept at releasing major publications or statements in advance of major ICANN events. However, it was initially somewhat of a surprise that the only announcement released prior to the Dakar meeting was a Presolicitation Notice that the IANA RFP would be issued on or about 4 November 2011. However, it was not until 10 November 2011 that the IANA RFP was issued suggesting that there may have been some material changes made to the IANA RFP based upon the feedback from the ICANN Dakar meeting. In fact given the recent release of an amended IANA RFP on 17 November 2011, it appears that the USG is not done tweaking the IANA RFP to achieve its desired goal.
I have previously advocated amending the ICANN bylaws to put GAC advice on equal footing as a GNSO Supermajority vote. However, the GAC Dakar communiqué and the proposed IANA RFP appear on their face to have gone above and beyond a bylaw revision and superseded the ability of the ICANN Board to disregard GAC advice on global public policy in connection with gTLD delegation and redelegation issues. While many new gTLD applicants have expressed reservation about having to waive all types of legal rights against ICANN for the privilege of apply for a new gTLD, it appears that ICANN is getting a dose of its own medicine by the USG imposing a list of requirement that are rather take or leave it if ICANN wishes to remain the Contractor of the IANA functions. It seems that turn-around is fair play.
The GAC communicated to the ICANN Board in Dakar its concerns of providing early warning advice in connection with potential a substantially large number of new gTLD applications in such a short period of time, noting that ICANN had reserved itself the ability to batch applications in groups of five hundred. If the ICANN Board would like to prevent an initial GAC Early Warning communication noting genuine global public policy concerns involving a long laundry list of gTLD applications that have not been able to be fully resolved due to a short period of time, ICANN should be working on a way to address the valid concerns of the GAC expressed in Dakar.
Some critics will undoubtedly dismiss this article as placating to the GAC, or a last gasp attempt to interfere with the roll-out of the new gTLD process. Unfortunately these individuals are missing the much bigger picture of a fundamental paradigm shift within the power base of ICANN. During a recent presentation to a group of registration authorities in June I provided a presentation that included the following text: "[t]he GAC sleeping bear has been awoken; will it go back into hibernation or will it go on a feeding frenzy to bulk up." For anyone that may have missed Dakar just ask the registrars if they believe the GAC will be going back into hibernation anytime soon.
By Michael D. Palage, Intellectual Property Attorney and IT Consultant
|Data Center||Policy & Regulation|
|DNS Security||Regional Registries|
|Domain Names||Registry Services|
|Intellectual Property||Top-Level Domains|
|Internet of Things||Web|
|Internet Protocol||White Space|
Afilias - Mobile & Web Services
.eco launches globally at 16:00 UTC on April 25, 2017, when domains will be available on a first-come, first-serve basis. .eco is for businesses, non-profits and people committed to positive change for the planet. See list of registrars offering .eco more»