You are here: Home / Internet Governance / Blog / Breaking Down ICANN Accountability: What It Is and What the Internet Community Wants

Breaking Down ICANN Accountability: What It Is and What the Internet Community Wants

Posted by Ramya Chandrasekhar at Nov 05, 2015 03:30 PM |
Filed under: ,
At the recent ICANN conference held in Dublin (ICANN54), one issue that was rehashed and extensively deliberated was ICANN's accountability and means to enhance the same. In light of the impending IANA stewardship transition from the NTIA to the internet's multi-stakeholder community, accountability of ICANN to the internet community becomes that much more important. In this blog post, some aspects of the various proposals to enhance ICANN's accountability have been deconstructed and explained.

The Internet Corporation for Assigned Names and Numbers, known as ICANN, is a private not-for-profit organization, registered in California. Among other functions, it is tasked with carrying out the IANA function[1], pursuant to a contract between the US Government (through the National Telecommunications and Information Administration – NTIA) and itself. Which means, as of now, there exists legal oversight by the USG over ICANN with regard to the discharge of these IANA functions.[2]

However, in 2014, the NTIA, decided to completely handover stewardship of the IANA functions to the internet’s ‘global multistakeholder community’. But the USG put down certain conditions before this transition could be effected, one of which was to ensure that there exists proper accountability within the ICANN.[3]

The reason for this, was that the internet community feared a shift of ICANN to a FIFA-esque organization with no one to keep it in check, post the IANA transition if these accountability concerns weren’t addressed.[4]

And thus, to answer these concerns, the Cross Community Working Group (CCWG-Accountability) has come up with reports that propose certain changes to the structure and functioning of ICANN.

In light of the discussions that took place at ICANN54 in Dublin, this blog post is directed towards summarizing some of these proposals - those pertaining to the Independent Review Process or IRP (explained below) as well the various accountability models that are the subject of extensive debate both on and off the internet.

Building Blocks Identified by the CCWG-Accountability

The CCWG-Accountability put down four “building blocks”, as they call it, on which all their work is based. One of these is what is known as the Independent Review Process (or IRP). This is a mechanism by which internal complaints, either by individuals or by SOs/ACs[5], are addressed. However, the current version of the IRP is criticized for being an inefficient mechanism of dispute resolution.[6]

And thus the CCWG-Accountability proposed a variety of amendments to the same.

Another building block that the CCWG-Accountability identified is the need for an “empowered internet community”, which means more engagement between the ICANN Board and the internet community, as well as increased oversight by the community over the Board. As of now, the USG acts as the oversight-entity. Post the IANA transition however, the community feels they should step in and have an increased say with regard to decisions taken by the ICANN Board.

As part of empowering the community, the CCWG-Accountability identified five core areas in which the community needs to possess some kind of powers or rights. These areas are – review and rejection of the ICANN budget, strategic plans and operating plans; review, rejection and/or approval of standard bylaws as well fundamental bylaws; review and rejection of Board decisions pertaining to IANA functions; appointment and removal of individual directors on the Board; and recall of the entire Board itself. And it is with regard to what kind of powers and rights are to be vested with the community that a variety of accountability models have been proposed, both by the CCWG-Accountability as well as the ICANN Board. However, of all these models, discussion is now primarily centered on three of them – the Sole Member Model (SMM), the Sole Designator Model (SDM) and the Multistakeholder Empowerment Model (MEM).

What is the IRP?

The Independent Review Process or IRP is the dispute resolution mechanism, by which complaints and/or oppositions by individuals with regard to Board resolutions are addressed. Article 4 of the ICANN bylaws lay down the specifics of the IRP. As of now, a standing panel of six to nine arbitrators is constituted, from which a panel is selected for hearing every complaint. However, the primary criticism of the current version of the IRP is the restricted scope of issues that the panel passes decisions on.[7]

The bylaws explicitly state that the panel needs to focus on a set on procedural questions while hearing a complaint – such as whether the Board acted in good faith or exercised due diligence in passing the disputed resolution.

Changes Proposed by the Internet Community to Enhance the IRP

To tackle this and other concerns with the existing version of the IRP, the CCWG-Accountability proposed a slew of changes in the second draft proposal that they released in August this year. What they proposed is to make the IRP arbitral panel hear complaints and decide the matter on both procedural (as they do now) and substantive grounds. In addition, they also propose a broadening of who all have locus to initiate an IRP, to include individuals, groups and other entities. Further, they also propose a more precedent-based method of dispute resolution, wherein a panel refers to and uses decisions passed by past panels in arriving at a decision.

