|Multi-Stakeholder Public Policy Governance and its Application to the Internet Governance Forum|
As will be recalled from Chapter 2, consensus is the dominant method for the internal governance of the existing institutions of Internet governance that preceded the IGF, including ICANN, the IETF and the W3C. A significant factor in this is that the decentralised norms of consensus decision-making are more compatible than those of hierarchical decision-making structures with the Internet’s cultural norms of decentralisation, interactivity, openness, egalitarianism and cosmopolitanism.
However, as foreshadowed by the introduction to this section, there is considerable variation in each organisation’s conception of consensus, including the degree of agreement required, the processes by which it should be fostered, and how and by whom it is declared.
Here, the different conceptions of consensus held by three of the major institutions of Internet governance—ICANN, APNIC, and the IETF—will be briefly compared, without retreading ground already covered when analysing their organisational structures.
In July 1999, then ICANN Chair Esther Dyson testified before the United States House of Representatives that
ICANN is nothing more or less than the embodiment of the Internet community as a whole. It reflects the participation of a large and growing number of technical, business, public-interest, academic, and other segments of the Internet community. It is this collection of diverse interests and experiences that produces ICANN policies and decisions, as a statement of the consensus of the participants.
Taking this statement at face value, it implies the existence of something like an online public sphere within which consensus on ICANN policies and decisions is developed, along with mechanisms by which for that consensus to be transmitted to its Board of Directors and implemented. As such, it provides a simple but conceptually sound model of a governance network that draws upon the consensus of all stakeholders both to ground its legitimacy and to structure its decision-making processes.
Unfortunately however, it is quite fictitious. None of its assumptions were fulfilled by ICANN in 1999, and they are still yet to be fully realised today, with the result that ICANN remains closer to an oligarchy than any other organisational form. Even so, it is possible to isolate four basic assumptions behind Dyson’s aspirational claim for ICANN, and to sketch ICANN’s progress towards fulfilling them:
If the consensus of the Internet community is to be reflective at all, there must exist a public sphere within which for it to be formed and articulated through public discourse. Although this is the promise of Internet democracy and is found in microcosm within certain virtual communities, there is no persuasive evidence that it exists on a large scale.
In an endeavour to provide a forum for outreach and informal consensus-building amongst the Internet community at large, ICANN holds regular open meetings in various cities around the world, and hosts asynchronous online fora. Open meetings are webcast, and beginning with the São Paulo meeting in December 2006, a Web site designed to facilitate remote participation, based on that developed for the first meeting of the IGF, was also made available. The limitation of these fora is that any consensus developed within them does not feed directly into ICANN’s governance processes.
A more direct link exists between ICANN’s Board and the narrower, more manageable segments of the Internet community represented by its three Supporting Organisations, which still encompass a fairly broad cross-section of the Internet community through their constituency groups.
However in general, ICANN does not require the SOs or their constituencies to reach consensus (indeed, on one view these top–down structures have been “gerrymandered to prevent emergence of true consensus”.) In fact, the only mention of consensus at all in ICANN’s current Bylaws applies to the process by which the CCNSO is to build consensus within the community of ccTLD managers over ccTLD-related issues. Consensus is said to exist where at least 14 of the 18 voting members of its Council are in agreement.
None of the other SOs are charged to operate by consensus at all, and neither is there is any mechanism to broker consensus between them. The GNSO Council uses a system of voting based on Robert’s Rules of Order, save that the gTLD registries and registrars exercise half of the vote, and the other constituencies share the other half. The Address Council of the ASO follows a similar but simpler procedure. As for the constituency groups—too many to go into individually—they are left to devise their own means of making decisions.
Assuming that there were effective fora in the public sphere within which for consensus on ICANN’s policies to be formed, ICANN would also require the means to discern this consensus. This is straightforward in the case of the SOs which are represented on ICANN’s board, but less so for those other stakeholder groups which are not. This is where ICANN’s five Advisory Committees could come in. Unlike the SOs, the ACs are not stakeholders in themselves (and thus do not have voting power within ICANN), but rather act as conduits for the transmission of the views of specified classes of external stakeholders to ICANN’s board.
Thus the Operating Principles of the GAC state that it is “not a decision making body,” and simply provide for the Chair to summarise the views expressed by its participants when reporting to the ICANN Board. Similarly, the ALAC’s main role is to coordinate the activities of the RALOs, which in turn serve the purpose of drawing in input from their constituent At-Large Structures, and to transmit this to ICANN’s Board. However, in the absence of an effective online public sphere, there is no particular reason why such input would or even should amount to consensus.
Third, but following from the second point, if there exist both effective fora within which for consensus to be formed, and the means of discerning that consensus, there should also be a process for ICANN to document it. Thus earlier in ICANN’s history, both Post, and Johnson and Crawford, suggested that ICANN be required when purporting to take actions by consensus, to table a report demonstrating that this was so.
According to Johnson and Crawford, the report should include amongst other matters an analysis of all substantial impacts of the proposal in question, a description of outreach conducted to those potentially affected, a summary of the arguments made for and against the proposal by impacted parties, and an analysis of why opposition to the proposal is believed to be limited, unreasoned, or arising only from those not impacted by its implementation.
A process broadly similar to this is now enshrined in Annexes A and B to ICANN’s Bylaws, which set out a detailed Policy Development Process (PDP) for the development of new policies by the GNSO and CCNSO respectively.
Finally, ICANN must have both the will and ability to act upon any consensus that has developed amongst its stakeholders and that it has discerned and documented. Its will is limited only by the fact that its Board always retains the discretion not to act upon the consensus of the community, whether expressed informally at public meetings or online fora, or formally through a PDP.
ICANN’s ability to give effect to the consensus of the Internet community is also restricted by institutional limitations on the scope of its activities that are required to be conducted consensually. In fact, a CCNSO PDP, requiring the approval of a two-thirds majority of CCNSO members, is the only means by which ICANN’s activities are formally subjected to a consensual test, and a loose one at that.
It may be that there are certain matters—such as the Board’s dealings with registries—that ought not to be governed by consensus, because reliance upon other forms of governance, such as markets, is more legitimate or effective in those circumstances. However, ICANN cannot truly live up to the claims made of it by Esther Dyson in 1999 while the scope of application of consensus decision-making within ICANN is as limited as it presently is. An organisation cannot accurately be said to be governed by consensus unless it is so governed at all levels of policy development, from agenda-setting through to decision-making.
Less time needs to be spent on discussing APNIC, the RIR for the Asia Pacific region and a constituent of ICANN’s ASO, as its procedures for decision-making by consensus are much simpler and more open than those of ICANN.
APNIC’s policy development process is self-described as one in which policies are “developed by the membership and the broader Internet community through a bottom–up process of consultation and consensus.”
The main forum in which this process takes place are the twice-yearly APNIC Open Policy Meetings (OPMs), held in various locations within the region, and which are open to APNIC members and non-members alike. For those from developing countries who could not otherwise attend an OPM in person, APNIC grants a number of fellowships. Remote participation is also facilitated using video streaming, audio streaming, live transcripts, Jabber chat software and podcasts.
The other fora for the policy development process are the mailing lists of APNIC’s Special Interest Groups (SIGs), of which there are currently seven on topics ranging from National Internet Registries (NIR) to DNS operation, routing and IPv6. These are also open to non-members, and are publicly archived.
A proposal for the adoption or amendment of an APNIC policy begins by tabling notice of the proposal to the relevant SIG mailing list and the SIG Chair at least four weeks prior to an OPM at which it is intended to be agreed. At the OPM, the proposal must meet with consensus both at the relevant SIG session, and also at the plenary Member Meeting. For this purpose, “consensus” is simply defined as “general agreement” as observed by the Chair of the meeting. If consensus is not reached at either stage, the SIG may resolve that the proposal should be amended for submission at a following OPM, or be withdrawn.
Following an OPM at which a proposal meets with consensus, an eight-week comment period begins, during which the proposal remains open for discussion on the relevant SIG mailing list. At the expiry of this period, the SIG Chair and co-chairs will determine whether any substantial objections to the proposal have been made. If so, then the proposal fails, and again the SIG may determine to amend it before it is proposed again, or to withdraw it.
A proposal that survives the comment period then goes to the Executive Council of APNIC, which will normally simply endorse the proposal as formal APNIC policy, but may refer it back to the SIG for further discussion if the Executive Council itself is unable to agree upon the proposal by majority vote, or may require a majority vote of endorsement by APNIC members. This introduces the possibility that the APNIC policy development process may not remain purely consensual throughout, as the last stage of decision-making may employ a hybrid of consensus and democracy.
The process for decision-making by consensus within the IETF has more in common with that of APNIC than that of ICANN. The movement of a specification through the IETF standards track from an Internet draft agreed within a Working Group, to a Proposed Standard (and thence a Draft Standard and eventually an Internet Standard) accepted by the community as a whole, has already been described in some detail at Section 126.96.36.199.
The IETF process requires consensus to a proposal to be formed at three levels within each stage of this standards track process. It must first achieve consensus within its originating Working Group. Once a rough consensus appears to have been reached, the Chair makes a “last call” for comments from the Working Group that normally lasts for two weeks, before forwarding the specification to the IESG.
The IESG then publishes the specification to an IETF-wide mailing list where a further “last call” for comments is made, lasting another two weeks for specifications that originate within an IETF Working Group, or four weeks for those submitted from outside the IETF.
The third and final level within which consensus must be obtained to the specification before it passes that stage of the standards track process is the IESG itself. The IESG may approve the document and request the RFC Editor to publish it, send it back to the Working Group for revision, or even reject it outright.
The IETF’s definition of consensus, such as it is, is found in RFC 1603 which states:
IETF consensus does not require that all participants agree although this is, of course, preferred. In general the dominant view of the working group shall prevail. (However, it must be noted that “dominance” is not to be determined on the basis of volume or persistence, but rather a more general sense of agreement.) Consensus can be determined by balloting, humming, or any other means on which the Working Group agrees (by rough consensus, of course).
Allowing Working Groups the flexibility of devising their own means of establishing rough consensus is naturally empowering, and limits the scope for the process to be subverted through strategic games. On the other hand, it places a lot of responsibility on the shoulders of Working Group Chairs, leaving them open to challenge if they should declare a rough consensus of the Working Group as a whole over the objections of a small minority.
In the case of disputes such as this that cannot be resolved within the Working Group, nor by the relevant Area Director, the IESG steps in to adjudicate. The IESG will also conduct an internal review when a decision of its own is challenged. These appeals and reviews may be further appealed to the IAB whose decision is final. Only in cases where the above procedures are insufficient to fairly and openly address the concerns of all parties, ISOC’s Board of Trustees may also hear an appeal, resolving it by whatever means it sees fit to adopt.
It can be seen from this that the IETF standards process also displays hybrid qualities; being consensual at the grass roots level, but remaining subject to the judicious use of hierarchical power at higher levels of governance when the pursuit of rough consensus has failed. But then, this is only a reflection of the fact that as open and inclusive as the IETF may be, it is fundamentally a meritocracy in practice.
See Section 188.8.131.52.
See Section 2.1.3.
See Section 184.108.40.206.
In the ASO’s case these are the RIRs, in the CCNSO’s case are organisations for each of the five geographic regions recognised by ICANN, and in the GNSO’s case are commercial and business users, gTLD registries, ISPs, non-commercial users, registrars and intellectual property owners: see http://gnso.icann.org/ for links to their respective Web sites.
ICANN, Bylaws (2006), Article IX, Sections 1 and 4(11)
GNSO Council, New Rules of Procedure (2003), Articles 3.6, 5.4
But see Section 220.127.116.11.
GAC, Operating Principles (2005), Principles 2 and 40
See generally ALAC, Charter (2005)
See Section 4.1.2.
The same observation applies to chairs of APNIC SIGs, who are placed in the same position.
See Section 18.104.22.168.