RFC 7282

On Consensus and Humming in the IETF

📅 published June 2014, from ietf

RFC 7282: On Consensus and Humming in the IETF 🎀

Internet Engineering Task Force (IETF) 🌸 Request for Comments: 7282 💜

Author: P. Resnick, Qualcomm Technologies, Inc. ✨

Category: Informational 🦋 Date: June 2014 🍓 ISSN: 2070-1721 🧚

The title block doesn't list any RFCs that this one obsoletes or updates, so nothing to track there 💅

Abstract ✨

okay so the IETF has a long tradition of getting its technical work done through a consensus process 🫶 that means taking into account everyone's different views and coming to (at least rough) consensus on technical stuff. The IETF is supposed to NOT be run on a "majority rule" vibe, which is exactly why we do rituals like "humming" instead of voting 🙈 But more and more of what we do is basically indistinguishable from voting, and honestly we keep letting the majority win the day without really thinking about minority concerns 😭 This document breaks down some features of rough consensus, what is not rough consensus, how we drifted away from it, how we could think about it differently, and the stuff we can actually do 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. 🫶

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

1. Introduction ✨

Okay so almost every IETF participant knows the famous line from Dave Clark's 1992 plenary presentation [Clark] about how we make decisions in the IETF 🎀

We reject: kings, presidents and voting.

We believe in: rough consensus and running code.

Basically, 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 made in a vacuum without practical experience. Instead, we aim to make decisions by the consent of all participants, though allowing for some dissent (rough consensus), and to let the actual products of engineering (running code) beat out theoretical designs 💅

Full consensus, or unanimity, would be ideal, but we don't require it 🙈 Requiring full consensus lets one intransigent person who just keeps saying "No!" stop the whole process cold 😭 So 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 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, the chair will sometimes ask each side to hum on a particular question, either "for" or "against" 🎶

However, in recent years we've seen participants (and even some folks in IETF leadership) who don't 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 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 keep coming back to the agenda again and again 😩 More and more often, 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're 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 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 IETF consensus processes, the primary audience is those who have experience working in the IETF and are trying to understand and participate in the consensus-building process, and it's 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 anyone 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 🦋

2. Lack of disagreement is more important than agreement 💅✨

okay so picture this 🎀 a working group is deciding between format A and format B for a data structure. The chair notices a bunch of experienced people think format A is a good pick, so they ask on the mailing list, "Is everyone OK with format A?" 😬 Of course a bunch of people object for different technical reasons. So the chair pivots: "It sounds like we don't have consensus to use format A. Is everyone OK with format B?" and now even MORE people object to B, on totally different grounds 💀 The chair is left perplexed, convinced the whole group is deadlocked.

the chair's mistake? They thought they were hunting for agreement. "After all," the chair thinks, "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 is a little subtle, but it's SO important 🙈 Engineering is always a pile of tradeoffs. Whenever engineering choices need making, there will be options that appeal to some people and not to others. The move is to separate the choices that are simply unappealing from the ones that are truly problematic 🔥 If, at the end, some people didn't get the option they preferred, but they're convinced the chosen solution is acceptable (just less appealing), they've still come to consensus. Consensus doesn't mean everyone is happy and agrees it's the best one. Consensus is when everyone is sufficiently satisfied with the chosen solution that they no longer have specific objections to it 👑

so, for a working group decision, once everyone has talked through the pros and cons of the options, the most important thing is to ask not just for objections to a proposal, but for the nature of those objections 🦋 A chair who asks, "Is 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 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 group can actually examine the purported failings of the choice. The objector might convince everyone the objections are valid, and the group might choose a different path. Or the group might convince the objector that the concerns can be addressed, or that the choice is simply unappealing (something the objector can "live with") and not a show-stopper. Either way, closure is way more likely to happen quickly when you ask for and try to accommodate objections, rather than asking for agreement ✨

Sorting out disagreements isn't the ONLY thing needed for consensus, though! 🙈

