The myth of the ongoing gTLD round, often repeated as the reason for ICANN Corporate decisions, is: every thing ICANN Corporate does is  based on the ICANN Bottom Up Multistakeholder Process (BUMP).

Petitioners and appellants are often told that the Application Guide Book (AGB), and the program that ensued, was the product of this ICANN bottom up multistakeholder process. Unfortunately, this is not quite the case. As ICANN now discusses the possibility of power sharing between the ICANN Community and ICANN Corporate in the absence of US National Telecommunication and Information Administration (NTIA) oversight, the New gTLD program – as an example of ICANN’s bottom up multistakeholder process, provides the opportunity for a case study in the evolution of ICANN’s model. Additionally as ICANN starts to move toward possible subsequent gTLD rounds, the community will need to understand the conditions under which the round was run, so that the ICANN policy and implementation processes can be improved.

I do not argue against the value of the New gTLD program. I still believe that we are in the necessary process of creating opportunities for expressive and meaningful domain names that serve global registrants and users. Domain names that can serve communities, and domain names that can serve businesses, institutions and interests of every variety in a multitude of languages and scripts, are a good thing. We are starting to see the early blooms in the domain name garden, though with some Internationalized Domain Name (IDN) bare patches. We are seeing the emergence of new categories and innovative uses for domain names.

I do not blame those in the ICANN Global Domains Division (GDD) who are diligently trying to implement the AGB in all of its complex manifestations. Nor do I suspect them of any ill intent in using the myth of a multistakeholder approved AGB to keep the community in check during the implementation. Many of them joined ICANN Corporate after the AGB had been approved by the ICANN Board. They accepted the given dogma concerning the AGB being the result of a well formed bottom up multistakeholder process. How could they know about its real history? Additionally the leadership was new to the multistakeholder model, and in many cases were just quoting what they had been told without really understanding the multistakeholder environment within which they were situated.

Many parts of the New gTLD process were subject to multistakeholder participation and survived the AGB and the subsequent implementation, relatively unscathed. On the other hand, some important parts of the GNSO recommendations for the program were “bent, spindled and mutilated.” Decisions were made by the Board without GNSO consultation. The staff that developed the multiple versions leading up to the AGB,  largely different from the current GDD staff, frequently rejected the comments made by the GNSO and the rest of the ICANN Community on their Draft Application Guidebook (DAG) revisions. There were many cases in which the principles, recommendations and guidelines of the original GNSO recommendations were ignored. As the process continued and as ICANN staff continue to improvise to meet emerging issues, the GNSO recommendations are rarely, if ever, referred to, quoted or listed as the basis for decisions. Most people are, I expect, unable to even find the GNSO recommendations on the ICANN New gTLD website. Is it unreasonable to expect that the recommendations that are the foundation of the program would remain a visible reference for the program? In a time when the broader Internet community is looking at ICANN accountability and its adherence to bottom up multistakeholder processes, it is important to look at the New gTLD program and the degree to which it has really functioned as a community driven bottom up multistakeholder process.

Yes ICANN is a multistakeholder organization and yes, the New gTLD program had a large component of multistakeholder direction. But in doing the implementation, ICANN Corporate took lots of liberties with the way they interpreted the GNSO policy recommendations, doing so in a manner that occasionally appears incompatible with the spirit of the GNSO recommendations. To list just a few examples:

