idnits 2.17.1 draft-resnick-on-consensus-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 15, 2014) is 3656 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1603 (Obsoleted by RFC 2418) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Resnick 3 Internet-Draft Qualcomm Technologies, Inc. 4 Intended status: Informational April 15, 2014 5 Expires: October 17, 2014 7 On Consensus and Humming in the IETF 8 draft-resnick-on-consensus-07 10 Abstract 12 The IETF has had a long tradition of doing its technical work through 13 a consensus process, taking into account the different views among 14 IETF participants and coming to (at least rough) consensus on 15 technical matters. In particular, the IETF is supposed not to be run 16 by a "majority rule" philosophy. This is why we engage in rituals 17 like "humming" instead of voting. However, more and more of our 18 actions are now indistinguishable from voting, and quite often we are 19 letting the majority win the day without consideration of minority 20 concerns. This document explains some features of rough consensus, 21 what is not rough consensus, how we have gotten away from it, how we 22 might think about it differently, and the things we can do in order 23 to really achieve rough consensus. 25 Note: This document is quite consciously being put forward as 26 Informational. It does not propose to change any IETF processes 27 and is therefore not a BCP. It is simply a collection of 28 principles, hopefully around which the IETF can come to (at least 29 rough) consensus. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on October 17, 2014. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Lack of disagreement is more important than agreement . . . . 4 67 3. Rough consensus is achieved when all issues are addressed, 68 but not necessarily accommodated . . . . . . . . . . . . . . 6 69 4. Humming should be the start of a conversation, not the end . 9 70 5. Consensus is the path, not the destination . . . . . . . . . 12 71 6. One hundred people for and five people against might not be 72 rough consensus . . . . . . . . . . . . . . . . . . . . . . . 14 73 7. Five people for and one hundred people against might still be 74 rough consensus . . . . . . . . . . . . . . . . . . . . . . . 15 75 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 10. Informative References . . . . . . . . . . . . . . . . . . . 17 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 81 1. Introduction 83 Almost every IETF participant knows the aphorism from Dave Clark's 84 1992 plenary presentation [Clark] regarding how we make decisions in 85 the IETF: 87 We reject: kings, presidents and voting. 89 We believe in: rough consensus and running code. 91 That is, our credo is that we don't let a single individual dictate 92 decisions (a king or president), nor should decisions be made by a 93 vote, nor do we want decisions to be made in a vacuum without 94 practical experience. Instead, we strive to make our decisions by 95 the consent of all participants, though allowing for some dissent 96 (rough consensus), and to have the actual products of engineering 97 trump theoretical designs (running code). 99 Having full consensus, or unanimity, would be ideal, but we don't 100 require it: Requiring full consensus allows a single intransigent 101 person who simply keeps saying "No!" to stop the process cold. We 102 only require rough consensus: If the chair of a working group 103 determines that a technical issue brought forward by an objector has 104 been truly considered by the working group, and the working group has 105 made an informed decision that the objection has been answered or is 106 not enough of a technical problem to prevent moving forward, the 107 chair can declare that there is rough consensus to go forward, the 108 objection notwithstanding. 110 To reinforce that we do not vote, we have also adopted the tradition 111 of "humming": When, for example, we have face-to-face meetings and 112 the chair of the working group wants to get a "sense of the room", 113 instead of a show of hands, sometimes the chair will ask for each 114 side to hum for or against a question. 116 However, in recent years we have seen participants (and even some 117 folks in IETF leadership) who do not understand some of the 118 subtleties of consensus-based decision making. Participants ask, 119 "Why don't we just vote? Why are we bothering with this 'humming' 120 thing?" Or even more concerning, "We've already hummed/voted, so why 121 isn't the discussion concluded?" Chairs, many of whom have little 122 experience in leading large volunteer groups like those in the IETF, 123 let alone experience in how to gather consensus, are faced with 124 factious working groups with polarized viewpoints and long-running 125 unresolved issues that return again and again to the agenda. More 126 and more frequently, people walk away from working groups, thinking 127 that "consensus" has created a document with horrible compromises to 128 satisfy everyone's pet peeve instead of doing "the right thing". 129 None of these things are indicators of a rough consensus process 130 being used, and are likely due to some basic misperceptions. 132 This document explains some features of rough consensus, explains 133 what is not rough consensus, discusses some new ways to think about 134 rough consensus, and suggests ways that we might achieve rough 135 consensus and judge it in the IETF. Though this document describes 136 some behaviors of working groups and chairs, it does so in broad 137 brushstrokes and it does not prescribe specific procedures. Rather, 138 this document is intended to foster understanding of the underlying 139 principles of IETF consensus processes. While it may be of general 140 interest to anyone interested in the IETF consensus processes, the 141 primary audience for this document is those who have experience 142 working in the IETF and are trying to understand and participate in 143 the consensus-building process, and it is particularly aimed at 144 generating thought and discussion among those who might lead a 145 consensus discussion. Although most of the examples in this document 146 talk about working group chairs, these principles apply to any person 147 who is trying to lead a group to rough consensus, whether a chair, a 148 design team leader, a document editor, an IESG area director, or any 149 community member who is facilitating a discussion or trying to assess 150 consensus. 152 While the community has come to rough consensus that the principles 153 expressed in this document are (at least approximately) right, many 154 of our current practices are not consistent with these principles. 155 Again, this document is primarily intended to generate thought and 156 discussion, not dictate practices. If the IETF does commit itself to 157 these principles, practices may change in the future. 159 2. Lack of disagreement is more important than agreement 161 A working group comes to a technical question of whether to use 162 format A or format B for a particular data structure. The chair 163 notices that a number of experienced people think format A is a good 164 choice. The chair asks on the mailing list, "Is everyone OK with 165 format A?" Inevitably, a number of people object to format A for one 166 or another technical reason. The chair then says, "It sounds like we 167 don't have consensus to use format A. Is everyone OK with format B?" 168 This time even more people object to format B, on different technical 169 grounds. The chair, not having agreement on either format A or 170 format B, is left perplexed, thinking the working group has 171 deadlocked. 173 The problem that the chair got themselves into in the above case was 174 thinking that what they were searching for was agreement. "After 175 all", thinks the chair, "consensus is a matter of getting everyone to 176 agree, so asking whether everyone agrees is what the chair ought to 177 do. And if lots of people disagree, there's no consensus." But 178 _determining_ consensus and _coming to_ consensus are different 179 things than _having_ consensus. 181 The distinction might be a bit subtle, but it's important. 182 Engineering always involves a set of tradeoffs. It is almost certain 183 that any time engineering choices need to be made, there will be 184 options that appeal to some people that are not appealing to some 185 others. In determining consensus, the key is to separate those 186 choices that are simply unappealing from those that are truly 187 problematic. If at the end of the discussion some people have not 188 gotten the choice that they prefer, but they have become convinced 189 that the chosen solution is acceptable, albeit less appealing, they 190 have still come to consensus. Consensus doesn't require that 191 everyone is happy and agrees that the chosen solution is the best 192 one. Consensus is when everyone is sufficiently satisfied with the 193 chosen solution, such that they no longer have specific objections to 194 it. 196 So in the case of a working group decision, after the initial 197 discussion of the pros and cons of the available choices, it is most 198 important to ask not just for objections to a particular proposal, 199 but for the nature of those objections. A chair who asks, "Is 200 everyone OK with choice A?" is going to get objections. But a chair 201 who asks, "Can anyone not live with choice A?" is more likely to only 202 hear from folks who think that choice A is impossible to engineer 203 given some constraints. Following up with, "What are the reasons you 204 object to choice A?" is also essential. Then the purported failings 205 of the choice can be examined by the working group. The objector 206 might convince the rest of the group that the objections are valid 207 and the working group might choose a different path. Conversely, the 208 working group might convince the objector that the concerns can be 209 addressed, or that the choice is simply unappealing (i.e., something 210 the objector can "live with") and not a show-stopper. In any event, 211 closure is much more likely to be achieved quickly by asking for and 212 trying to accommodate the objections rather than asking for 213 agreement. 215 None of the above discussion should be taken as meaning that sorting 216 out disagreements is the only thing that needs to be done for 217 successful consensus. An engineering solution that has no 218 objections, but also has no base of support and is met with complete 219 apathy, is not a solution that has any useful sort of consensus. 220 Consensus does require the active engagement and eventual support of 221 those who are working on the solution. However, finding mere 222 "agreement" among participants is not enough. People might very well 223 agree that a solution is sufficient and have no objection to it, but 224 if they also don't actively think it's a good and correct outcome, 225 it's absurd to declare that the group has consensus. 227 There is also an important point to be made about reaching consensus 228 and "compromising": Unfortunately, the word "compromise" gets used in 229 two different ways, and though one sort of compromising to come to 230 consensus is good (and important), the other sort of compromising in 231 order to achieve consensus can actually be harmful. As mentioned 232 earlier, engineering always involves balancing tradeoffs, and 233 figuring out whether one engineering decision makes more sense on 234 balance compared to another involves making engineering 235 "compromises": We might have to compromise processor speed for lower 236 power consumption, or compromise throughput for congestion 237 resistance. Those sorts of compromises are among engineering 238 choices, and they are expected and essential. We always want to be 239 weighing tradeoffs and collectively choosing the set that best meets 240 the full set of requirements. 242 However, there is another sense of "compromise" that involves 243 compromising between people, not engineering principles. For 244 example, a minority of a group might object to a particular proposal, 245 and even after discussion still think the proposal is deeply 246 problematic, but decide that they don't have the energy to argue for 247 it and say, "Forget it, do what you want". That surely can be called 248 a compromise, but a chair might mistakenly take this to mean that 249 they agree, and have therefore come to consensus. But really all 250 that they've done is capitulated; they've simply given up by trying 251 to appease the others. That's not coming to consensus; there still 252 exists an outstanding unaddressed objection. Again, if the objection 253 is only that the choice is not ideal but is otherwise acceptable, 254 such a compromise is fine. But conceding when there is a real 255 outstanding technical objection is not coming to consensus. 257 Even worse is the "horse-trading" sort of compromise: "I object to 258 your proposal for such-and-so reasons. You object to my proposal for 259 this-and-that reason. Neither of us agree. If you stop objecting to 260 my proposal, I'll stop objecting to your proposal and we'll put them 261 both in." That again results in an "agreement" of sorts, but instead 262 of just one outstanding unaddressed issue, this sort of compromise 263 results in two, again ignoring them for the sake of expedience. 265 These sorts of "capitulation" or "horse-trading" compromises have no 266 place in consensus decision making. In each case, a chair who looks 267 for "agreement" might find it in these examples because it appears 268 that people have "agreed". But answering technical disagreements is 269 what is needed to achieve consensus, sometimes even when the people 270 who stated the disagreements no longer wish to discuss them. 272 Coming to consensus is when everyone (including the person making the 273 objection) comes to the conclusion that either the objections are 274 valid, and therefore make a change to address the objection, or that 275 the objection was not really a matter of importance, but merely a 276 matter of taste. Of course, coming to full consensus like that does 277 not always happen. That's why in the IETF, we talk about "rough 278 consensus". 280 3. Rough consensus is achieved when all issues are addressed, but not 281 necessarily accommodated 283 The preceding discussion gives an example where the working group 284 comes to consensus on a point: Either the objector is satisfied with 285 the answer to the objection, or the working group is satisfied that 286 the objection is valid and changes course. But that doesn't happen 287 all of the time, and it's certainly not the problematic case. Again, 288 engineering is always a set of tradeoffs. Often, a working group 289 will encounter an objection where everyone understands the issue and 290 acknowledges that it is a real shortcoming in the proposed solution, 291 but the vast majority of the working group believes that 292 accommodating the objection is not worth the tradeoff of fixing the 293 problem. 295 So, an objector might say, "The proposal to go with protocol X is 296 much more complicated than going with protocol Y. Protocol Y is a 297 much more elegant and clean solution, which I can code much more 298 easily, and protocol X is a hack." The working group might consider 299 this input, and someone might respond, "But we have a great deal of 300 code already written that is similar to protocol X. While I agree 301 that protocol Y is more elegant, the risks to interoperability with 302 an untested solution is not worth it compared to the advantages of 303 going with the well-understood protocol X." If the chair finds, in 304 their technical judgement, that the issue has truly been considered, 305 and that the vast majority of the working group has come to the 306 conclusion that the tradeoff is worth making, even in the face of 307 continued objection from the person(s) who raised the issue, the 308 chair can declare that the group has come to rough consensus. (And 309 even though this is framed in terms of a "vast majority", even that 310 is not necessarily true. This point is discussed in more detail in 311 Section 6 and Section 7.) 313 Note that this portrays rough consensus as a fallback. In one sense, 314 it is: As a working group does its work and makes its choices, it 315 behaves as if it is striving toward full consensus and tries to get 316 all issues addressed to the satisfaction of everyone in the group, 317 even those who originally held objections. It treats rough consensus 318 as a sort of "exception processing", to deal with cases where the 319 person objecting still feels strongly that their objection is valid 320 and must be accommodated. But it is certainly true that more often 321 than not in the IETF, at least someone in the group will be 322 unsatisfied with a particular decision. In that sense, rough 323 consensus might be closer to the norm than the exception. However, 324 when a participant says, "That's not my favorite solution, but I can 325 live with it; I'm satisfied that we've made a reasonable choice", 326 that participant is not in the "rough" part of a rough consensus; the 327 group actually reached consensus if that person is satisfied with the 328 outcome. It's when the chair has to declare that an unsatisfied 329 person still has an open issue, but that the group has truly answered 330 the objection, that the consensus is only rough. 332 Now, a conclusion of having only rough consensus relies heavily on 333 the good judgement of the consensus caller. The group must truly 334 consider and weigh an issue before the objection can be dismissed as 335 being "in the rough". ("In the rough" is terminology from golf. 336 "The rough" is the term for the longer grass at the side of the 337 fairway, and if your ball has landed in the rough you are off course 338 and away from the normal direction of play. The phrase gets used 339 quite a bit in the IETF as a play on words to complement "rough 340 consensus" meaning that you are "in the rough" if you find yourself 341 not agreeing with the rough consensus.) The chair of the working 342 group in one of these cases is going to have to decide that not only 343 has the working group taken the objection seriously, but that it has 344 fully examined the ramifications of not making a change to 345 accommodate it, and that the outcome does not constitute a failure to 346 meet the technical requirements of the work. In order to do this, 347 the chair will need to have a good idea of the purpose and 348 architecture of the work being done, perhaps referring to the charter 349 of the working group or a previously published requirements document, 350 or even consulting with other experts on the topic, and then the 351 chair will use their own technical judgement to make sure that the 352 solution meets those requirements. It is possible that the chair can 353 come to the wrong conclusion, and the chair's conclusion is always 354 appealable should that occur, but the chair must use their judgement 355 in these cases. What can't happen is that the chair bases their 356 decision solely on hearing a large number of voices simply saying, 357 "The objection isn't valid." That would simply be to take a vote. A 358 valid justification needs to me made. 360 It is important to recognize that this view of rough consensus is a 361 change from the way it sometimes has been characterized in the IETF. 362 RFC 1603 [RFC1603] described rough consensus as the "dominant view" 363 of the group: 365 Working groups make decisions through a "rough consensus" process. 366 IETF consensus does not require that all participants agree 367 although this is, of course, preferred. In general the dominant 368 view of the working group shall prevail. (However, it must be 369 noted that "dominance" is not to be determined on the basis of 370 volume or persistence, but rather a more general sense of 371 agreement.) Consensus can be determined by balloting, humming, or 372 any other means on which the WG agrees (by rough consensus, of 373 course). 375 The above says that consensus can be "determined" by balloting and 376 humming, and there are certainly IETF folks who have thought of rough 377 consensus as being primarily about the percentage of people who agree 378 with a decision. Indeed, RFC 2418 [RFC2418] adds on to the above 379 text by saying, "Note that 51% of the working group does not qualify 380 as 'rough consensus' and 99% is better than rough." This document 381 actually disagrees with the idea that simply balloting or otherwise 382 looking at percentages can "determine" consensus. While counting 383 heads might give a good guess as to what the rough consensus will be, 384 doing so can allow important minority views to get lost in the noise. 385 One of the strengths of a consensus model is that minority views are 386 addressed, and using a rough consensus model should not take away 387 from that. That is why this document talks a great deal about 388 looking at open issues rather than just counting the number of people 389 who do or do not support any given issue. Doing so has some 390 interesting and surprising implications that are discussed in 391 subsequent sections. 393 Any finding of rough consensus needs, at some level, to provide a 394 reasoned explanation to the person(s) raising the issue of why their 395 concern is not going to be accommodated. A good outcome is for the 396 objector to understand the decision taken and accept the outcome, 397 even though their particular issue is not being accommodated in the 398 final product. 400 Remember, if the objector feels that the issue is so essential that 401 it must be attended to, they always have the option to file an 402 appeal. A technical error is always a valid basis for an appeal. 403 The chair in making the consensus call (or whoever is responsible to 404 hear an appeal) may determine that the issue was addressed and 405 understood, but they also have the freedom and the responsibility to 406 say, "The group did not take this technical issue into proper 407 account" when appropriate. Simply having a large majority of people 408 agreeing to dismiss an objection is not enough to claim there is 409 rough consensus; the group must have honestly considered the 410 objection and evaluated that other issues weighed sufficiently 411 against it. Failure to do that reasoning and evaluating means that 412 there is no true consensus. 414 4. Humming should be the start of a conversation, not the end 416 We don't vote in the IETF. In some ways, we can't vote: Since the 417 IETF is not a membership organization, it's nearly impossible to 418 figure out who would get a vote for any given question. We can't 419 know who the "members" of any given working group would be at any one 420 time, and we certainly can't know who all of the "members" of the 421 IETF would be: That's why we refer to "participants" in the IETF; the 422 IETF doesn't really have "members". Indeed, we often recruit 423 additional implementers and other experts into working groups in 424 order to ensure that broader views are brought into the discussion. 425 So voting is simply not practical. We've also decided that coming to 426 consensus (albeit sometimes rough consensus) is an important thing to 427 do. Final decisions are supposed to be taken on the mailing list, 428 which reinforces the idea that we come to consensus by looking at the 429 open issues and not counting heads. We do on occasion take informal 430 polls to get a sense of the direction of the discussion, but we try 431 not to treat a poll as a vote that decides the issue. When we do 432 discuss things face-to-face, we don't want to vote there either; we 433 want to show that we are coming to consensus. So sometimes, to 434 reinforce the notion that we're not voting, instead of a show of 435 hands, we often "hum". 437 However, more and more we see people who think that a hum is a sort 438 of anonymous vote, with some chairs calling every question they have 439 for the working group by asking for a hum and judging the result by 440 the loudest hum, even saying things like, "There were lots of hums 441 for choice 1 and very few hums for choice 2, so it sounds like we 442 have rough consensus for choice 1." This misses some really 443 important points of using humming and is almost certainly mis- 444 assessing the consensus. Hums should not be used as votes. 446 So, why should we engage in this strange practice of humming? What 447 are good reasons to "take a hum"? One reason is pragmatic. Quite 448 often, a chair is faced with a room full of people who seem to be 449 diametrically opposed on some choice facing the group. In order to 450 find a starting place for the conversation, it can be useful for the 451 chair to ask for a hum to see if one of the choices already has a 452 stronger base of support than the other (or any significant base of 453 support at all, for that matter). Sometimes the hum can tell a chair 454 that the room isn't all that contentious after all, that it's just a 455 few voices who were being especially vociferous during the initial 456 discussion. 458 Sometimes, the hum will make it clear that choice "foo" has a 459 significant amount more support than choice "bar", and it is 460 therefore likely easier to start the discussion by saying, "OK, 'foo' 461 seems to have quite a bit of support. Let's have the people that 462 think 'foo' is a bad idea come up and tell us why it is problematic." 463 At that point, the group can start going through the issues and see 464 if any of them are showstoppers. It could always turn out that one 465 of the objections is instantly recognized by the entire group as a 466 fatal flaw in "foo" and the group will then turn to a discussion of 467 the merits (and demerits) of "bar" instead. All that the hum does is 468 give the chair a starting point: The hum indicated that there were 469 less objections to "foo" than to "bar" at the beginning of the 470 discussion, so starting with the objections to "foo" might shorten 471 the discussion. 473 Another good reason for us to hum is because it actually gives the 474 chair the opportunity to take the temperature of the room. A smaller 475 bunch of loud hums for choice A and a larger number of non-committal 476 hums for choice B might indicate that some people believe that there 477 are serious problems with choice B, albeit the more popular by sheer 478 number of people. The chair might decide that starting with choice A 479 and getting objections to it is the easier path forward and more 480 likely to result in consensus in the end. Remember, coming to 481 consensus is a matter of eliminating disagreements, so the chair 482 wants to choose the path that gets to the least objections fastest. 483 A bunch of people who are not strongly committed to B might have no 484 real technical objection to A, even though it is not their first 485 preference. There is always a chance that this could be misleading, 486 or even abused, because some people are more willing to hum loudly 487 than others (just by dint of personality), or that one of the quieter 488 hums actually turn outs to be a showstopper that makes the original 489 choice impossible. However, keep in mind that taking the hum in this 490 case is to figure out how to start the conversation. The chair could 491 always be surprised because the hum turns out to be unanimous and no 492 further discussion is needed. Otherwise, the hum begins the 493 discussion, it doesn't end it. 495 But couldn't all of the above could have been done with a show of 496 hands instead of a hum? Absolutely. Indeed, on a mailing list there 497 is no way to using humming and so a different kind of polling would 498 be needed. Even in face-to-face situations, sometimes we do use a 499 show of hands. But there are more symbolic reasons for using a hum 500 instead of a show of hands when face-to-face: Of course, a chair 501 could get the temperature of the room by doing a show of hands too, 502 and knowing who specifically feels one way or another can help a good 503 chair guide the subsequent conversation. However, a show of hands 504 might leave the impression that the number of people matters in some 505 formal way. A chair and a working group with a solid understanding 506 of how consensus works can certainly do a show of hands and achieve 507 exactly the same result as a hum. But with less experienced folks, a 508 show of hands can end up reinforcing the mistaken notion that a vote 509 is taking place. A chair can always take the hum and then later ask 510 for specific folks to identify themselves to elicit more discussion. 511 The advantage of the hum is that it makes it perfectly clear that the 512 chair is simply figuring out the direction of the conversation. 514 This also points to another misuse of any kind of informal polling: 515 If the chair is already convinced that the group has come to 516 consensus, there isn't much reason to take a poll. In fact, taking a 517 poll can serve to discourage those who might be in the minority from 518 voicing their concerns to the group in the face of a large majority 519 who want to move forward. Often, the right thing for the chair to do 520 if they already sense consensus is to say, "It sounds to me like we 521 have consensus for choice A. Does anybody have any concerns about or 522 objections to going with A?" This allows folks to bring up issues to 523 the group that the chair might have mistakenly missed without having 524 them feel that the majority has "already spoken". 526 The reverse situation can also have similar advantages and 527 disadvantages: Sometimes a chair (say of a birds-of-a-feather 528 session, or a working group discussing a new proposed document) might 529 want to make sure that there really is a good base of support to go 530 forward with a proposal, and takes a hum. This can let the chair see 531 if there are more than a handful of active people who are really 532 interested in the new work. However, this has pitfalls as well: 533 Someone may be dissuaded from raising what could be an essential 534 concern if they feel that the group is overwhelmingly in favor of 535 going forward, or conversely some folks may decide to "hum along with 536 the crowd" even though they're not committed to the outcome. Indeed, 537 the formulation, or even the order, of questions asked during a hum 538 can have huge effects on the outcome: Asking simply, "Who supports 539 going forward with this proposal?", and asking it first, can itself 540 cause more people to hum in the affirmative than would for 541 differently formulated questions, or asking the same question after 542 some more "negatively" framed questions. Any sort of polling, 543 whether hums or even a show of hands, must be done with caution, and 544 should almost always be used to prompt discussion and questions, not 545 be the conclusion of the matter. 547 There are times where the result of a hum is a pretty even split. In 548 practical terms, that means it doesn't matter where the chair starts 549 the discussion. And in fact, we've had working groups where a coin- 550 flip decided which proposal to start with. That doesn't mean that 551 the coin-flip determined the outcome; if a fatal technical flaw was 552 found in the solution that won the coin flip, it is still incumbent 553 upon the group to address the issue raised, or abandon that solution 554 and find another. Rough consensus on the technical points, in the 555 end, is always required. Any way to find a place to start, be it the 556 hum or the coin-flip, is only getting to the beginning of the 557 discussion, not the end. 559 5. Consensus is the path, not the destination 561 We don't try to reach consensus in the IETF as an end in itself. We 562 use consensus-building as a tool to get to the best technical (and 563 sometimes procedural) outcome when we make decisions. Experience has 564 shown us that traditional voting leads to gaming of the system, 565 "compromises" of the wrong sort described earlier, important minority 566 views being ignored, and in the end worse technical outcomes. 568 Coming to consensus by looking for objections, tracking open issues, 569 and using hums as the start of discussions and not the end can all 570 take some patience. Indeed, sometimes objection-based or issue-based 571 decision making can be extremely difficult because there can be large 572 factions who have diametrically opposed views. And there is no doubt 573 that we do see some amount of political compromise (that is, the 574 undesirable kind of compromise) from time to time in the IETF. 576 However, accepting these things has its price. When we decide that a 577 discussion is too factious and opt to simply go with a majority, it 578 creates more polarized arguments in the future: Instead of working 579 toward the best technical outcome that most everyone can accept, 580 people are much quicker to run to opposing sides and dig in to their 581 positions. And when we allow real technical issues to drop because 582 proponents have simply capitulated or have "horse-traded" to allow 583 other technical problems to remain, the end product is weaker. 584 Though the IETF can never be perfectly principled with regard to 585 rough consensus, failing to be vigilant about sticking to the 586 principles makes it increasingly hard to stick to them in the future, 587 and ends us up with worse technical output. 589 Again, coming to consensus is not the goal in itself. Coming to 590 consensus is what we do during our processes to arrive at the best 591 solution. In particular, "declaring" consensus is not an end goal. 592 Attempts to declare consensus at the end of a discussion just for the 593 sake of being able to say that there is consensus often get us back 594 into the voting mentality that we're trying to avoid. 596 We often hear chairs say that they are making a "consensus call". 597 Sometimes, they simply mean they are making a call _of_ the 598 consensus; that is, they are declaring the consensus that has, in 599 their view, been reached when the discussion has reached an end. 600 That's a fine thing and what chairs are supposed to do: They are 601 "calling" the consensus. Sometimes, when a chair says that they are 602 making a "consensus call", the chair is actually making a call _for 603 discussion_ of a particular point in order to reach consensus. 604 Although it's a bit odd to call that a "consensus call" (as opposed 605 to a "call for discussion" or the like), it is fine for a chair to 606 occasionally identify a particular point of contention and get the 607 group to focus discussion on it in order to reach consensus. But 608 more and more often, we hear chairs say that they are making a 609 "consensus call" at the end of a discussion, where the chair will 610 pose the classic "Who is in favor of choice A? Who is in favor of 611 choice B?" questions to the working group. That's not really a 612 "consensus call", and has the same potential problems as the "hum" at 613 the end of a discussion: It can be tantamount to asking for a vote. 614 Even talk of "confirming consensus" has this problem: It implies that 615 you can confirm that there is consensus by counting people, not 616 issues. The important thing for a chair to do is to "call consensus" 617 in the sense of declaring the consensus; others can always object and 618 say that the chair has gotten the consensus wrong and ask for 619 reconsideration. But the chair ought to be looking for consensus 620 throughout the discussion, not asking for it at the end. 622 There are some times where chairs will ask a question or take a poll 623 toward the end of a discussion in order to figure out the state of 624 consensus, but this must be done with extreme caution. This is 625 discussed in the next section. 627 6. One hundred people for and five people against might not be rough 628 consensus 630 Section 3 discussed the idea of consensus being achieved when 631 objections had been addressed (that is, properly considered, and 632 accommodated if necessary). Because of this, using rough consensus 633 avoids a major pitfall of a straight vote: If there is a minority of 634 folks who have a valid technical objection, that objection must be 635 dealt with before consensus can be declared. This also reveals one 636 of the great strengths of using consensus over voting: It isn't 637 possible to use "vote stuffing" (simply recruiting a large number of 638 people to support a particular side, even people who have never 639 participated in a working group or the IETF at all) to change the 640 outcome of a consensus call. As long as the chair is looking for 641 outstanding technical objections and not counting heads, vote 642 stuffing shouldn't affect the outcome of the consensus call. 644 So in a large working group with over 100 active participants and 645 broad agreement to go forward with a particular protocol, if a few 646 participants say, "This protocol is going to cause congestion on the 647 network, and it has no mechanism to back off when congestion occurs; 648 we object to going forward without such a mechanism in place", and 649 the objection is met with silence on the mailing list, there is no 650 consensus. Even if the working group chair makes a working group 651 "last call" on the document, and 100 people actively reply and say, 652 "This document is ready to go forward", if the open issue hasn't been 653 addressed, there's still no consensus, not even rough consensus. 654 It's the existence of the unaddressed open issue, not the number of 655 people, which is determinative in judging consensus. As discussed 656 earlier, you can have rough consensus with issues that have been 657 purposely dismissed, but not ones that have been ignored. 659 This brings us back to when a poll could be used (cautiously) at the 660 end of a discussion. A discussion may be ongoing for some time, and 661 a particular objection seems to be holding up the decision. A 662 diligent chair who's been carefully listening to the discussion might 663 think, "I have heard person X make this objection, and I've heard 664 responses from many other folks that really address the issue. I 665 think we have rough consensus. But the objection keeps coming up. 666 Maybe it's just the one person getting up again and again with the 667 same argument, but maybe we don't have rough consensus. I'm not 668 sure." At this point, the chair might ask for a hum. If only a 669 single hum objecting can be heard, even a loud one, in the face of 670 everyone else humming that the objection has been answered, the chair 671 has pretty good reason to believe that they heard the single 672 objection all along and it really has been addressed. However, to 673 say immediately after the hum, "It sounds like we have rough 674 consensus" and nothing else is at best being slipshod: What the chair 675 really needs to say at that point is, "I believe the only objection 676 we've heard is A (coming from person X), and I've heard answers from 677 the group that fully address that issue. So, unless I hear a 678 different objection than the one I've just described, I find that 679 there is rough consensus to move on." That leaves the door open for 680 someone to tell the chair that the objection was really on different 681 grounds and they misevaluated, but it makes it clear that the chair 682 has found rough consensus due to the discussion, not due to the hum. 683 Again, it's not the hum that ends things, it's that the issues have 684 been addressed. If the small minority (even one person) still has an 685 issue that hasn't been addressed, rough consensus still hasn't been 686 achieved. 688 Even if no particular person is still standing up for an issue, that 689 doesn't mean an issue can be ignored. As discussed earlier, simple 690 capitulation on an issue is not coming to consensus. But even in a 691 case where someone who is not an active participant, who might not 692 care much about the fate of the work, raises a substantive issue and 693 subsequently disappears, the issue needs to be addressed before the 694 chair can claim that rough consensus exists. 696 7. Five people for and one hundred people against might still be rough 697 consensus 699 This one is the real mind bender for most people, and certainly the 700 most controversial. Say there is a very small working group, one 701 with half a dozen truly active participants who are experts in the 702 field; everybody else is just following along, but not contributing 703 to the discussion. The active folks come up with a protocol document 704 that they all agree is the right way forward, and people inside and 705 outside the working group agree that the protocol is likely to get 706 widespread adoption; it is a good solution to a real problem, even if 707 the non-experts don't have the ability to fully judge the details. 709 However, one of the active members has an objection to a particular 710 section: The protocol currently uses a well-known algorithm to 711 address an issue, but the objector has a very elegant algorithm to 712 address the issue, one which works especially well on their 713 particular piece of hardware. There is some discussion, and all of 714 the other contributors say, "Yes, that is elegant, but what we're 715 using now is well-understood, widely-implemented, and it works 716 perfectly acceptably, even on the objector's hardware. There is 717 always some inherent risk to go with a new, albeit more elegant, 718 algorithm. We should stick to the one we've got." The chair follows 719 the conversation and says, "It sounds like the issue has been 720 addressed and there's consensus to stick with the current solution." 721 The objector is not satisfied, maybe even saying, "But this is silly. 722 You've seen that my algorithm works. We should go with that." The 723 chair makes the judgement that the consensus is rough, in that there 724 is still an objector, but the issue has been addressed and the risk 725 argument has won the day. The chair makes a working group last call. 727 Now the worst case scenario happens. The objector, still unhappy 728 that their preferred solution was not chosen, recruits one hundred 729 people, maybe a few who were silent participants in the working group 730 already, but mostly people who work at the same company as the 731 objector who never participated before. The objector gets them all 732 to post a message to the list saying, "I believe we should go with 733 the new elegant algorithm in section Z instead of the current one. 734 It is more elegant, and works better on our hardware." The chair 735 sees these dozens of messages coming in and posts a query to each of 736 them: "We discussed this on the list, and we seemed to have consensus 737 that, given the inherent risk of a new algorithm, and the widespread 738 deployment of this current one, it's better to stick with the current 739 one. Do you have further information that indicates something 740 different?" And in reply the chair gets utter silence. These 741 posters to the list (say some of whom were from the company sales and 742 marketing department) thought that they were simply voting and have 743 no answer to give. At that point, it is within bounds for the chair 744 to say, "We have objections, but the objections have been 745 sufficiently answered, and the objectors seem uninterested in 746 participating in the discussion. Albeit rough in the extreme, there 747 is rough consensus to go with the current solution." 749 Though the above example uses the most extreme form of recruiting 750 sheer numbers of people (i.e., from the sales and marketing 751 department), the same principle should hold true no matter how new or 752 how credible the objectors seem: The chair is trying to discover 753 whether objections have been addressed or if there are still open 754 issues. If, instead of a bunch of sales and marketing people, the 755 new people to the conversation are developers or others who are 756 directly involved in creating the technology, or even folks who have 757 been participating the entire time who's knowledge of the technology 758 is not in question at all, the principle is still the same: If the 759 objection has been addressed, and the new voices are not giving 760 informed responses to that point, they can still justifiably be 761 called "in the rough". Of course, the more involved and knowledgable 762 the objectors are, the more difficult it will be for the consensus 763 caller to make the call, but a call of rough consensus is reasonable. 764 The chair in this case needs to understand what the responses mean; 765 only sufficiently well-informed responses that justify the position 766 taken can really "count". 768 There is no doubt that this is the degenerate case and a clear 769 indication of something pathological. But this is precisely what 770 rough consensus is ideally suited to guard against: vote stuffing. 771 In the presence of an objection, the chair can use their technical 772 judgement to decide that the objection has been answered by the group 773 and that rough consensus overrides the objection. Now, the case 774 described here is probably the hardest call for the chair to make 775 (how many of us are willing to make the call that the vast majority 776 of people in the room are simply stonewalling, not trying to come to 777 consensus?), and if appealed it would be incredibly difficult for the 778 appeals body to sort out. Indeed, it is likely that if a working 779 group got this dysfunctional, it would put the whole concept of 780 coming to rough consensus at risk. But still, the correct outcome in 781 this case is to look at the very weak signal against the huge 782 background noise in order to find the rough consensus. 784 8. Conclusion 786 Although this document talks quite a bit about the things chairs and 787 working groups and other IETF participants might do to achieve rough 788 consensus, this document is not really about process and procedures. 789 It describes a way of thinking about how we make our decisions. 790 Sometimes, a show of hands can be useful; sometimes it can be quite 791 damaging and result in terrible decisions. Sometimes, using a device 792 like a "hum" can avoid those pitfalls; sometimes it is just a poorly 793 disguised vote. The point of this document is to get all of us to 794 think about how we are coming to decisions in the IETF, to make sure 795 we avoid the dangers of "majority rule" and actually get to rough 796 consensus decisions with the best technical outcomes. 798 9. Security Considerations 800 "He who defends with love will be secure." -- Lao Tzu 802 10. Informative References 804 [Clark] Clark, D., "A Cloudy Crystal Ball - Visions of the 805 Future", July 1992. 807 In "Proceedings of the Twenty-Fourth Internet Engineering 808 Task Force" [IETF24], July 13-17, 2004, pages 539-543. 810 [IETF24] Davies, M., Ed., Clark, C., Ed., and D. Legare, Ed., 811 "Proceedings of the Twenty-Fourth Internet Engineering 812 Task Force", July 1992, 813 . 815 [RFC1603] Huizer, E. and D. Crocker, "IETF Working Group Guidelines 816 and Procedures", RFC 1603, March 1994. 818 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 819 Procedures", BCP 25, RFC 2418, September 1998. 821 [Sheeran] Sheeran, M., "Beyond Majority Rule: Voteless Decisions in 822 the Religious Society of Friends", December 1983. 824 Appendix A. Acknowledgements 826 This document is the result of conversations with many IETF 827 participants, too many to name individually. I greatly appreciate 828 all of the discussions and guidance. I do want to extend special 829 thanks to Peter Saint-Andre, who sat me down and pushed me to start 830 writing, and to Melinda Shore for pointing me to Beyond Majority Rule 831 [Sheeran], which inspired some of the thinking in this document. 833 Author's Address 835 Pete Resnick 836 Qualcomm Technologies, Inc. 837 5775 Morehouse Drive 838 San Diego, CA 92121 839 US 841 Phone: +1 858 6511 4478 842 Email: presnick@qti.qualcomm.com