an engineering solution with zero objections but also zero support, just met with complete apathy, is not a solution with any useful kind of consensus 😭 Consensus does require the active engagement and eventual support of the people working on the solution. But finding mere "agreement" among participants isn't enough. People might totally agree a solution is sufficient and have no objection to it, but if they don't actively think it's a good and correct outcome, it's absurd to declare the group has consensus. ngl that's a major vibe check 💜

now let's talk about "compromise", because the word gets used in two different ways and only one of them is good 🌈 Engineering compromises are the good kind, and they're totally expected. Engineering always involves balancing tradeoffs, so we might have to compromise processor speed for lower power consumption, or compromise throughput for congestion resistance 🍓 We always want to be weighing tradeoffs and collectively choosing the set that best meets the full set of requirements. Chef's kiss 👌

the other sense of "compromise" is compromising between people, not engineering principles, and this one can be harmful 💀 Say a minority of the group objects to a proposal, and even after discussion they still think it's deeply problematic. But they decide they don't have the energy to keep arguing and say, "Forget it, do what you want". That absolutely can be called a compromise, but a chair might mistakenly take it to mean they agree and therefore the group has reached consensus. Really, all that happened is capitulation. They gave up by trying to appease everyone else 😩 That's not consensus! There's still an outstanding, unaddressed objection. Again, if the objection is only that the choice isn't ideal but is otherwise acceptable, that kind of compromise is totally fine 🧚 But conceding when there's a real, outstanding technical objection is not coming to consensus.

even worse is the "horse-trading" kind 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 both in." 🙃 That also results in an "agreement" of sorts, but instead of one outstanding unaddressed issue, this kind of compromise leaves two, just ignored for the sake of expedience 🎀

these "capitulation" and "horse-trading" compromises have no place in consensus decision making 🚫 A chair who looks for "agreement" might find it in these examples, because it appears people have agreed. But answering technical disagreements is what's needed to achieve consensus, sometimes even when the people who raised the disagreements no longer want to discuss them 💖

so what does coming to consensus actually look like? It's when everyone, including the person who made the objection, concludes one of two things: either the objections are valid and a change gets made to address them, or the objection wasn't really important and was merely a matter of taste 🌸 Of course, full consensus like that doesn't 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 ✨

okay so the last bit was about how the working group figures out a point together 🫶 Either the objector is happy with the answer, or the group decides the objection is valid and changes course. But that doesn't happen every time, and honestly it's not even the tricky case. Engineering is always about tradeoffs 💅 Sometimes a working group hits an objection where everyone gets it, everyone agrees it's a real flaw in the proposal, and the vast majority still thinks fixing it isn't worth the tradeoff 🌸

Picture this: an objector goes, "Protocol X is way more complicated than Protocol Y. Y is so much more elegant and clean, I can code it way more easily, and X is a hack." 🙈 The group thinks about it, and someone replies, "We already have a ton of code that looks like Protocol X. Y is prettier, I'll give you that, but the risk to interoperability with something untested isn't worth it compared to going with the well-understood X." 💜 If the chair decides, using their technical judgement, that the issue has really been considered and that the vast majority of the group thinks the tradeoff is worth it, the chair can say the group has reached rough consensus. Even if the person who raised the issue keeps objecting ✨ (And even though this is described as a "vast majority", even that isn't necessarily true. Sections 6 and 7 get into this more. 🧚)

Here's the thing: rough consensus is meant to be the backup plan 🎀 While a working group is doing its work, it acts like it's going for full consensus. It tries to address every issue so everyone in the group is happy, including the people who started out objecting 😭 Rough consensus is more like "exception processing" for when someone still feels strongly that their objection is valid and has to be accommodated. That said, it's true that in the IETF, someone in the group is usually unhappy with a decision. So honestly rough consensus can feel more like the norm than the exception 💀 But when someone says, "That's not my favorite solution, but I can live with it. I'm satisfied we made a reasonable choice," that person isn't part of the "rough" bit. If they're satisfied with the outcome, the group actually reached consensus ✨ The consensus is only rough when the chair has to say that an unsatisfied person still has an open issue, but the group has genuinely answered the objection. 🦋

Now, a rough consensus call depends a LOT on the consensus caller's good judgement 👑 The group has to really consider and weigh an issue before it can be waved off as being "in the rough". ("In the rough" is a golf term. "The rough" is the long grass along the side of the fairway. If your ball lands there, you're off course and away from the normal direction of play. The IETF uses the phrase as a pun on "rough consensus", meaning you're "in the rough" if you don't agree with the rough consensus. 🌈) A chair who's about to call rough consensus has to decide three things: the group took the objection seriously, the group fully looked at what happens if they don't make the change, and the outcome doesn't count as failing the technical requirements of the work. To make that call, the chair needs a good sense of what the work is for and how it's built, maybe by checking the working group charter or a requirements document that's already been published, or even asking other experts on the topic. Then the chair uses their own technical judgement to check that the solution meets those requirements 🔥 The chair could get it wrong, and the chair's decision can always be appealed if that happens, but the chair has to actually use their judgement here. What can't happen is the chair deciding based only on hearing lots of people say, "The objection isn't valid." That's just taking a vote, and a valid justification still needs to be made. 💅

