4.4.3. Consensus in Internet governance

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.[1]

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.[2]

4.4.3.1. ICANN

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.[3]

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.[4] 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.[5] 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.[6] 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:

4.4.3.2. APNIC

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.”[22]

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.[23]

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.

4.4.3.3. IETF

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 2.2.1.1.

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.[24]

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).[25]

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.[26]

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.[27]

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.[28]

Notes

[1]

See Section 2.2.1.3.

[2]

See Section 2.1.2.1 and Section 2.2.1.

[3]

Dyson, Esther, Prepared Testimony (1999)

[4]

Compare Habermas, Jürgen, Between Facts and Norms: Contributions to a Discourse Theory of Law and Democracy (1996), 380

[5]

See Section 2.1.3.

[6]

See Section 4.2.2.1.

[7]

See http://www.icann.org/meetings/.

[8]

See http://forum.icann.org/.

[9]

See http://sp.icann.org/, and subsequently http://public.icann.org.

[10]

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.

[11]

Johnson, David R & Crawford, Susan P, What’s Wrong With ICANN—And How to Fix It (2000)

[12]

ICANN, Bylaws (2006), Article IX, Sections 1 and 4(11)

[13]

GNSO Council, New Rules of Procedure (2003), Articles 3.6, 5.4

[14]

ASO, Memorandum of Understanding (1999)

[15]

But see Section 4.4.3.2.

[16]

GAC, Operating Principles (2005), Principles 2 and 40

[17]

See generally ALAC, Charter (2005)

[18]

Post, David G, ICANN and the Consensus of the Internet Community (1999)

[19]

Johnson, David R & Crawford, Susan P, What an ICANN Consensus Report Should Look Like (2000)

[20]

See Section 4.1.2.

[21]

Biegel, Stuart, Beyond Our Control?: Confronting the Limits of Our Legal System in the Age of Cyberspace (2001), 223

[22]

Tseng, Kuo-Hung, Using Online Nominal Group Technique to Implement Knowledge Transfer (2006)

[23]

See http://www.apnic.net/meetings/remote/.

[24]

IETF, The Internet Standards Process—Revision 3 (1996), para 6.1

[25]

IETF, IETF Working Group Guidelines and Procedures (1994)

[26]

The same observation applies to chairs of APNIC SIGs, who are placed in the same position.

[27]

IETF, The Internet Standards Process—Revision 3 (1996), para 6.5

[28]

See Section 4.2.3.1.