The Dublin meeting was not a train wreck. That much we can say. My assessment of ICANN 54 is not, to put it mildly, as chirpy as that of the Internet Society CEO, but it is more objective and nuanced. Insofar as progress on the transition is concerned, the deliberations among the CCWG, the GAC and the ICANN board averted a rupture that would have jeopardized the transition. But it did so primarily by caving in to the board-promulgated fears of creating a membership, and by side-stepping contentious issues. There are still a lot of loose ends.
Furthermore, it became clear that there are not just loose ends awaiting consensus and implementation, but a couple of gaping holes in the part of the IANA transition proposal developed by the names community’s CWG. (More about that later.)
Still, those who were waiting gleefully for the so-called multistakeholder model to collapse will be disappointed by the resilience that has been displayed. The IANA Stewardship Coordination Group (ICG) has completed its work combining and reconciling the names, numbers and protocols proposals. While the CCWG is not done, most people showed flexibility and a willingness to compromise methods but not principles. And the chairs of the CCWG have a real appetite for getting the work done. That being said, the cheerleaders of “the multistakeholder model,” the people leading the CCWG process, the NTIA and the ICANN board will have to be less self-congratulatory and more focused on achieving real consensus on a detailed, complete and workable plan. It’s time to make some hard choices.
One good, sensible decision that emerged from the meeting was the realization that the next round of CCWG revisions need to be put through a public comment process. Major changes are being made from the model put forward in the last round of comment. The changes are complex and their effects will be debatable and uncertain. There is no way this process can claim to have legitimacy and widespread public support without a formal comment period that enables all those tracking the process to carefully review and evaluate the proposal in its entirety, compare it to the last one, and express their opinion in writing.
One key decision was to abandon membership and move to a “Single Designator” (SD) as the reference model for enforcement of community powers. In theory, the CCWG will be taking a “requirements-based” approach to modifying its proposal; that is, it will determine whether the new SD model can actually deliver the community enforcement powers that the CCWG has agreed it needs. If so, it is still possible that the CCWG participants will determine that the SD model cannot meet the requirements. As of now, it looks as if the key difference between SD and Single Member is that SD places a lot more of its accountability bets on removing board members or spilling the entire board. This is a highly indirect form of accountability – usually people concerned about a board action want the specific action to be corrected, not an entirely new board. But the threat of removal might provide the desired results.
What about those loose ends we mentioned? There are at least four of them: 1) the ‘voting’ or ‘consensus’ structure of the community enforcement mechanism, 2) the role of the GAC, 3) the relationship between ICANN and the Root Zone Maintainer (Verisign) and 4) the IFO review and separation process.
Voting, Consensus and Rotten Boroughs
A critical feature of future ICANN accountability mechanisms is the ability of the community to vote to overturn or uphold board decisions. Political scientists and economists have done a lot of studies, some of them quite mathematical, about voting structures and the way they can affect outcomes. Public choice theory is but one of many examples. No one in ICANN seems to be aware of this. People designing the governance structure for a large-scale, consequential global institution routinely go around saying absurdly uninformed things, like “Advisory Committees (ACs) and Supporting Organizations (SOs) should all have the same weight in a voting process because the multistakeholder model means that all stakeholders should be on equal footing.” The fact that one AC (say, SSAC) has about 15 appointed members, whereas a Supporting Organization such as the GNSO is composed of 4 different stakeholder groups each of which has hundreds of organizations in it representing different interest groups, each of which may have thousands of members, does not seem to faze the drinkers of stakeholder equality kool aid. People in ICANN need to be more aware of the political and governance implications of what groups of people you draw circles around and call voting units. The fact that you drew circles around an arbitrary group and call them an AC or SO or a whatever does not mean that they are the same, appropriate unit for accountability voting decisions. And no, it does not matter at all whether you call them “voting” units or “consensus” units because either way, the structure of consent depends heavily on how many of these units there are and how many people are in them. People in the CCWG need to read a bit about the history of gerrymandering in the U.S. and rotten boroughs in the U.K.; they need to read about the way the Peoples Republic of China (and before them, the U.K.) manipulates “functional constituencies” to prevent Hong Kong from having real elections. The CCWG needs to think through the full implications of assigning voting power to various combinations of SOs and ACs. The goal should be to allow those most affected by particular policies or decisions to block bad things from happening (e.g., things inconsistent with the mission and core values, or board decisions that go against consensus or community will.) One idea that started to get floated at Dublin: disaggregating the SOs into stakeholder groups or regional units to get wider representation.
GAC and “stress test 18”
Stress test 18 was proposed by those concerned about a “takeover” or dominance of ICANN by governments. It asked, “What would happen if GAC changed its operating rules to allow it to give formal advice to the ICANN?” Those who believe that governments are nice, fuzzy partners in the multistakeholder model need to read a recent report from Freedom House, which concludes that:
over 61 percent of all internet users live in countries where criticism of the government, military or ruling family has been subject to censorship online, and over 58 percent live in countries where bloggers or ICT users were jailed for sharing content on political, social, and religious issues.
Currently, GAC advice counts as “advice” only if no government objects; i.e., GAC requires a true consensus before its advice to the board achieves its magical ability to bring the entire policy development process to a halt while the board and GAC deliberate over how to reconcile their views. But what if GAC changed its operating rules to allow decisions by majority rule? That would make “advice” a lot easier and more plentiful, strengthening the influence of a smaller number of governments in the process. In general, it would make the GAC more like a UN General Assembly meeting. This would inject inter-state politics directly into ICANN’s policy development process as various states formed voting coalitions against each other to achieve a simple majority or some percentage.
To prevent this, the CCWG proposed that ICANN bylaws be changed to make the Board answerable to GAC advice only when it is supported by full consensus. Some GAC members had no problem with this, but others objected strongly to it. The objectors felt as if the accountability process was singling out governments and trying to limit their influence in ICANN. They argued that GAC should define its own operating rules as it pleased.
At the Dublin meeting, the official word was that this conflict was resolved by the GAC Communique. But what really happened is that the Communique noted:
“1. The need that each and every Advisory Committee ensures that the advice provided is clear and reflects the consensus view of the Committee; and 2. The need that each and every Advisory Committee should preserve its own autonomy in its definition of consensus.”
In other words, the GAC said, “yeah, we should offer advice only when it is based on consensus….but we can define consensus any way we like, and our advice should have the same status as when it is supported by every government in the room.”
Obviously, this diplomatic sleight of hand merely wraps the underlying conflict up in prettier paper. No one who is worried about turning the GAC into the UN General Assembly is going to accept the idea that GAC can unilaterally redefine what it means by consensus and retain the same status for its advice. As Heritage Foundation’s Paul Rosenszwieg noted:
“This is not “accepting” Stress Test 18 it is deliberately avoiding the hard choice.”
The Root Zone Maintainer (RZM) contract
A major failing in the work of the CWG developing the proposal for names was its refusal to address the long-term relationship between the IANA Functions Operator, ICANN and the RZM. The proposal left a vacuum that will be filled in the near term by private negotiations between ICANN and Verisign. The CWG gave ICANN no constraints or requirements for this relationship. Which is odd because it treated the relationship between PTI and ICANN in great detail. The CWG justified this oversight by pretending that anything related to RZM was under the control of the NTIA as part of its separation and parallel process. But this was plainly false. The NTIA process simply modifies the cooperative agreement between Verisign and NTIA, it does not cover everything related to the RZM. Indeed, the CWG proposal already calls for the end of any authorization role and other measures affecting the way RZM gets done. The CWG simply refused to address other critical parts of this relationship. We are now relying almost entirely on ICANN’s discretion as to what these arrangements are, when these arrangements are changed, what requirements they must meet. Pressed in the public forum, ICANN’s chair said that ICANN would not try to take over the RZM role, and the ICG proposal demanded that the contract now being negotiated between ICANN and Verisign be open to public scrutiny. But in the short term, ICANN is in a very strong position to create “facts on the ground” that may be very difficult to change later.
Separability of IANA
Another flaw in the CWG plan emerged during the discussions in Dublin. Separability of the IANA Functions Operator (IFO) from ICANN was a major principle and requirement of all three operational communities (names, numbers, protocols). But in the names community, the subgroup that went off to define the details of the separation process seems to have fallen into a tangled briar patch of committees and reviews. Avri Doria’s attempt to diagram the separation process should make it clear, if it was not before, how virtually impossible it will be for the names IANA to be separated from ICANN.
One obscure detail that no one really noticed during the CWG process is that the creation of an IFO review and separation process requires the approval of the board before it can even get started. In other words, the board has to agree before the community can even create a committee to consider separation. This is stupid. IANA separation is one of the most significant forms of accountability over the board, and we are allowing the board to veto efforts to even consider it. Things related to IANA will have to be pretty bad to even get to the point of tying to create a separation committee. The idea that the board can block the effort getting started is just bad design.
We have already seen how ICANN can manipulate a process (CCWG) that is relatively independent, even with the prospect of an NTIA-supervised transition hanging over its head. What lengths will it go to, what levers will it pull, when a separation process is initiated and it doesn’t want it to happen, and it can kill it simply by refusing to go along with the creation of a committee? What was the CWG thinking when it put this kind of a mechanism into its proposal?
In sum, there are a lot of things to be worked out yet. And the clock is ticking. September 30, 2016 is now starting to look like a constraining deadline, not just a goal.
I would like to start these comments by thanking Milton Mueller for these thoughtful comments on the ICANN state of affairs coming out of the Dublin meetings. This is a comment so I will keep this short. I would like to tease forward the three “hot button” areas to watch closely as this transition train roles forward. In no particular order of importance those three areas are: (1) the power of the ICANN board, (2) the power of the GAC, and (3) the power of the constituency groups. It is no accident that all three areas include the word “power”, a term seldom used explicitly in the ICANN multistakeholder discussions. It is important to recognize that each of these power relationship issues is, and will be, ongoing. There is no simple path to settling them in a transition and accountability exercise.
While the ICANN board needs a viable multistakeholder context for legitimacy, there is a tension between the board seeking greater autonomy in decision making and constituencies seeking greater board accountability. It should be clear that such tension is endemic and will not be resolved by any one step accountability solution. This will be a recurrent challenge.
The role of the GAC places countries in a position that they are not accustom to being in, and one they will be less content with as the Internet looms larger on their domestic policy agendas. They will increasingly make their Internet governance moves inside and outside ICANN, depending on where they can best exercise their state power. This too will be a recurrent challenge and will call for Internet constituencies to be strongly organized both within countries, and beyond ICANN at the global level.
The actual power of constituencies within ICANN is influenced by two considerations. One is the need for legitimacy of ICANN’s multistakeholder model, as currently required for the IANA transition, and the other is the relative influence over policy within ICANN. The contracted and non-contracted business constituencies have the resource base for a greater policy making and implementation presence than do the non-business not-for-profit, NGO, and community constituencies. The key balancing factor here is support organization structures and processes. In the exercise of power, and the definition of structures and processes within ICANN, ideas about equal voting weights are fraught with problems. In the democratic ideal of “one person one vote” persons have a vote by virtue of being citizens and are accountable only to themselves. For any proposed “each constituency some votes” approach within ICANN the issue of accountability will loom large. While volunteers come from constituencies, they face no formal accountability to those constituencies. No matter how dedicated and capable volunteers are, there is a formal accountability problem here and a constituency vulnerability within ICANN’s multistakeholder model. It is not clear how this issue will be addressed.
Dear Milton,
Thank you for this excellent analysis. You start by saying that there was no train wreck, but fail to note that a train wreck was not possible because the railroad lines were carefully laid and policed by NTIA in such a way that the train could not literally wreck itself.
On the other hand, the railroad lines have been rearranged rather blatantly to avoid going down paths that the dominant players don’t like (e.g. membership, non-US jurisdiction, etc.).
Your post documents well the important unresolved issues.
But your post does not document, much less refer to, the fact that there was significant opposition to the ICG proposal for reasons in addition to the ones you highlight. For sure a majority of the commentators supported the ICG proposal in principle, but that majority consists primarily of people and entities that are deeply involved in ICANN. Most of the non-ICANN comments were negative.
So, while it is correct that the transition proposal has broad support within the ICANN community, it is not correct to conclude that it has broad support in the global multistakeholder community as a whole.
Since NTIA’s stated goal was to transition the IANA function to the global multistakeholder community, and not the ICANN community, I would say that the train has utterly failed to reach its intended destination: on the contrary, the train has been sidetracked to reach a totally different destination.