Internet Engineering Task Force (IETF) P. Resnick
Request for Comments: 7282 Qualcomm Technologies, Inc.
Category: Informational June 2014
ISSN: 2070-1721
On Consensus and Humming in 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.
Note: This document is quite consciously being put forward as
Informational. It does not propose to change any IETF processes and
is therefore not a BCP. It is simply a collection of principles,
hopefully around which the IETF can come to (at least rough)
consensus.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7282.
Resnick Informational [Page 1]RFC 7282 On Consensus June 2014Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Lack of disagreement is more important than agreement . . . . 4
3. Rough consensus is achieved when all issues are addressed,
but not necessarily accommodated . . . . . . . . . . . . . . 7
4. Humming should be the start of a conversation, not the end . 10
5. Consensus is the path, not the destination . . . . . . . . . 13
6. One hundred people for and five people against might not be
rough consensus . . . . . . . . . . . . . . . . . . . . . . . 14
7. Five people for and one hundred people against might still be
rough consensus . . . . . . . . . . . . . . . . . . . . . . . 16
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. Informative References . . . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19
Resnick Informational [Page 2]RFC 7282 On Consensus June 2014
1. Introduction
Almost every IETF participant knows the aphorism from Dave Clark's
1992 plenary presentation [Clark] 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