At the 19th October “Enhancing ICANN-Accountability Engagement Session” that took place in Dublin as part of ICANN54, the mechanism to initiate an IRP was explained by Thomas Rickert, CCWG Co-Chair.[8]

Briefly, the modified process is as follows -

  • An objection may be raised by any individual, even a non-member.
  • This individual needs to find an SO or an AC that shares the objection.
  • A “pre-call” or remote meeting between all the SOs and ACs is scheduled, to see if objection receives prescribed threshold of approval from the community.
  • If this threshold is met, dialogue is undertaken with the Board, to see if the objection is sustained by the Board.
  • If this dialogue also fails, then IRP can be initiated.

The question of which “enforcement model” empowers the community arises post the initiation of this IRP, and in the event that the community receives an unfavourable decision through the IRP or that the ICANN Board refuses to implement the IRP decision. Thus, all the “enforcement models” retain the IRP as the primary method of internal dispute resolution.

The direction that the CCWG-Accountability has taken with regard to enhancement of the IRP is heartening. And these proposals have received large support from the community. What is to be seen now is whether these proposals will be fully implemented by the Board or not, in addition to all the other proposals made by the CCWG.

Enforcement  – An Overview of the Different Models

In addition to trying to enhance the existing dispute resolution mechanism, the CCWG-Accountability also came up with a variety of “enforcement models”, by which the internet community would be vested with certain powers. And in response to the models proposed by the CCWG-Accountability, the ICANN Board came up with a counter proposal, called the MEM.

Below is a tabular representation of what kinds of powers are vested with the community under the SMM, the SDM and the MEM.





Reject/Review Budget, Strategies and OPs.


Review/Reject Board decisions with regard to IANA functions.

Sole Member has the reserved power to reject the budget up to 2 times.

Member also has standing to enforce bylaw restrictions on the budget, etc.

Sole Designator can only trigger Board consultations if opposition to budget, etc exists. Further, bylaws specify how many times such a consultation can be triggered.

Designator only possesses standing to enforce this consultation.

Community can reject Budget up to two times. Board is required by bylaws to reconsider budget post such rejection, by consulting with the community. If still no change is made, then community can initiate process to recall the Board.

Reject/Review amendments to Standard bylaws and Fundamental bylaws

Sole Member has right to veto these changes. Further, member also standing to enforce this right under the relevant Californian law.

Sole Designator can also veto these changes. However, ambiguity regarding standing of designator to enforce this right.

No veto power granted to any SO or AC.

Each SO and AC evaluate if they want to voice the said objection. If certain threshold of agreement reached, then as per the bylaws, the Board cannot go ahead with the amendment.

Appointment and Removal of individual ICANN directors

Sole Member can appoint and remove individual directors based on direction from the applicable Nominating Committee.

Sole Member can appoint and remove individual directors based on direction from the applicable Nominating Committee.

The SOs/ACs cannot appoint individual directors. But they can initiate process for their removal.

However, directors can only be removed for breach of or on the basis of certain clauses in a “pre-service letter” that they sign.

Recall of ICANN Board

Sole Member has the power to recall Board.

Further, it has standing to enforce this right in Californian courts.

Sole Designator also has the power to recall the Board.

However, ambiguity regarding standing to enforce this right.

Community is not vested with power to recall the Board.

However, if simultaneous trigger of pre-service letters occurs, in some scenarios, only then can something similar to a recall of the Board occur.

A Critique of these Models


The Sole Member Model (or SMM) was discussed and adopted in the second draft proposal, released in August 2015. This model is in fact the simplest and most feasible variant of all the other membership-based models, and has received substantial support from the internet community. The SMM proposes only one amendment to the ICANN bylaws - a move from having no members to one member, while ICANN itself retains its character as a non-profit mutual-benefit corporation under Californian laws.

This “sole member” will be the community as a whole, represented by the various SOs and ACs. The SOs and ACs require no separate legal personhood to be a part of this “sole member”, but can directly participate. This participation is to be effected by a voting system, explained in the second draft, which allocates the maximum number of votes each SO and AC can cast. This ensures that each SO/AC doesn’t have to cast a unanimous vote, but each differing opinion within an SO/AC is given equal weight.


A slightly modified and watered down version of the SMM, proposed by the CCWG-Accountability as an alternative to the same, is the “Sole Designator Model” or the SDM. Such a model requires an amendment to the ICANN bylaws, by which certain SOs/ACs are assigned “designator” status. By virtue of this status, they may then exercise certain rights - the right to recall the Board in certain scenarios and the right to veto budgets and strategic plans.