This is a change from how rough consensus has sometimes been described in the IETF 🍓 RFC 1603 [RFC1603] called rough consensus the "dominant view" of the group:

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

That text says consensus can be "determined" by balloting and humming, and yep, some IETF folks have thought of rough consensus as mostly about what percentage of people agree with a decision 🙈 RFC 2418 [RFC2418] builds on the text above and says, "Note that 51% of the working group does not qualify as 'rough consensus' and 99% is better than rough." 😭 This document disagrees that balloting or looking at percentages can actually "determine" consensus. Counting heads might give a decent guess at what the rough consensus will be, but it can also let important minority views get lost in the noise 💔 One of the best things about a consensus model is that minority views get addressed, and using rough consensus shouldn't take that away. That's why this document spends so much time on looking at open issues instead of just counting who supports or opposes something. That approach has some interesting and surprising results, which the later sections dig into. ✨

Any rough consensus finding has to give the person(s) who raised the issue a reasoned explanation of why their concern isn't going to be accommodated 🫶 The ideal outcome is that the objector understands the decision, accepts it, and moves on, even though their particular issue didn't make it into the final product 🌸

And remember, if the objector thinks the issue is so essential that it has to be dealt with, they can always file an appeal 📣 A technical error is always a valid basis for an appeal. The chair making the consensus call (or whoever hears the appeal) can decide 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 that's the case 💀 A big majority agreeing to dismiss an objection is not enough to claim rough consensus. The group has to have honestly considered the objection and decided that other issues outweighed it. If there's no real reasoning and evaluation, there's no true consensus 😤

4. Humming should be the start of a conversation, not the end ✨

Okay bestie, first things first: we don't vote in the IETF 🙅‍♀️. In some ways we literally can't, because the IETF isn't a membership organization, so it's nearly impossible to figure out who would even get a vote on any question. We can't know who the "members" of a working group are at any given moment, and we definitely can't know who all the "members" of the whole IETF would be. That's why we say "participants" instead, since the IETF doesn't really have "members" 🦋. We also often recruit extra implementers and other experts into working groups so that broader views make it into the chat, so voting just isn't practical 💅.

We've decided that coming to consensus (sometimes rough consensus, but still) is the goal 🫶. Final decisions are supposed to happen on the mailing list, which reinforces that we get to consensus by looking at the open issues, not counting heads 🙈. We do sometimes take informal polls to see which way the discussion is leaning, but we try really hard not to treat a poll as a vote that decides things. When we meet face-to-face, we don't want to vote there either. We want to show that we're coming to consensus ✨. So instead of a show of hands, we often "hum" 🎀 to remind everyone that nobody's voting.

However, more and more people think a hum is a sort of anonymous vote 😭. Some chairs call every question for the working group by asking for a hum, then judge the result by the loudest hum. Iykyk, it sounds 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." That totally misses the point of humming, and it's almost certainly a misassessment of the consensus 💀. Hums should not be used as votes.

So, why do we even do 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. To find a starting place for the conversation, it can be useful for the chair to ask for a hum and see whether 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 shows that the room isn't all that contentious after all, and it was just a few voices being especially vociferous during the initial discussion.

