Internet Engineering Task Force P. Resnick
Internet-Draft Qualcomm Technologies, Inc.
Intended status: Informational November 01, 2013
Expires: May 05, 2014
On Consensus and Humming in the IETF
draft-resnick-on-consensus-06
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 is a collection of thoughts on what rough
consensus is, 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 (to be removed before publication): 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 05, 2014.
Resnick Expires May 05, 2014 [Page 1]
Internet-Draft On Consensus November 2013
Copyright Notice
Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Lack of disagreement is more important than agreement . . . . 4
3. Rough consensus is achieved when all issues are addressed,
but not necessarily accommodated . . . . . . . . . . . . . . 6
4. Humming should be the start of a conversation, not the end . 8
5. Consensus is the path, not the destination . . . . . . . . . 12
6. One hundred people for and five people against might not be
rough consensus . . . . . . . . . . . . . . . . . . . . . . . 13
7. Five people for and one hundred people against might still be
rough consensus . . . . . . . . . . . . . . . . . . . . . . . 14
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. Informative References . . . . . . . . . . . . . . . . . . . 17
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
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 (kings and presidents), nor should decisions be made by a
simple vote of the majority, 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
Resnick Expires May 05, 2014 [Page 2]
Internet-Draft On Consensus November 2013
some dissent (rough consensus), and to have the actual products of
engineering trump theoretical designs (running code).
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, the chair of the working group wants
to get a "sense of the room" during a face-to-face meeting, instead
of a show of hands, sometimes the chair will ask for each side to hum
for or against a question.
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 are we bothering with this 'humming' thing? Wouldn't a show of
hands be easier? That way we could really see how many people want
one thing over another." 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 are likely due to some basic misperceptions.
This document attempts to explain some features of rough consensus,
explain what is not rough consensus, discuss some new ways to think
about rough consensus, and suggest 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 proscribe 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 expected to be those who have
experience working in the IETF, and it is particularly aimed at
generating thought and discussion among those who might lead a
Resnick Expires May 05, 2014 [Page 3]
Internet-Draft On Consensus November 2013
consensus discussion. Although most of the examples in this document
talk about working group chairs, these principles are meant to 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 IESG
area director, or any community member who is facilitating a
discussion or trying to assess consensus.
2. Lack of disagreement is more important than agreement
A working group comes to a technical question of whether to use
format A or format B for a particular data structure. The chair
notices that a number of experienced people think format A is a good
choice. The chair asks on the mailing list, "Is everyone OK with
format A?" Inevitably, a number of people object to format A for one
or another technical reason. The chair then says, "It sounds like we
don't have consensus to use format A. Is everyone OK with format B?"
This time even more people object to format B, on different technical
grounds. The chair, not having agreement on either format A or
format B, is left perplexed, thinking the working group has
deadlocked.
The problem that the chair got themselves into in the above case was
thinking that what they were searching for was agreement. "After
all", thinks the chair, "consensus is a matter of getting everyone to
agree, so asking whether everyone agrees is what the chair ought to
do. And if lots of people disagree, there's no consensus." But
_determining_ consensus and _coming to_ consensus are different
things than _having_ consensus.
The distinction might be a bit subtle, but it's important.
Engineering always involves a set of tradeoffs. It is almost certain
that any time engineering choices need to be made, there will be
options that appeal to some people that are not appealing to some
others. In determining consensus, the key is to separate those
choices that are simply unappealing from those that are truly
problematic. If at the end of the discussion some people have not
gotten the choice that they prefer, but they have become convinced
that the chosen solution is acceptable, albeit less appealing, they
have still come to consensus. Consensus doesn't require that
everyone is happy and agrees that the chosen solution is the best
one. Consensus is when everyone is sufficiently satisfied with the
chosen solution, such that they no longer have specific objections to
it.
So in the case of a working group decision, after the initial
discussion of the pros and cons of the available choices, it is most
important to ask not just for objections to a particular proposal,
but for the nature of those objections. A chair who asks, "Is
Resnick Expires May 05, 2014 [Page 4]
Internet-Draft On Consensus November 2013
everyone OK with choice A?" is going to get objections. But a chair
who asks, "Can anyone not live with choice A?" is more likely to only
hear from folks who think that choice A is impossible to engineer
given some constraints. Following up with, "What are the reasons you
object to choice A?" is also essential. Then the purported failings
of the choice can be examined by the working group. The objector
might convince the rest of the group that the objections are valid
and the working group might choose a different path. Conversely, the
working group might convince the objector that the concerns can be
addressed, or that the choice is simply unappealing (i.e., something
the objector can "live with") and not a show-stopper. In any event,
closure is much more likely to be achieved quickly by asking for and
trying to accommodate the objections rather than asking for
agreement.
This also brings up an important point about reaching consensus and
"compromising": Unfortunately, the word "compromise" gets used in two
different ways, and though one sort of compromising to come to
consensus is good (and important), the other sort of compromising in
order to achieve consensus can actually be harmful. As mentioned
earlier, engineering always involves balancing tradeoffs, and
figuring out whether one engineering decision makes more sense on
balance compared to another involves making engineering
"compromises": We might have to compromise processor speed for lower
power consumption, or compromise throughput for congestion
resistance. Those sorts of compromises are among engineering
choices, and they are expected and essential. We always want to be
weighing tradeoffs and collectively choosing the best set.
However, there is another sense of "compromise" that involves
compromising between people, not engineering principles. For
example, a minority of a group might object to a particular proposal,
and even after discussion still think the proposal is deeply
problematic, but decide that they don't have the energy to argue for
it and say, "Forget it, do what you want". That surely can be called
a compromise, but a chair might mistakenly take this to mean that
they agree, and have therefore come to consensus. But really all
that they've done is capitulated; they've simply given up by trying
to appease the others. That's not coming to consensus; there still
exists an outstanding unaddressed objection. Again, if the objection
is only that the choice is not ideal but is otherwise acceptable,
such a compromise is fine. But conceding when there is a real
outstanding technical objection is not coming to consensus.
Even worse is the "horse-trading" sort of compromise: "I object to
your proposal for such-and-so reasons. You object to my proposal for
this-and-that reason. Neither of us agree. If you stop objecting to
my proposal, I'll stop objecting to your proposal and we'll put them
Resnick Expires May 05, 2014 [Page 5]
Internet-Draft On Consensus November 2013
both in." That again results in an "agreement" of sorts, but instead
of just one outstanding unaddressed issue, this sort of compromise
results in two, again ignoring them for the sake of expedience.
These sorts of "capitualation" or "horse-trading" compromises have no
place in consensus decision making. In each case, a chair who looks
for "agreement" might find it in these examples because it appears
that people have "agreed". But answering technical disagreements is
what is needed to achieve consensus, sometimes even when the people
who stated the disagreements no longer wish to discuss them.
Coming to consensus is when everyone (including the person making the
objection) comes to the conclusion that either the objections are
valid, and therefore make a change to address the objection, or that
the objection was not really a matter of importance, but merely a
matter of taste. Of course, coming to full consensus like that does
not always happen. That's why in the IETF, we talk about "rough
consensus".
3. Rough consensus is achieved when all issues are addressed, but not
necessarily accommodated
The preceding discussion gives an example where the working group
comes to consensus on a point: Either the objector is satisfied, or
the working group is satisfied. But that doesn't happen all of the
time, and it's certainly not the problematic case. Again,
engineering is always a set of tradeoffs. Often, a working group
will encounter an objection where everyone understands the issue and
acknowledges that it is a real shortcoming in the proposed solution,
but the vast majority of the working group believes that
accommodating the objection is not worth the tradeoff of fixing the
problem.
So, an objector might say, "The proposal to go with protocol X is
much more complicated than going with protocol Y. Protocol Y is a
much more elegant and clean solution, which I can code much more
easily, and protocol X is a hack." The working group might consider
this input, and someone might respond, "But we have a great deal of
code already written that is similar to protocol X. While I agree
that protocol Y is more elegant, the risks to interoperability with
an untested solution is not worth it compared to the advantages of
going with the well-understood protocol X." If the chair finds, in
their technical judgement, that the issue has truly been considered,
and that the vast majority of the working group has come to the
conclusion that the tradeoff is worth making, even in the face of
continued objection from the person(s) who raised the issue, the
chair can declare that the group has come to rough consensus.
Resnick Expires May 05, 2014 [Page 6]
Internet-Draft On Consensus November 2013
Note that this portrays rough consensus as a fallback. In one sense,
it is: As a working group does its work and makes its choices, it
behaves as if it is striving toward full consensus and tries to get
all issues addressed to the satisfaction of everyone in the group,
even those who originally held objections. It treats rough consensus
as a sort of "exception processing", to deal with cases where the
person objecting still feels strongly that their objection is valid
and must be accommodated. But it is certainly true that more often
than not in the IETF, at least someone in the group will be
unsatisfied with a particular decision. In that sense, rough
consensus might be closer to the norm than the exception. However,
when a participant says, "That's not my favorite solution, but I can
live with it; I'm satisfied that we've made a reasonable choice",
that participant is not in the "rough" part of a rough consensus; the
group actually reached consensus if that person is satisfied with the
outcome. It's when the chair has to declare that an unsatisfied
person still has an open issue, but that the group has truly answered
the objection, that the consensus is only rough.
Now, a conclusion of having only rough consensus relies heavily on
the good judgement of the consensus caller. The group must truly
consider and weigh an issue before the objection can be dismissed as
being "in the rough". ("In the rough" is terminology from golf. The
phrase, which gets used quite a bit in the IETF, is just a play on
words.) The chair of the working group in one of these cases is
going to have to decide that not only has the working group taken the
objection seriously, but that it has fully examined the ramifications
of not making a change to accommodate it, and that the outcome does
not constitute a failure to meet the technical requirements of the
work. In order to do this, the chair will need to have a good idea
of the purpose and architecture of the work being done, perhaps
referring to the charter of the working group or a previously
published requirements document, and use their own technical
judgement to make sure that the solution meets those requirements.
What can't happen is that the chair bases their decision solely on
hearing a large number of voices simply saying, "The objection isn't
valid." That would simply be to take a vote. A valid justification
needs to me made.
It is important to recognize that this view of rough consensus is a
change from the way it has been traditionally characterized in the
IETF. Rough consensus in the IETF is often talked about as the
"dominant view" of the group, as RFC 1603 [RFC1603] described:
Working groups make decisions through a "rough consensus" process.
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
Resnick Expires May 05, 2014 [Page 7]
Internet-Draft On Consensus November 2013
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 WG agrees (by rough consensus, of
course).
The above does say that "volume" is not the basis for a determination
of consensus, but over the years many IETF folks have thought of
rough consensus as being primarily about the percentage of people who
agree with a decision. Indeed, RFC 2418 [RFC2418] adds on to the
above text by saying, "Note that 51% of the working group does not
qualify as 'rough consensus' and 99% is better than rough." While
counting heads might give a good guess as to what the rough consensus
will be, doing so can allow important minority views to get lost in
the noise. One of the strengths of a consensus model is that
minority views are addressed, and using a rough consensus model
should not take away from that. That is why this document talks
about looking at open issues rather than just counting the number of
people who do or do not support any given issue. Doing so has some
interesting and surprising implications that are discussed in
subsequent sections.
Any finding of rough consensus needs, at some level, to provide a
reasoned explanation to the person(s) raising the issue of why their
concern is not going to be accommodated. A good outcome is for the
objector to understand the decision taken and accept the outcome,
even though their particular issue is not being accommodated in the
final product.
Remember, if the objector feels that the issue is so essential that
it must be attended to, they always have the option to file an
appeal. A technical error is always a valid basis for an appeal.
The chair (or whoever is responsible to hear an appeal) may determine
that the issue was addressed and understood, but they also have the
freedom and the responsibility to say, "The group did not take this
technical issue into proper account" when appropriate. Simply having
a large majority of people agreeing to dismiss an objection is not
enough to claim there is rough consensus; the group must have
honestly considered the objection and evaluated that other issues
weighed sufficiently against it. Failure to do that reasoning and
evaluating means that there is no true consensus.
4. Humming should be the start of a conversation, not the end
We don't vote in the IETF. In some ways, we can't vote: Since the
IETF is not a membership organization, it's nearly impossible to
figure out who would get a vote for any given question. We can't
know who the "members" of any given working group would be at any one
Resnick Expires May 05, 2014 [Page 8]
Internet-Draft On Consensus November 2013
time, and we certainly can't know who all of the "members" of the
IETF would be: That's why we refer to "participants" in the IETF; the
IETF doesn't really have "members". Indeed, we often recruit
additional implementers and other experts into working groups in
order to ensure that broader views are brought into the discussion.
So voting is simply not practical. We've also decided that coming to
consensus (albeit sometimes rough consensus) is an important thing to
do. Final decisions are supposed to be taken on the mailing list,
which reinforces the idea that we come to consensus by looking at the
open issues and not counting heads. Sometimes we do discuss things
face-to-face, but we don't want to vote there either; we want to show
that we are coming to consensus. So instead of voting, we often
"hum".
However, more and more we see people who think that a hum is a sort
of anonymous vote, with some chairs calling every question they have
for the working group by asking for a hum and judging the result by
the loudest hum, even saying things like, "There were lots of hums
for choice 1 and very few hums for choice 2, so it sounds like we
have rough consensus for choice 1." This misses some really
important points of using humming and is almost certainly mis-
assessing the consensus. Hums should not be used as votes.
So, why should we engage in this strange practice of humming? What
are good reasons to "take a hum"? One reason is pragmatic. Quite
often, a chair is faced with a room full of people who seem to be
diametrically opposed on some choice facing the group. In order to
find a starting place for the conversation, it can be useful for the
chair to ask for a hum to see if one of the choices already has a
stronger base of support than the other (or any significant base of
support at all, for that matter). Sometimes the hum can tell a chair
that the room isn't all that contentious after all, that it's just a
few voices who were being especially vociferous during the initial
discussion.
Resnick Expires May 05, 2014 [Page 9]
Internet-Draft On Consensus November 2013
Sometimes, the hum will make it clear that choice "foo" has a
significant amount more support than choice "bar", and it is
therefore likely easier to start the discussion by saying, "OK, 'foo'
seems to have quite a bit of support. Let's have the people that
think 'foo' is a bad idea come up and tell us why it is problematic."
At that point, the group can start going through the issues and see
if any of them are showstoppers. It could always turn out that one
of the objections is instantly recognized by the entire group as a
fatal flaw in "foo" and the group will then turn to a discussion of
the merits (and demerits) of "bar" instead. All that the hum does is
give the chair a starting point: The hum indicated that there were
less objections to "foo" than to "bar" at the beginning of the
discussion, so starting with the objections to "foo" might shorten
the discussion.
Another good reason for us to hum is because it actually gives the
chair the opportunity to take the temperature of the room. A smaller
bunch of loud hums for choice A and a larger number of non-committal
hums for choice B might indicate that some people believe that there
are serious problems with choice B, albeit the more popular by sheer
number of people. The chair might decide that starting with choice A
and getting objections to it is the easier path forward and more
likely to result in consensus in the end. Remember, coming to
consensus is a matter of eliminating disagreements, so the chair
wants to choose the path that gets to the least objections fastest.
A bunch of people who are not strongly committed to B might have no
real technical objection to A, even though it is not their first
preference. There is always a chance that this could be misleading,
because some people are more willing to hum loudly than others (just
by dint of personality), or that one of the quieter hums actually
turn outs to be a showstopper that makes the original choice
impossible, but keep in mind that taking the hum in this case is to
figure out how to start the conversation. The chair could always be
surprised because the hum turns out to be unanimous and no further
discussion is needed. Otherwise, the hum begins the discussion, it
doesn't end it.
But couldn't all of the above could have been done with a show of
hands instead of a hum? Sure, but there are more formal reasons for
using a hum instead of a show of hands: Of course, a chair could get
the temperature of the room by doing a show of hands too, and knowing
who specifically feels one way or another can help a good chair guide
the subsequent conversation. However, a show of hands might leave
the impression that the number of people matters in some formal way.
A chair and a working group with a solid understanding of how
consensus works can certainly do a show of hands and achieve exactly
the same result as a hum. But with less experienced folks, a show of
hands can end up reinforcing the mistaken notion that a vote is
Resnick Expires May 05, 2014 [Page 10]
Internet-Draft On Consensus November 2013
taking place. A chair can always take the hum and then later ask for
specific folks to identify themselves to elicit more discussion. The
advantage of the hum is that it makes it perfectly clear that the
chair is simply figuring out the direction of the conversation.
This also points to another misuse of the hum: If the chair is
already convinced that the group has come to consensus, there is no
reason to take a hum. In fact, taking the hum only serves to
discourage those who might be in the minority from voicing their
concerns to the group in the face of a large majority who want to
move forward. The right thing for the chair to do if they already
sense consensus is to say, "It sounds to me like we have consensus
for choice A. Does anybody have any concerns or objections to going
with A?" This allows folks to bring up issues to the group that the
chair might have mistakenly missed without having them feel that the
majority has "already spoken".
The reverse situation can also have similar advantages and
disadvantages: Sometimes a chair (say of a birds-of-a-feather
session, or a working group discussing a new proposed document) might
want to make sure that there really is a good base of support to go
forward with a proposal, and takes a hum. This can let the chair see
if there are more than a handful of active people who are really
interested in the new work. However, this has pitfalls as well:
Someone may be dissuaded from raising what could be an essential
concern if they feel that the group is overwhelmingly in favor of
going forward, or conversely some folks may decide to "hum along with
the crowd" even though they're not committed to the outcome. Indeed,
the formulation, or even the order, of questions asked during a hum
can have huge effects on the outcome: Asking simply, "Who supports
going forward with this proposal?", and asking it first, can itself
cause more people to hum in the affirmative than would for
differently formulated questions, or asking the same question after
some more "negatively" framed questions. Hums (or even a show of
hands) must be done with caution, and should almost always be used to
prompt discussion and questions, not be the conclusion of the matter.
There are times where the result of a hum is a pretty even split. In
practical terms, that means it doesn't matter where the chair starts
the discussion. And in fact, we've had working groups where a coin-
flip decided which proposal to start with. That doesn't mean that
the coin-flip determined the outcome; if a fatal technical flaw was
found in the solution that won the coin flip, it is still incumbent
upon the group to address the issue raised, or abandon that solution
and find another. Rough consensus on the technical points, in the
end, is always required. Any way to find a place to start, be it the
hum or the coin-flip, is only getting to the beginning of the
discussion, not the end.
Resnick Expires May 05, 2014 [Page 11]
Internet-Draft On Consensus November 2013
5. Consensus is the path, not the destination
We don't try to reach consensus in the IETF as an end in itself. We
use consensus-building as a tool to get to the best technical (and
sometimes procedural) outcome when we make decisions. Experience has
shown us that traditional voting leads to gaming of the system,
"compromises" of the wrong sort described earlier, important minority
views being ignored, and in the end worse technical outcomes.
Coming to consensus by the looking for objections, tracking open
issues, and using hums as the start of discussions and not the end
can all take some patience. Indeed, sometimes objection-based or
issue-based decision making can be extremely difficult because there
can be large factions who have diametrically opposed views. And
there is no doubt that we do see some amount of political compromise
(that is, the undesirable kind of compromise) from time to time in
the IETF.
However, accepting these things has its price. When we decide that a
discussion is too factious and opt to simply go with a majority, it
creates more polarized arguments in the future: Instead of working
toward the best technical outcome that most everyone can accept,
people are much quicker to run to opposing sides and dig in to their
positions. And when we allow real technical issues to drop because
proponents have simply capitulated or have "horse-traded" to allow
other technical problems to remain, the end product is weaker.
Though the IETF can never be perfectly principled with regard to
rough consensus, failing to be vigilant about sticking to the
principles makes it increasingly hard to stick to them in the future,
and ends us up with worse technical output.
Again, coming to consensus is not the goal in itself. Coming to
consensus is what we do during our processes to arrive at the best
solution. In particular, "declaring" consensus is not an end goal.
Attempts to declare consensus at the end of a discussion just for the
sake of being able to say that there is consensus often get us back
into the voting mentality that we're trying to avoid.
We often hear chairs say that they are making a "consensus call".
Sometimes, they simply mean they are making a call _of_ the
consensus; that is, they are declaring the consensus that has, in
their view, been reached when the discussion has reached an end.
That's a fine thing and what chairs are supposed to do: They are
"calling" the consensus. Sometimes, when a chair says that they are
making a "consensus call", the chair is actually making a call _for
discussion_ of a particular point in order to reach consensus.
Although it's a bit odd to call that a "consensus call" (as opposed
to a "call for discussion" or the like), it is fine for a chair to
Resnick Expires May 05, 2014 [Page 12]
Internet-Draft On Consensus November 2013
occasionally identify a particular point of contention and get the
group to focus discussion on it in order to reach consensus. But
more and more often, we hear chairs say that they are making a
"consensus call" at the end of a discussion, where the chair will
pose the classic "Who is in favor of choice A? Who is in favor of
choice B?" questions to the working group. That's not really a
"consensus call", and has the same potential problems as the "hum" at
the end of a discussion: It can be tantamount to asking for a vote.
Even talk of "confirming consensus" has this problem: It implies that
you can confirm that there is consensus by counting people, not
issues. The important thing for a chair to do is to "call consensus"
in the sense of declaring the consensus; others can always object and
say that the chair has gotten the consensus wrong and ask for
reconsideration. But the chair ought to be looking for consensus
throughout the discussion, not asking for it at the end.
There are some times where chairs will ask a question or take a hum
toward the end of a discussion in order to figure out the state of
consensus, but this must be done with extreme caution. This is
discussed in the next section.
6. One hundred people for and five people against might not be rough
consensus
Remember that consensus is found when all of the objections have been
addressed. Because of this, using rough consensus avoids a major
pitfall of a straight vote: If there is a minority of folks who have
a valid technical objection, that objection must be dealt with before
consensus can be declared. This also reveals one of the great
strengths of using consensus over voting: It isn't possible to use
"vote stuffing" (simply recruiting a large number of people to
support a particular side, even people who have never participated in
a working group or the IETF at all) to change the outcome of a
consensus call. As long as the chair is looking for outstanding
technical objections and not counting heads, vote stuffing shouldn't
affect the outcome of the consensus call.
So in a large working group with over 100 active participants and
broad agreement to go forward with a particular protocol, if a few
participants say, "This protocol is going to cause congestion on the
network, and it has no mechanism to back off when congestion occurs;
we object to going forward without such a mechanism in place", and
the objection is met with silence on the mailing list, there is no
consensus. Even if the working group chair makes a working group
"last call" on the document, and 100 people actively reply and say,
"This document is ready to go forward", if the open issue hasn't been
addressed, there's still no consensus, not even rough consensus.
It's the existence of the unaddressed open issue, not the number of
Resnick Expires May 05, 2014 [Page 13]
Internet-Draft On Consensus November 2013
people, which is determinative in judging consensus. As discussed
earlier, you can have rough consensus with issues that have been
purposely dismissed, but not ones that have been ignored.
This brings us back to when a hum could be used (cautiously) at the
end of a discussion. A discussion may be ongoing for some time, and
a particular objection seems to be holding up the decision. A
diligent chair who's been carefully listening to the discussion might
think, "I have heard person X make this objection, and I've heard
responses from many other folks that really address the issue. I
think we have rough consensus. But the objection keeps coming up.
Maybe it's just the one person getting up again and again with the
same argument, but maybe we don't have rough consensus. I'm not
sure." At this point, the chair might ask for a hum. If only a
single hum objecting can be heard, even a loud one, in the face of
everyone else humming that the objection has been answered, the chair
has pretty good reason to believe that they heard the single
objection all along and it really has been addressed. However, to
say immediately after the hum, "It sounds like we have rough
consensus" and nothing else is at best being slipshod: What the chair
really needs to say at that point is, "I believe the only objection
we've heard is A (coming from person X), and I've heard answers from
the group that fully address that issue. So, unless I hear a
different objection than the one I've just described, I find that
there is rough consensus to move on." That leaves the door open for
someone to tell the chair that the objection was really on different
grounds and they misevaluated, but it makes it clear that the chair
has found rough consensus due to the discussion, not due to the hum.
Again, it's not the hum that ends things, it's that the issues have
been addressed. If the small minority (even one person) still has an
issue that hasn't been addressed, rough consensus still hasn't been
achieved.
7. Five people for and one hundred people against might still be rough
consensus
This one is the real mind bender for most people, and certainly the
most controversial. Say there is a very small working group, one
with half a dozen truly active participants who are experts in the
field; everybody else is just following along, but not contributing
to the discussion. The active folks come up with a protocol document
that they all agree is the right way forward, and people inside and
outside the working group agree that the protocol is likely to get
widespread adoption; it is a good solution to a real problem, even if
the non-experts don't have the ability to fully judge the details.
However, one of the active members has an objection to a particular
section: The protocol currently uses a well-known algorithm to
Resnick Expires May 05, 2014 [Page 14]
Internet-Draft On Consensus November 2013
address an issue, but the objector has a very elegant algorithm to
address the issue, one which works especially well on their
particular piece of hardware. There is some discussion, and all of
the other contributors say, "Yes, that is elegant, but what we're
using now is well-understood, widely-implemented, and it works
perfectly acceptably, even on the objector's hardware. There is
always some inherent risk to go with a new, albeit more elegant,
algorithm. We should stick to the one we've got." The chair follows
the conversation and says, "It sounds like the issue has been
addressed and there's consensus to stick with the current solution."
The objector is not satisfied, maybe even saying, "But this is silly.
You've seen that my algorithm works. We should go with that." The
chair makes the judgement that the consensus is rough, in that there
is still an objector, but the issue has been addressed and the risk
argument has won the day. The chair makes a working group last call.
Now the worst case scenario happens. The objector, still unhappy
that their preferred solution was not chosen, recruits one hundred
people, maybe a few who were silent participants in the working group
already, but mostly people who work at the same company as the
objector who never participated before. The objector gets them all
to post a message to the list saying, "I believe we should go with
the new elegant algorithm in section Z instead of the current one.
It is more elegant, and works better on our hardware." The chair
sees these dozens of messages coming in and posts a query to each of
them: "We discussed this on the list, and we seemed to have consensus
that, given the inherent risk of a new algorithm, and the widespread
deployment of this current one, it's better to stick with the current
one. Do you have further information that indicates something
different?" And in reply the chair gets utter silence. These
posters to the list (say some of whom were from the company sales and
marketing department) thought that they were simply voting and have
no answer to give. At that point, it is within bounds for the chair
to say, "We have objections, but the objections have been
sufficiently answered, and the objectors seem uninterested in
participating in the discussion. Albeit rough in the extreme, there
is rough consensus to go with the current solution."
Though the above example uses the most extreme form of recruiting
sheer numbers of people (i.e., from the sales and marketing
department), the same principle should hold true no matter how new or
how credible the objectors seem: The chair is trying to discover
whether objections have been addressed or if there are still open
issues. If, instead of a bunch of sales and marketing people, the
new people to the conversation are developers or others who are
directly involved in creating the technology, or even folks who have
been participating the entire time who's knowledge of the technology
is not in question at all, the principle is still the same: If the
Resnick Expires May 05, 2014 [Page 15]
Internet-Draft On Consensus November 2013
objection has been addressed, and the new voices are not giving
informed responses to that point, they can still justifiably be
called "in the rough". Of course, the more involved and knowledgable
the objectors are, the more difficult it will be for the consensus
caller to make the call, but a call of rough consensus is reasonable.
The chair in this case needs to understand what the responses mean;
only sufficiently well-informed responses that justify the position
taken can really "count".
There is no doubt that this is the degenerate case and a clear
indication of something pathological. But this is precisely what
rough consensus is ideally suited to guard against: vote stuffing.
In the presence of an objection, the chair can use their technical
judgement to decide that the objection has been answered by the group
and that rough consensus overrides the objection. Now, the case
described here is probably the hardest call for the chair to make
(how many of us are willing to make the call that the vast majority
of people in the room are simply stonewalling, not trying to come to
consensus?), and if appealed it would be incredibly difficult for the
appeals body to sort out. Indeed, it is likely that if a working
group got this dysfunctional, it would put the whole concept of
coming to rough consensus at risk. But still, the correct outcome in
this case is to look at the very weak signal against the huge
background noise in order to find the rough consensus.
8. Conclusion
Although this document talks quite a bit about the things chairs and
working groups and other IETF participants might do to achieve rough
consensus, this document is not really about process and procedures.
It describes a way of thinking about how we make our decisions.
Sometimes, a show of hands can be useful; sometimes it can be quite
damaging and result in terrible decisions. Sometimes, using a device
like a "hum" can avoid those pitfalls; sometimes it is just a poorly
disguised vote. The point of this document is to get all of us to
think about how we are coming to decisions in the IETF, to make sure
we avoid the dangers of "majority rule" and actually get to rough
consensus decisions with the best technical outcomes.
9. Security Considerations
"He who defends with love will be secure." -- Lao Tzu
Resnick Expires May 05, 2014 [Page 16]
Internet-Draft On Consensus November 2013
10. Informative References
[Clark] Clark, D., "A Cloudy Crystal Ball - Visions of the
Future", July 1992.
In
[IETF24] Davies, M., Ed., Clark, C., Ed., and D. Legare, Ed.,
"Proceedings of the Twenty-Fourth Internet Engineering
Task Force", July 1992,
<http://www.ietf.org/proceedings/24.pdf>.
[RFC1603] Huizer, E. and D. Crocker, "IETF Working Group Guidelines
and Procedures", RFC 1603, March 1994.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
[Sheeran] Sheeran, M., "Beyond Majority Rule: Voteless Decisions in
the Religious Society of Friends", December 1983.
Appendix A. Acknowledgements
This document is the result of conversations with many IETF
participants, too many to name individually. I greatly appreciate
all of the discussions and guidance. I do want to extend special
thanks to Peter Saint-Andre, who sat me down and pushed me to start
writing, and to Melinda Shore for pointing me to Beyond Majority Rule
[Sheeran], which inspired some of the thinking in this document.
Author's Address
Pete Resnick
Qualcomm Technologies, Inc.
5775 Morehouse Drive
San Diego, CA 92121
US
Phone: +1 858 6511 4478
Email: presnick@qti.qualcomm.com
Resnick Expires May 05, 2014 [Page 17]
