The  Cross Community Working Group on Enhancing ICANN Accountability (CCWG) has released a second draft for public comment.  While the group has been enormously successful debating and coming to consensus on key areas (e.g., strengthening the Independent Review Process and Reconsideration processes), there continue to be some sticking points where consensus has not been achieved. As one would expect when engaged in institutional design, most contention revolves around the distribution of power. One specific issue is voting allocations within the proposed Community Mechanism that will be used for enforcing the proposed new community powers. The debate raises two major concerns. First, there is a major shift of power away from the Supporting Organizations and toward Advisory Committees, especially the At Large Advisory Committee (ALAC). Second, there is growing pressure to incorrectly reinvent ICANN governance structures along regional lines.

After much deliberation, the CCWG settled on a sole, incorporated “member” representing the various stakeholder bodies as the legal means by which community powers would be enforceable on ICANN. The community powers are what will, in the absence of the NTIA’s ability to yank the IANA contract, hold ICANN accountable to the global stakeholder community. The community’s powers will include:

  • Power to reconsider or reject the operating plan and budget
  • Power to reconsider or reject changes to ICANN “standard” Bylaws
  • Power to approve changes to “Fundamental” Bylaws (including bylaws pertaining to enforcing IANA function reviews outcomes)
  • Power to appoint and remove individual ICANN directors
  • Power to recall the entire ICANN Board.

This “member” could take action upon a vote facilitated by a proposed Community Mechanism. Of course, the devil is in the details of who is included in a Community Mechanism and how it would operate. The CCWG’s initial proposal gave 5 votes each to the GNSO, ccNSO, ASO, GAC and ALAC, and 2 votes each to the RSSAC and SSAC.  We previously argued that such an allocation was unwise and unfair, because it inappropriately allocated votes to advisory committees – including committees appointed by the ICANN board. Nonetheless, the CCWG states that:

This proposed voting weight is unchanged from the proposal made in our first Public Comment Report, and attracted the most support from CCWG-Accountability participants during the last meetings finalizing this Report. (51)

However, several alternative configurations have now been floated, as shown in Figure 1 below and described in the report:

One is that there should be a distinction in voting authority between SOs and ACs, with SOs having greater voting influence (e.g. 5 votes for SOs, 2 votes for ACs). [Alternative 2 below]

Another view is that there should be five votes allocated to each of the SOs and ACs. [Alternative 1 below]

A third view is that there should be four votes each for ASO, ccNSO, and GNSO, and two votes for ALAC. The GAC, the SSAC and the RSSAC would participate fully in discussions in the ICANN Community Forum (introduced in Section 6.3) but would not vote in the Community Mechanism. [Alternative 3 below]

Community Mechanism Structure
Figure 1: Community Mechanism Structure

It’s useful to compare these alternatives to the way the ICANN board is selected. This comparison is important for two reasons: one is that the ICANN board will continue to be ultimately responsible for the policies adopted as well as many other corporate governance decisions. Second, early on a CCWG legal scoping identified that “ICANN’s existing organizational framework represents a balancing of interests, and these mechanisms should not upset that balance.”

As Figure 2 below shows, half of ICANN’s sixteen-member board is directly placed by four sending bodies, along with ICANN’s CEO. Each of the SOs elect 2 members (for a total of 6 or 75%), and since 2010 the At-large Community elects one (or 12.5%). The other eight board members are indirectly selected by ICANN’s Nominating Committee, which was created by the 2002 “Committee on Evolution and Reform” (CER). Within the Nomcom selection structure, the ALAC has 33% of the vote by virtue of being the only body represented in Nomcom along regional lines.

Figure 2: Existing Board Selection Structures
Figure 2: Existing Board Selection Structures

If you put these two board selection mechanisms (Nomcom and direct election) together into a weighted average, the Advisory Committees select 3.64 board members out of the total of 16, or 23%, just less than a quarter of the total. The SOs account for the remaining 77%. Even if the denominator is decreased to 15 (accounting for ICANN’s CEO on the board), the weighted average only increases to 24%, still less than a quarter of the total.