Sometimes the hum makes it clear that choice "foo" has significantly more support than choice "bar", so it's probably easier to start the discussion with something like, "OK, 'foo' seems to have quite a bit of support. Let's have the people who think 'foo' is a bad idea come up and tell us why it's problematic." 🧚 Then the group can go through the issues and see whether any of them are showstoppers. It could turn out that one objection is instantly recognized by the whole group as a fatal flaw in "foo", and then the group turns to the merits (and demerits) of "bar" instead. All the hum does is give the chair a starting point. The hum indicated there were fewer 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 to hum is that it gives the chair a chance 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 mean some people believe there are serious problems with choice B, even though it's 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 fewest objections fastest 🏃‍♀️. A bunch of people who aren't strongly committed to B might have no real technical objection to A, even though it isn't their first preference.

There's always a chance this could be misleading, or even abused, because some people are more willing to hum loudly than others (just by dint of personality). Or one of the quieter hums might turn out to be a show-stopper that makes the original choice impossible 😬. But keep in mind that taking the hum in this case is about figuring out how to start the conversation. The chair could 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 have been done with a show of hands instead of a hum? Absolutely 💁‍♀️. On a mailing list there's no way to hum, so a different kind of polling would be needed. Even face-to-face, we sometimes do use a show of hands. But there are more symbolic reasons to use a hum instead of a show of hands when we're face-to-face 🦋. A chair could get the temperature of the room with a show of hands too, and knowing who specifically feels one way or another can help a good chair guide the rest of the 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 totally do a show of hands and get 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 happening 😭. A chair can always take the hum and then later ask specific folks to identify themselves to get more discussion going. The advantage of the hum is that it makes it perfectly clear the chair is just figuring out the direction of the conversation 💖.

This also points to another misuse of any kind of informal polling 🙅‍♀️. If the chair is already convinced the group has reached consensus, there isn't much reason to take a poll. In fact, taking a poll can discourage people in the minority from voicing their concerns in the face of a large majority that wants to move forward. Often, the right thing for the chair to do when they already sense consensus is to say, "It sounds to me like we have consensus for choice A. Does anybody have any concerns about or objections to going with A?" 🫶 That lets folks bring up issues the chair might have mistakenly missed, without feeling like the majority has "already spoken".

The reverse situation has similar advantages and disadvantages 🔄. Sometimes a chair (say, of a birds-of-a-feather session, or a working group discussing a new proposed document) wants to make sure there's a good base of support to go forward with a proposal, so they take a hum. This can show the chair whether there are more than a handful of active people who are really interested in the new work. But this has pitfalls too 🙈. Someone may be dissuaded from raising what could be an essential concern if they feel the group is overwhelmingly in favor of going forward. Or some folks may decide to "hum along with the crowd" even though they aren't committed to the outcome. The formulation, or even the order, of the 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 for the same question asked after some more "negatively" framed questions. Any sort of polling, whether hums or even a show of hands, must be done with caution and should almost always be used to prompt discussion and questions, not to conclude the matter 🛑.

Sometimes 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 we've honestly had working groups where a coin flip decided which proposal to start with 🪙. That doesn't mean the coin flip determined the outcome. If a fatal technical flaw is found in the solution that won the coin flip, it's still on the group to address the issue raised or abandon that solution and find another 💅. Rough consensus on the technical points is, in the end, always required 👑. Any way of finding a place to start, whether it's the hum or the coin flip, only gets us to the beginning of the discussion, not the end 🌈.

5. Consensus is the path, not the destination ✨

okay bestie, big reminder: we do NOT chase consensus just to say we have it 💅 consensus is the tool we use to get the best technical (and sometimes procedural) outcome when we make decisions 🔥 the vibe is that traditional voting leads to gaming the system 🙈, "compromises" of the wrong sort (we talked about those earlier 💀), important minority views getting ignored 😭, and in the end, way worse technical outcomes. not iconic at all.

coming to consensus by looking for objections, tracking open issues, and using hums as the start of a discussion instead of the end can take some patience 🧚 ngl, objection-based or issue-based decision making can be SO hard sometimes, because there can be big factions with totally opposite views. and yeah, we do see some political compromise (the undesirable kind 🙃) from time to time in the IETF. it's not perfect, and we know it 💜

