On Consensus and Humming in the IETF

A useful background in consensus based decision making generally, as well as the specifics of how it is practiced at the IETF.

Abstract

The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a "majority rule" philosophy. This is why we engage in rituals like "humming" instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day without consideration of minority concerns. This document explains some features of rough consensus, what is not rough consensus, how we have gotten away from it, how we might think about it differently, and the things we can do in order to really achieve rough consensus.

Introduction

Almost every IETF participant knows the aphorism from Dave Clark's 1992 plenary presentation ¹ regarding how we make decisions in the IETF:

We reject: kings, presidents and voting. We believe in: rough consensus and running code.

That is, our credo is that we don't let a single individual dictate decisions (a king or president), nor should decisions be made by a vote, nor do we want decisions to be made in a vacuum without practical experience. Instead, we strive to make our decisions by the consent of all participants, though allowing for some dissent (rough consensus), and to have the actual products of engineering (running code) trump theoretical designs.

Having full consensus, or unanimity, would be ideal, but we don't require it: Requiring full consensus allows a single intransigent person who simply keeps saying "No!" to stop the process cold. We only require rough consensus: If the chair of a working group determines that a technical issue brought forward by an objector has been truly considered by the working group, and the working group has made an informed decision that the objection has been answered or is not enough of a technical problem to prevent moving forward, the chair can declare that there is rough consensus to go forward, the objection notwithstanding.

To reinforce that we do not vote, we have also adopted the tradition of "humming": When, for example, we have face-to-face meetings and the chair of the working group wants to get a "sense of the room", instead of a show of hands, sometimes the chair will ask for each side to hum on a particular question, either "for" or "against".

However, in recent years we have seen participants (and even some folks in IETF leadership) who do not understand some of the subtleties of consensus-based decision making. Participants ask, "Why don't we just vote? Why are we bothering with this 'humming' thing?" Or even more concerning, "We've already hummed/voted, so why isn't the discussion concluded?" Chairs, many of whom have little experience in leading large volunteer groups like those in the IETF, let alone experience in how to gather consensus, are faced with factious working groups with polarized viewpoints and long-running unresolved issues that return again and again to the agenda. More and more frequently, people walk away from working groups, thinking that "consensus" has created a document with horrible compromises to satisfy everyone's pet peeve instead of doing "the right thing".

None of these things are indicators of a rough consensus process being used, and the fact that we are seeing them is likely due to some basic misperceptions.'

This document explains some features of rough consensus, explains what is not rough consensus, discusses some new ways to think about rough consensus, and suggests ways that we might achieve rough consensus and judge it in the IETF. Though this document describes some behaviors of working groups and chairs, it does so in broad brushstrokes and it does not prescribe specific procedures. Rather, this document is intended to foster understanding of the underlying principles of IETF consensus processes. While it may be of general interest to anyone interested in the IETF consensus processes, the primary audience for this document is those who have experience working in the IETF and are trying to understand and participate in the consensus-building process, and it is particularly aimed at generating thought and discussion among those who might lead a consensus discussion. Although most of the examples in this document talk about working group chairs, these principles apply to any person who is trying to lead a group to rough consensus, whether a chair, a design team leader, a document editor, an area director, or any community member who is facilitating a discussion or trying to assess consensus.

While the community has come to rough consensus that the principles expressed in this document are (at least approximately) right, many of our current practices are not consistent with these principles.

Again, this document is primarily intended to generate thought and discussion, not dictate practices. If the IETF does commit itself to these principles, practices may change in the future.

Table of Contents

Abstract and Introduction are included above:

1. Introduction
2. Lack of disagreement is more important than agreement
3. Rough consensus is achieved when all issues are addressed, but not necessarily accommodated
4. Humming should be the start of a conversation, not the end
5. Consensus is the path, not the destination
6. One hundred people for and five people against might not be rough consensus
7. Five people for and one hundred people against might still be rough consensus
8. Conclusion
9. Security Considerations
10. Informative References