|
||
|
||
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.
Basket One
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.
Basket Two
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.
Basket Three
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.2.2.1.3.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.
GAC Veto
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.
Bylaw Rewrite
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.
Sponsored byIPv4.Global
Sponsored byRadix
Sponsored byVerisign
Sponsored byCSC
Sponsored byVerisign
Sponsored byDNIB.com
Sponsored byWhoisXML API
A World-Renowned Source for Internet Developments. Serving Since 2002.
And what will the other critics say?
A thoughtful article Michael. Some comments:
We (.nz) argued for a change in the SOW to remove the requirement for IANA to determine “how the proposed string has reached consensus support ...” because we did not want to see two separate policy processes taking place, one at ICANN followed by one at the IANA functions operator, where the former had multi-stakeholder input and the latter did not. Once the ICANN policy process has been followed then that should be the final decision and an instruction given to the registry (the IANA functions operator). The only role for the IANA functions operator is to assure itself that the ICANN process was followed and that the instruction is legitimate. This clear separation of duties prevents an ICANN board from going off-piste, as they have done in numerous ccTLD redelegations, and sets out a framework that allows the IANA functions operator to be independent from ICANN. Ideally that would be a third party but a subsidiary of ICANN would have sufficient structural separation to ensure independence.
Your point about ‘global public interest’ is interesting because it all depends on how ICANN plays it. It would be sensible for any delegation instruction to IANA to include a statement of conformance from ICANN that says something like “this delegation has been agreed through a multi-stakeholder process that provided for input from all relevant stakeholder and has ensured that this is in the global public interest”. The point being that they need to establish at the outset that the definition of ‘global public interest’ is a multi-stakeholder definition that they are the arbiters of and the GAC is only one voice in this. This is basically what they had to say to approve the Applicant Guidebook so I hope it would be the natural next step. Even with the requirement for each delegation to have this asserted, ICANN should be sensible enough to stick to a similar answer for all new gTLDs.
Michael, nice try. You did the best you could. But the argument falls apart.
First, the new IANA contract clearly and unambiguously moves away from the idea that each TLD string has to meet a public interest standard in addition to meeting the ICANN guidebook policies. It is ICANN’s policies, not any specific application or implementation of it, that is judged by that standard. Here is the relevant language:
FNOI Language
For delegation requests for new generic TLDS (gTLDs), the Contractor
shall include documentation to demonstrate how the proposed string
has received consensus support from relevant stakeholders and is supported
by the global public interest.
Current IANA RFP
In making a delegation or redelegation recommendation, 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.
What is it that must be “demonstrated” to have support? This direct comparison makes it clear that the object of the requirement has shifted in a significant way. In the FNOI, the object of the requirement is “the proposed string;” in the final IANA RFP, it is ICANN’s “policy framework” or “policy process.” So, what ICANN must do now when requesting a new delegation or changing an old one is simply demonstrate that its process “provided the opportunity for input from relevant stakeholders and was supportive of the global public interest.” It could bundle 37 new TLD requests into one request, if all the applications went go through essentially the same process, and demonstrate how the process met the criterion. It is no longer the “proposed string” that must be “in the global public interest.”
And “consensus support” for a string - which I and many others argued constituted a heckler’s veto that would make any and every application hostage to opposition from competitors or any ornery opponent for any reason - is completely gone. As it should be.
This does give the IANA a kind of veto power over a process. But given a choice of evils, this is much, much better. USG (and/or the hordes of interest groups lobbying it) cannot refuse to make a delegation simply because they don’t like an applicant, or the content of a proposed string, or the anticipated content of the websites that might live under a string. If they veto a delegation, they will have to veto any and all applications produced by the same process and policy. And it is conceivable that ICANN’s byzantine and sometimes bizarre processes might produce a policy framework or process that was not open to relevant stakeholders and not in the global public interest. Although, as I argued in my IGP blog, the idea of NTIA setting itself up as unilateral judge of what is in the GLOBAL public interest is troubling.
Second, your article makes an astounding equivocation, substituting GAC’s privileged ability to weigh in on “public policy issues” with an authoritative determination as to what is in the “global public interest.” Those two things are not the same. Obviously. The GACeroos can deem something to raise a “public policy issue,” although the criteria for doing so are rather arbitrary. But all it means is that their advice must be dealt with in a certain way. But such a designation does not say anything at all about whether a specific delegation (or process) is “in the global public interest.”
I know that there are a few governments who want to be able to veto any individual application. I know that they would love to stretch and twist whatever language is on the table to achieve that goal. And I know there are people out there who, for various reasons, are willing to encourage those fantasies. But wishing doesn’t make it so.
The simple fact is that the IANA contract says nothing whatsoever about “public policy issues”, and thus does not invoke the GAC’s advisory role in any way. With this IANA contract, GAC is in no stronger position to veto TLD requests than before. And even if it was, the IANA RFP, as noted above, does not ask for a determination whether an individual string or applicant is in the global public interest, it asks whether ICANN’s policy framework is.
Dang, I wish _I_ got paid for this stuff….
Milton,
If you find some one that pays for this stuff let me know.
I respect your opinion, and will not belittle it or you by callings your opinion slanted or invalid.
I am often reminded of the saying that there are three sides to every story, his side, her side and the truth. In this case their is my side, your side and the government’s side.
While we can constructively engage in trying to interpret what these words mean, it is really going to be up to the governments to define them for us. There is no mechanism to prevent the GAC from providing advice on global public policy, and if you want to hear their opinion on global public advice sooner as opposed to later keep yelling from the roof tops that they are not the appropriate body to provide global public policy advice.
As I noted in my original article, while I find merit in your opinion based upon the standard ICANN/IANA used back in 2000, if you look at the quality and depth of the IANA reports in connection with recent new gTLDs .CAT, .ASIA, .XXX. you will see that the operational trend supports my interpretation.
Just to be clear, I do not view the GAC veto being able to be wielded by a couple of rouge governments. I actually have the trust that those governments that have invested serious resources in defending the private sector lead model in ICANN and in other international fora will only use that nuclear weapon when necessary for the greater good.
So instead of arguing over who is right or who is wrong, lets focus our efforts jointly on preventing the GAC from reaching for that nuclear button, because the next time they do it is game over for ICANN.