Compare that to Alternative 1, which gives the ACs 57% of the voting power or even Alternative 2, which gives ACs almost half of the voting power. If it wasn’t clear before it should be now: the CCWG’s currently proposed vote allocation would be a substantial departure from the current distribution of votes and board members. It would constitute a dramatic shift of power in ICANN, enough to change the way it functions entirely.

The CCWG has tried to rationalize its vote allocation proposal by claiming that regional representation brings greater diversity of views:

The logic for 5 multiple “votes” per participant in the community mechanism among the five SOs and ACs allocated this number is to allow for greater diversity of views, including the ability to represent all the ICANN regions in each participating group.

This is a misleading argument. Even if one accepts the dubious premise that selecting one representative per world region improves “diversity” (as if everyone in a multi-billion person population had the same views), a shift to regional representation does not have to alter the balance of voting power. The CCWG could have proposed to alter the overall number of votes in a way that allowed the SO/AC proportions to remain the same. For example, it could give the SOs 10 votes (2 from each region). Or it could decouple votes from representation, and allow ALAC 5 participants but only 2 votes.

Building accountability structures according to regional lines only makes sense for bodies organized along regional or territorial lines, like ALAC and GAC.  That is why these bodies continue to push for 5 votes per body.

To conclude, Alternative 1, which gives 5 votes to all the ACs and SOs, would be a radical revision of ICANN’s makeup and should be eliminated from consideration immediately. Alternative 2, which allocates votes to all Advisory Committees, has serious problems which we noted before, including the obvious conflict of interest involved in relying on board-appointed people to keep the board accountable. Only Alternative 3 most closely reflects today’s distribution of power and should be the path forward.

4 thoughts on “CCWG Community Mechanism threatens to upset ICANN balance

  1. I think the bigger problem is that the community has got sucked into itself and the minutiae of voting and process and completely lost track of the overall purpose of having these mechanisms.

    As just one example: the process to remove IANA from ICANN has become completely unworkable. There are no less than 10 steps that have to go through seven different committees. Two of those committees have to be specially created and the process requires super majority votes from the two main supporting organizations not once but twice. And the ICANN Board has a say too.

    Spending all the time arguing about who should get what vote and who should decide what happens means that the actual ability to cause change is lost in the process.

    What’s more, this self-absorption is doing something very stupid: incorporating the NomCom into the next version of ICANN simply because it exists currently. What it should be doing is pulling it out.

    In short: navel-gazing is exactly the wrong activity right now.


    1. Excellent points, Kieren, especially about the absurdly complicated IANA Functions Review process. I hope you will make these comments in the public comment process.
      However, if the charge of navel-gazing means that we shouldn’t take the trouble to analyze and quantify the implications of what the CCWG has proposed, we would have to disagree.
      You are correct, however, that the CCWG basically lost sight of its broader goal of making ICANN accountable to the global multistakeholder community, and concentrated instead on making ICANN accountable only to the specific chartering organizations involved in developing the CCWG proposal.

      1. We’re in agreement, Milton.

        This is a valuable analysis and what is proposed needs to be looked at. But there needs to be a re-evaluation of what the overall goals are and whether what comes out actually achieves that.

        I would argue that both the IANA transition plan and the accountability plan have gone off track.

        A common complaint used to be that ICANN corporate would use ‘divide and conquer’ methods to maintain its unhealthy level of control. That was only partly true: the community does the job just as well itself.

        In broad, I think the accountability working group is relying far too heavily on high-end processes to bring in future accountability. ICANN will just tie it all up in process.

        Real accountability will only come when ICANN is obliged to provide information that it doesn’t want to, and when there are immediate consequences to it being caught not following its own rules.

  2. I agree with the comments by Kieren and Milton. While I agree with the gist of the article by Brenden, I would add a more fundamental concern, which is basically the one raised by Kieren and Milton: the proposal reduces ICANN’s external accountability and gives effective control of ICANN to the domain name and addressing industry, which is the very industry that ICANN is supposed to regulate.

    As far as I can tell, that was not the purpose of the exercise. The purpose of the exercise was to make ICANN more accountable to the broad communities that don’t normally participate in ICANN.

Comments are closed.