However, there is some uncertainty in Californian law regarding who can be a designator - an individual or an entity as well. So whether unincorporated associations, such as the SOs and ACs, can be a “designator” as per the law is a question that doesn’t have a clear answer yet.

Where most discussion with respect to the SDM has occurred has been in the area of the designator being vested with the power to “spill” or remove all the members of the ICANN Board. The designator is vested with this power as a sort of last-resort mechanism for the community’s voice to be heard. However, an interesting point raised in one of the Accountability sessions at ICANN54 was the almost negligible probability of this course of action ever being taken, i.e. the Board being “spilled”. So while in theory this model seems to vest the community with massive power, in reality, because the right to “spill” the Board may never be invoked, the SDM is actually a weak enforceability model.

Other Variants of the Designator Model:

The CCWG-Accountability, in both its first and second report, discussed variants of the designator model as well. A generic SO/AC Designator model was discussed in the first draft. The Enhanced SO/AC Designator model, discussed in the second draft, also functions along similar lines. However, only those SOs and ACs that wanted to be made designators apply to become so, as opposed to the requirement of a mandatory designator under the SDM model.

After the second draft released by the CCWG-Accountability and the counter-proposal released by the ICANN Board (see below for the ICANN Board’s proposal), discussion was mostly directed towards the SMM and the MEM. However, the discussion with regard to the designator model has recently been revived by members of the ALAC at ICANN54 in Dublin, who unanimously issued a statement supporting the SDM.[9] And following this, many more in the community have expressed their support towards adopting the designator model.[10]


The Multi-stakeholder Enforcement Model or MEM was the ICANN Board’s counter-model to all the models put forth by the CCWG-Accountability, specifically the SMM. However, there is no clarity with regard to the specifics of this model. In fact, the vagueness surrounding the model is one of the biggest criticisms of the model itself.

The CCWG-Accountability accounts for possible consequences of implementation every model by a mechanism known as “stress-tests”. The Board’s proposal, on the other hand, rejects the SMM due to its “unintended consequences”, but does not provide any clarity on what these consequences are or what in fact the problems with the SMM itself are.[11]

In addition, many are opposed to the Board proposal in general because it wasn’t created by the community, and therefore not reflective of the community’s views, as opposed to the SMM.[12]

Instead, the Board’s solution is to propose a counter-model that doesn’t in fact fix the existing problems of accountability.

What is known of the MEM though, gathered primarily from an FAQ published on the ICANN community forum, is this: The community, through the various SOs and ACs, can challenge any action of the Board that is CONTRADICTORY TO THE FUNDAMENTAL BYLAWS only, through a binding arbitration. The arbitration panel will be decided by the Board and the arbitration itself will be financed by ICANN. Further, this process will not replace the existing Independent Review Process or IRP, but will run parallely.

Even this small snippet of the MEM is filled with problems. Concerns of neutrality with regard to the arbitral panel and challenge of the award itself have been raised.[13]

Further, the MEM seems to be in direct opposition to the ‘gold standard’ multi-stakeholder model of ICANN. Essentially, there is no increased accountability of the ICANN under the MEM, thus eliciting severe opposition from the community.

What is interesting to note about all these models, is that they are all premised on ICANN continuing to remain within the jurisdiction of the United States. And even more surprising is that hardly anyone questions this premise. However, at ICANN54 this issue received a small amount of traction, enough for the setting up of an ad-hoc committee to address these jurisdictional concerns. But even this isn’t enough traction. The only option now though is to wait and see what this ad-hoc committee, as well as the CCWG-Accountability through its third draft proposal to be released later this year, comes up with.

[1]. The IANA functions or the technical functions are the name, number and protocol functions with regard to the administration of the Domain Name System or the DNS.




[5]. SOs are Supporting Organizations and ACs are Advisory Committees. They form part of ICANN’s operational structure.

[6]. Leon Sanchez (ALAC member from the Latin American and Caribbean Region) speaking at the Enhancing ICANN Accountability Engagement Session !, ICANN54, Dublin (see page 5)

[7]. Leon Sanchez (ALAC member from the Latin American and Caribbean Region) speaking at the Enhancing ICANN Accountability Engagement Session !, ICANN54, Dublin (see page 5)

[8]. Thomas Rickert (GNSO-appointed CCWG co-chair) speaking at the Enhancing ICANN Accountability Engagement Session !, ICANN54, Dublin (see page 15,16)






Filed under: ,