but accepting all this has a price 💸 when we decide a discussion is too factious and just go with the majority, it creates more polarized arguments later. instead of working toward the best technical outcome that basically everyone can accept, people run to opposite sides and dig in their heels 😤 and when real technical issues get dropped because proponents just gave up, or "horse-traded" so other technical problems could stick around, the end product is weaker 🥀 the IETF can never be perfectly principled about rough consensus, but if we're not vigilant about sticking to the principles, it gets harder and harder to stick to them in the future, and we end up with worse technical output. big yikes 🌧️

again, consensus is not the goal in itself ✨ coming to consensus is what we do during our processes to land on the best solution. especially, "declaring" consensus is NOT an end goal 🚫 (sorry for the caps, I'm passionate 😭) attempts to declare consensus at the end of a discussion just so we can say "there is consensus" usually drag us right back into the voting mentality we're trying to escape 🍓

now, chairs say they're making a "consensus call" all the time 🎀 sometimes they just mean they're making a call of the consensus, which is declaring the consensus they think has been reached once the discussion wraps up. honestly that's a totally fine thing, and it's what chairs are supposed to do 👑 they're "calling" the consensus! other times, when a chair says "consensus call," they're actually making a call for discussion about one specific point, so the group can focus and reach consensus. it's a little weird to call that a "consensus call" (a "call for discussion" would be way more accurate 🤷‍♀️), but it's fine for a chair to pick out one point of contention and get everyone talking about it 🦋

BUT more and more often, chairs say "consensus call" at the very end of a discussion and then 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 it has the same 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 issue, because it implies you can confirm consensus by counting people instead of issues 💀 the important thing is for a chair to "call consensus" in the sense of declaring it. others can always object, say the chair got it wrong, and ask for reconsideration 🫶 but the chair ought to be looking for consensus throughout the whole discussion, not just asking for it at the end ✨

sometimes chairs will ask a question or take a poll toward the end of a discussion to figure out where consensus stands, but this must be done with EXTREME caution 🚨 (we'll get into this in the next section 💖)

6. One hundred people for and five people against might not be rough consensus 💀

okay, Section 3 covered how consensus is achieved when objections have been addressed (properly considered, and accommodated if necessary) 🧚 and this is why rough consensus dodges a major pitfall of a straight vote: if a minority has a valid technical objection, that objection must be dealt with before consensus can be declared 🔥 this also shows one of the great strengths of consensus over voting, which is that vote stuffing isn't a thing here. vote stuffing is when you recruit a huge number of people to back one side, even people who have never participated in a working group or the IETF at all 😤 it can't 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 result 👑

so picture a big working group with over 100 active participants and broad agreement to move 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 gets met with silence on the mailing list... there is no consensus 💀 even if the chair makes a working group "last call" on the document and 100 people actively reply "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 people, that decides consensus. as we covered earlier, you can have rough consensus with issues that have been purposely dismissed, but NOT with issues that have been ignored 🫠

this brings us back to when a poll could be used (cautiously!) at the end of a discussion 🎀 say a discussion has been going on for a while and one objection seems to be holding up the decision. a diligent chair who's been carefully listening might think, "I've 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 objecting hum 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 they heard that one objection all along and it really has been addressed 💖

BUT saying "It sounds like we have rough consensus" right after the hum and nothing else is, at best, being slipshod 😬 what the chair really needs to say is something like: "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 the objection was really on different grounds and they misevaluated, AND it makes clear the chair found rough consensus because of the discussion, NOT because of the hum 🫶 again, it's not the hum that ends things. it's that the issues have been addressed. if a small minority (even just one person) still has an issue that hasn't been addressed, rough consensus still hasn't been achieved 🙅‍♀️

even if no particular person is still standing up for an issue, that doesn't mean the issue can be ignored 🚫 as discussed earlier, simple capitulation on an issue is not coming to consensus 🥀 and even if someone who isn't an active participant (someone who might not care much about the fate of the work) raises a substantive issue and then disappears, the issue still needs to be addressed before the chair can claim rough consensus exists 🌸

7. Five people for and one hundred people against might still be rough consensus 💅

Okay bestie, this is the real mind-bender 🤯 and honestly the most controversial one. Picture a super small working group with six truly active participants who are experts in the field. Everyone else is just following along and not really contributing. The active folks write a protocol document they all agree is the right way forward, and people inside and outside the group agree it's likely to get widespread adoption. It's a good solution to a real problem, even if the non-experts can't fully judge the details ✨

Then one of the active members objects to a particular section. The protocol currently uses a well-known algorithm for an issue, but the objector has a very elegant algorithm that works especially well on their particular piece of hardware. There's some discussion, and everyone else says, "Yes, that is elegant, but what we're using now is well-understood, widely implemented, and 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 along and says, "It sounds like the issue has been addressed and there's consensus to stick with the current solution." The objector isn't satisfied and maybe even says, "But this is silly. You've seen that my algorithm works. We should go with that." The chair decides the consensus is rough, since there's still an objector, but the issue was addressed and the risk argument won the day. The chair makes a working group last call 🎀

Then the worst-case scenario happens 😭 The objector, still salty that their pick didn't win, recruits one hundred people. A few might be silent participants already, but mostly they're people from the objector's company who never participated before. The objector gets them all to post 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 dozens of messages roll in and posts a query to each one: "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 the chair gets... utter silence 💀 These posters, some of whom were from the company's sales and marketing department, thought they were just voting and have no answer to give. At that point, it's 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 example above uses the most extreme form of recruiting sheer numbers of people (i.e., from the sales and marketing department), the same principle holds no matter how new or how credible the objectors seem. The chair is trying to figure out whether objections have been addressed or if there are still open issues. If the new people are developers or others directly involved in creating the technology, or even folks who've been participating the whole time whose knowledge isn't in question at all, the principle is still the same. If the objection has been addressed and the new voices aren't giving informed responses to that point, they can still justifiably be called "in the rough". Of course, the more involved and knowledgeable the objectors are, the harder it is 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's no doubt this is the degenerate case and a clear sign of something pathological. But this is exactly what rough consensus is ideally suited to guard against: vote stuffing 🙅 When there's an objection, the chair can use their technical judgement to decide that the group has answered it and that rough consensus overrides it. Now, this is probably the hardest call a chair can make. How many of us are willing to decide that the vast majority of people in the room are just stonewalling and not trying to reach consensus? If it's appealed, it would be incredibly difficult for the appeals body to sort out. Honestly, if a working group got this dysfunctional, it would put the whole concept of rough consensus at risk. But the correct outcome here is still to look at the very weak signal against the huge background noise and find the rough consensus 🔍

8. Conclusion 👑

Although this document talks a lot about the things chairs, working groups, and other IETF participants might do to reach rough consensus, it's not really about process and procedures. It describes a way of thinking about how we make our decisions. Sometimes a show of hands is useful, and sometimes it's really damaging and leads to terrible decisions. Sometimes a device like a "hum" can avoid those pitfalls, and sometimes it's just a poorly disguised vote. The point is to get all of us thinking about how we come to decisions in the IETF, so we avoid the dangers of "majority rule" and actually reach rough consensus decisions with the best technical outcomes 💖

9. Security Considerations 🫶

"He who defends with love will be secure." -- Lao Tzu

10. Informative References 📚

  • [Clark] Clark, D., "A Cloudy Crystal Ball - Visions of the Future", Proceedings of the Twenty-Fourth Internet Engineering Task Force, pages 539-543, 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", ISBN 978-0941308045, December 1983.

Appendix A. Acknowledgements 🌸

This document came out of conversations with so many IETF participants that I couldn't possibly name them all, and I'm so grateful for every discussion and every bit of guidance 🥹 I especially want to thank Peter Saint-Andre, who sat me down and pushed me to start writing, and Melinda Shore, who pointed me to "Beyond Majority Rule" [Sheeran]. That book 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 651 4478
EMail: presnick@qti.qualcomm.com
📦 where this page comes from