• First and foremost the process was supposed to be predictable: “New generic top-level domains (gTLDs) must be introduced in an orderly, timely and predictable way.” Except for the most intense cynics among ICANN watchers, there are few who think the New gTLD program has been predictable. I wonder was this first principle of the New gTLD program ever discussed when changes to the program were being considered? Was this first principle posted on a wall somewhere so that every staff member was working to make sure the program was predictable?
• Within the GNSO recommendations, it was intended that there be an opportunity for those in contention for similar strings, to negotiate and possibly even change the gTLD under application to a related string,  eliminating contention. The example of 3 applicants for .bear was frequently cited during the policy development process, an example in which after discussion the applicants in contention might have been able to agree on .ursus, .teddy and .gummy. ICANN refused to allow this process into the AGB because it was too hard and might have caused some of the initial evaluation to be re-run. No matter how many comments there were on this issue, ICANN stood firm in its refusal.
• The GNSO specifically requested that it be possible to have further discussion and re-reviews after the initial string similarity review. This request was rejected by ICANN Corporate. We have seen the continuing confusion and conflict that ensued from this rejection. Many of the confusing similarity issues, such as a string and its plural, should have been re-reviewed, without the need ofRequests for Reconsideration, the Independent Review Panel (IRP), and serious anxiety.
• The GNSO recommended that “There must be a base contract provided to applicants at the beginning of the application process.” While a base contract was provided in the Application Guide Book (AGB), this contract changed over time. Changed even to the extent that it now includes the Board’s unilateral prerogative to change the base contract under certain conditions. It is true, the GNSO did not specifically say that it could not be a draft base contract subject to change. But was that in the spirit of the recommendation?
• The program that was recommended to the Board specifically excluded lists of reserved geographical names. The Board unilaterally decided to add these anyway. The process was to be completely one of dispute resolution, including action by the GAC in respect to country and city names.
• The program that was presented to the Board by the GNSO was designed to protect vulnerable communities and domain names that were applicable to those communities. Instead of creating a program that supported and protected communities as discussed in the creation of the GNSO recommendations, ICANN Corporate created a gauntlet where many community applications were subjected to death by a thousand cuts.

Today there are few if any satisfactory methods within ICANN by which to redress these and the other deviations from the multistakeholder recommendations for the project. While the NTIA sits in oversight of ICANN, it does not interfere in its day to day operations; NTIA did not act in this oversight role to correct any of this behavior. At least not yet. One of the Affirmation of Commitments (AOC) reviews will soon be dedicated to New gTLD program considerations. The AOC review on Promoting Competition, Consumer Trust, and Consumer Choice (CCT),scheduled to begin in October 2015, includes the following: “ICANN will organize a review that will examine the extent to which the introduction or expansion of gTLDs has promoted competition, consumer trust and consumer choice, as well as effectiveness of (a) the application and evaluation process.“ 

Following that AOC CCT review, when it became time to renew the IANA contract, the ICANN renewal by NTIA could have, and perhaps should have, considered the report of the yet to be initiated AOC review. It is unimaginable, to me at least, that the convergence or divergence among the GNSO recommendations, the AGB and the implementation of the New gTLD program , would not have been significant in the AOC review of New gTLD program, or in the NTIA evaluation of ICANN’s accountability. While the 2015 renewal would have been too soon for such a review, certainly by 2017 or 2019 it would have been available. As the IANA transition may have occurred by then, it may be the ICANN Community that will need to decide on other redress mechanisms for any accountability issues found in the New gTLD program – Uncle Sam will no longer be looking over ICANN’s shoulder to insure that the right things happen, though the US will remain a part of the community as a member of the  ICANN Governmental Advisory Committee (GAC). Will the ICANN Community have the ability to do anything about it? With the Community Powers defined in the Cross Community Working Group’s (CCWG) Accountability plan, it may be possible. 

In the CCWG Accountability process, much has been said about Trust. Not trust in any of the particular directors or staff members, but in ICANN Corporate’s ability to live up to the multistakeholder expectations of the ICANN Community. As it was, the implementation of the New gTLD program has been as responsible as any other program at ICANN for engendering the unease and distrust that many express toward ICANN.

While ICANN has a strong multistakeholder tradition, it is one that is still evolving, and it is one where ICANN Corporate has an ability to go around the community’s policy recommendations when they feel it is necessary. This is one of the reasons that with the transition away from US NTIA external oversight and its power to remove the IANA contract from a flawed organization, the CCWG proposed strengthening the commitment to internal oversight. It is a reason why  the CCWG proposed formalizing power sharing between the ICANN Community and ICANN Corporate. It is expected that the community would be able to ensure that such a gap between the multistakeholder recommendations and the ensuing program does not happen this way again. ICANN’s bottom up multistakeholder system has a lot to recommend it. This note has focused on just one of the problems to which it is vulnerable.