Internet Engineering Task Force (IETF) P. Resnick
Request for Comments: 7282 Qualcomm Technologies, Inc.
Category: Informational June 2014
ISSN: 2070-1721
Internet Engineering Task Force (IETF) P. Resnick
Request for Comments: 7282 Qualcomm Technologies, Inc.
Category: Informational June 2014
ISSN: 2070-1721
On Consensus and Humming in the IETF
IETF中的共识与哼唱
Abstract
摘要
The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a "majority rule" philosophy. This is why we engage in rituals like "humming" instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day without consideration of minority concerns. This document explains some features of rough consensus, what is not rough consensus, how we have gotten away from it, how we might think about it differently, and the things we can do in order to really achieve rough consensus.
IETF有着通过协商一致过程进行技术工作的悠久传统，考虑到IETF参与者之间的不同观点，并就技术问题达成（至少是粗略的）共识。特别是，IETF不应遵循“多数规则”的理念。这就是为什么我们参加“哼唱”之类的仪式而不是投票。然而，我们现在越来越多的行动与投票无法区分，而且我们经常让多数人获胜，而不考虑少数人的关切。本文件解释了粗略共识的一些特征，什么不是粗略共识，我们是如何摆脱它的，我们可能会以不同的方式思考它，以及我们可以做些什么来真正实现粗略共识。
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.
注：本文件是有意识地作为信息性文件提出的。它不建议更改任何IETF流程，因此不是BCP。它只是一个原则的集合，希望IETF能够围绕它达成（至少是粗略的）共识。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7282.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 . . . . . . . . . . . . . . . . . . . . . . . . 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
Almost every IETF participant knows the aphorism from Dave Clark's 1992 plenary presentation [Clark] regarding how we make decisions in the IETF:
几乎每一位IETF参与者都知道Dave Clark 1992年的全体演讲[Clark]中关于我们如何在IETF中做出决策的格言：
We reject: kings, presidents and voting.
我们拒绝：国王、总统和投票。
We believe in: rough consensus and running code.
我们相信：大致的共识和运行的代码。
That is, our credo is that we don't let a single individual dictate decisions (a king or president), nor should decisions be made by a vote, nor do we want decisions to be made in a vacuum without practical experience. Instead, we strive to make our decisions by the consent of all participants, though allowing for some dissent (rough consensus), and to have the actual products of engineering (running code) trump theoretical designs.
也就是说，我们的信条是，我们不让一个人（国王或总统）主宰决策，也不应该通过投票做出决策，也不希望决策是在没有实际经验的真空中做出的。相反，我们努力在所有参与者的同意下做出决定，尽管允许一些异议（粗略的共识），并让工程（运行代码）的实际产品胜过理论设计。
Having full consensus, or unanimity, would be ideal, but we don't require it: Requiring full consensus allows a single intransigent person who simply keeps saying "No!" to stop the process cold. We only require rough consensus: If the chair of a working group determines that a technical issue brought forward by an objector has been truly considered by the working group, and the working group has made an informed decision that the objection has been answered or is not enough of a technical problem to prevent moving forward, the chair can declare that there is rough consensus to go forward, the objection notwithstanding.
达成完全一致或一致意见是理想的，但我们并不要求这样做：要求完全一致意见可以让一个顽固的人简单地说“不”，从而停止整个过程。我们只需要大致达成共识：如果工作组主席确定反对者提出的技术问题已得到工作组的真正审议，并且工作组已作出知情决定，即反对意见已得到答复，或者不足以构成技术问题，无法继续推进，主席可以宣布，尽管有反对意见，但已大致达成一致意见。
To reinforce that we do not vote, we have also adopted the tradition of "humming": When, for example, we have face-to-face meetings and the chair of the working group wants to get a "sense of the room", instead of a show of hands, sometimes the chair will ask for each side to hum on a particular question, either "for" or "against".
为了强调我们不投票，我们还采用了“哼唱”的传统：例如，当我们举行面对面会议时，工作组主席希望获得“房间感”，而不是举手，有时主席会要求每一方就某一特定问题哼唱“赞成”或“反对”。
However, in recent years we have seen participants (and even some folks in IETF leadership) who do not understand some of the subtleties of consensus-based decision making. Participants ask, "Why don't we just vote? Why are we bothering with this 'humming' thing?" Or even more concerning, "We've already hummed/voted, so why isn't the discussion concluded?" Chairs, many of whom have little experience in leading large volunteer groups like those in the IETF, let alone experience in how to gather consensus, are faced with factious working groups with polarized viewpoints and long-running unresolved issues that return again and again to the agenda. More and more frequently, people walk away from working groups, thinking that "consensus" has created a document with horrible compromises to satisfy everyone's pet peeve instead of doing "the right thing".
然而，近年来，我们看到参与者（甚至IETF领导层中的一些人）不了解基于共识的决策的一些微妙之处。参与者会问：“我们为什么不投票？我们为什么要为这个‘哼唱’的事情烦恼？”或者更关心的是，“我们已经哼唱/投票了，那么为什么讨论还没有结束？”主席们，他们中的许多人在领导像IETF这样的大型志愿者团体方面几乎没有经验，更不用说在如何收集共识方面的经验了，面临着观点两极分化、争议不断的工作组，以及一次又一次回到议程上的长期未决问题。越来越多的人离开工作组，认为“共识”创造了一份带有可怕妥协的文件，以满足每个人的愤怒，而不是做“正确的事情”。
None of these things are indicators of a rough consensus process being used, and the fact that we are seeing them is likely due to some basic misperceptions.
所有这些都不是正在使用的粗略共识过程的指标，而我们看到它们的事实很可能是由于一些基本的误解。
This document explains some features of rough consensus, explains what is not rough consensus, discusses some new ways to think about rough consensus, and suggests ways that we might achieve rough consensus and judge it in the IETF. Though this document describes some behaviors of working groups and chairs, it does so in broad brushstrokes and it does not prescribe specific procedures. Rather, this document is intended to foster understanding of the underlying principles of IETF consensus processes. While it may be of general interest to anyone interested in the IETF consensus processes, the primary audience for this document is those who have experience working in the IETF and are trying to understand and participate in the consensus-building process, and it is particularly aimed at generating thought and discussion among those who might lead a consensus discussion. Although most of the examples in this document talk about working group chairs, these principles apply to any person who is trying to lead a group to rough consensus, whether a chair, a design team leader, a document editor, an area director, or any community member who is facilitating a discussion or trying to assess consensus.
本文件解释了粗略共识的一些特征，解释了什么不是粗略共识，讨论了思考粗略共识的一些新方法，并提出了在IETF中实现粗略共识和判断粗略共识的方法。尽管本文件描述了工作组和主席的一些行为，但它以粗略的笔触描述了这些行为，并且没有规定具体的程序。相反，本文件旨在促进对IETF共识过程基本原则的理解。尽管对IETF协商一致过程感兴趣的人可能普遍感兴趣，但本文件的主要读者是那些在IETF中有工作经验并试图理解和参与协商一致过程的人，它的特别目的是在那些可能领导协商一致讨论的人中间引起思考和讨论。尽管本文件中的大多数示例都涉及工作组主席，但这些原则适用于试图领导团队达成大致共识的任何人，无论是主席、设计团队负责人、文档编辑、区域主管，还是推动讨论或试图评估共识的任何社区成员。
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.
虽然社会已大致达成共识，认为本文件中表达的原则（至少大致）正确，但我们目前的许多做法与这些原则不一致。同样，本文件主要旨在引发思考和讨论，而不是规定实践。如果IETF确实致力于这些原则，实践可能会在未来发生变化。
A working group comes to a technical question of whether to use format A or format B for a particular data structure. The chair notices that a number of experienced people think format A is a good choice. The chair asks on the mailing list, "Is everyone OK with format A?" Inevitably, a number of people object to format A for one or another technical reason. The chair then says, "It sounds like we don't have consensus to use format A. Is everyone OK with format B?" This time even more people object to format B, on different technical grounds. The chair, not having agreement on either format A or format B, is left perplexed, thinking the working group has deadlocked.
一个工作组提出了一个技术问题，即对特定数据结构使用格式A还是格式B。主席注意到，许多有经验的人认为格式a是一个不错的选择。主席在邮件列表上问道：“每个人都同意格式A吗？”不可避免地，许多人出于某种技术原因反对格式A。主席接着说，“听起来我们没有共识使用格式A。大家都同意格式B吗？”这一次，更多的人反对格式B，基于不同的技术理由。主席对格式A或格式B都没有达成一致意见，因此感到困惑，认为工作组陷入僵局。
The problem that the chair got themselves into was thinking that what they were searching for was agreement. "After all", thinks the chair, "consensus is a matter of getting everyone to agree, so asking
主席陷入的问题是，他们认为他们寻求的是一致意见。主席认为，“毕竟，共识是一个让每个人都同意的问题，所以要问
whether everyone agrees is what the chair ought to do. And if lots of people disagree, there's no consensus." But _determining_ consensus and _coming to_ consensus are different things than _having_ consensus.
是否每个人都同意是主席应该做的。如果很多人不同意，就没有共识。”但是，决定共识和达成共识与达成共识是两码事。
The distinction might be a bit subtle, but it's important. Engineering always involves a set of tradeoffs. It is almost certain that any time engineering choices need to be made, there will be options that appeal to some people, but are not appealing to some others. In determining consensus, the key is to separate those choices that are simply unappealing from those that are truly problematic. If at the end of the discussion some people have not gotten the choice that they prefer, but they have become convinced that the chosen solution is acceptable, albeit less appealing, they have still come to consensus. Consensus doesn't require that everyone is happy and agrees that the chosen solution is the best one. Consensus is when everyone is sufficiently satisfied with the chosen solution, such that they no longer have specific objections to it.
区别可能有点微妙，但很重要。工程总是涉及一系列的权衡。几乎可以肯定的是，在任何需要做出工程选择的时候，都会有一些选择吸引一些人，但对另一些人没有吸引力。在确定共识时，关键是将那些根本不吸引人的选择与那些真正有问题的选择分开。如果在讨论结束时，一些人没有得到他们喜欢的选择，但他们确信所选择的解决方案是可以接受的，尽管吸引力较小，他们仍然达成了共识。共识并不要求每个人都高兴，并同意所选择的解决方案是最好的。共识是当每个人都对所选择的解决方案感到足够满意，从而不再有具体的反对意见时。
So, in the case of a working group decision, after the initial discussion of the pros and cons of the available choices, it is most important to ask not just for objections to a particular proposal, but for the nature of those objections. A chair who asks, "Is everyone OK with choice A?" is going to get objections. But a chair who asks, "Can anyone not live with choice A?" is more likely to only hear from folks who think that choice A is impossible to engineer given some constraints. Following up with, "What are the reasons you object to choice A?" is also essential. Then, the purported failings of the choice can be examined by the working group. The objector might convince the rest of the group that the objections are valid and the working group might choose a different path. Conversely, the working group might convince the objector that the concerns can be addressed, or that the choice is simply unappealing (i.e., something the objector can "live with") and not a show-stopper. In any event, closure is much more likely to be achieved quickly by asking for and trying to accommodate the objections rather than asking for agreement.
因此，就工作组的决定而言，在对现有选择的利弊进行初步讨论之后，最重要的是不仅要询问对某一特定提案的反对意见，还要询问这些反对意见的性质。如果一位主席问：“每个人都同意A选项吗？”就会遭到反对。但是，如果一位主席问：“有人不能接受选择a吗？”那么他很可能只会听到一些人的声音，他们认为，考虑到某些限制，选择a是不可能实现的。接下来，“你反对选择A的原因是什么？”也是很重要的。然后，工作组就可以审查这项选择据称的失败之处。反对者可能会让小组其他成员相信反对是有效的，工作组可能会选择不同的途径。相反，工作组可能会说服反对者，这些担忧可以得到解决，或者该选择根本没有吸引力（即，反对者可以“接受”的东西），而不是阻碍表演的因素。在任何情况下，通过要求并试图容纳反对意见而不是要求达成一致意见，更可能很快达成和解。
The above discussion does not mean that sorting out disagreements is the only thing that needs to be done for successful consensus. An engineering solution that has no objections, but also has no base of support and is met with complete apathy, is not a solution that has any useful sort of consensus. Consensus does require the active engagement and eventual support of those who are working on the solution. However, finding mere "agreement" among participants is not enough. People might very well agree that a solution is
上述讨论并不意味着解决分歧是达成成功共识所需要做的唯一事情。一个工程解决方案没有异议，但也没有支持的基础，并且完全没有兴趣，这不是一个有任何有用共识的解决方案。达成共识确实需要那些致力于解决方案的人的积极参与和最终支持。然而，仅仅在参与者之间找到“一致”是不够的。人们很可能会同意解决方案是可行的
sufficient and have no objection to it, but if they also don't actively think it's a good and correct outcome, it's absurd to declare that the group has consensus.
这已经足够了，也没有人反对，但如果他们也不积极地认为这是一个好的、正确的结果，那么宣布该小组达成了共识是荒谬的。
There is also an important point to be made about reaching consensus and "compromising": Unfortunately, the word "compromise" gets used in two different ways, and though one sort of compromising to come to consensus is good (and important), the other sort of compromising in order to achieve consensus can actually be harmful. As mentioned earlier, engineering always involves balancing tradeoffs, and figuring out whether one engineering decision makes more sense on balance compared to another involves making engineering "compromises": We might have to compromise processor speed for lower power consumption, or compromise throughput for congestion resistance. Those sorts of compromises are among engineering choices, and they are expected and essential. We always want to be weighing tradeoffs and collectively choosing the set that best meets the full set of requirements.
关于达成共识和“妥协”还有一点很重要：不幸的是，“妥协”一词有两种不同的用法，尽管达成共识的一种妥协是好的（也是重要的），但为了达成共识的另一种妥协实际上是有害的。如前所述，工程设计总是涉及权衡，要弄清楚一个工程决策是否比另一个工程决策更合理，就需要进行工程“折衷”：我们可能必须折衷处理器速度以降低功耗，或者折衷吞吐量以抵抗拥塞。这些折衷是工程选择中的一种，它们是预期的和必要的。我们总是希望权衡权衡，共同选择最符合全套需求的集合。
However, there is another sense of "compromise" that involves compromising between people, not engineering principles. For example, a minority of a group might object to a particular proposal, and even after discussion still think the proposal is deeply problematic, but decide that they don't have the energy to argue against it and say, "Forget it, do what you want". That surely can be called a compromise, but a chair might mistakenly take this to mean that they agree, and have therefore come to consensus. But really all that they've done is capitulated; they've simply given up by trying to appease the others. That's not coming to consensus; there still exists an outstanding unaddressed objection. Again, if the objection is only that the choice is not ideal but is otherwise acceptable, such a compromise is fine. But conceding when there is a real outstanding technical objection is not coming to consensus.
然而，还有另一种意义上的“妥协”，即人与人之间的妥协，而不是工程原理。例如，一个群体中的少数人可能会反对某个特定的提案，即使经过讨论，他们仍然认为该提案存在严重问题，但决定他们没有精力反对该提案，并说：“算了吧，想干什么就干什么”。这当然可以称为一种妥协，但主席可能会错误地认为这意味着他们同意，并因此达成共识。但实际上他们所做的一切都是投降；他们只是为了安抚其他人而放弃了。这还没有达成共识；仍然存在一个尚未解决的异议。同样，如果反对意见仅仅是选择不理想，但在其他方面是可以接受的，那么这样的妥协是可以接受的。但在存在真正突出的技术异议时让步并没有达成共识。
Even worse is the "horse-trading" sort of compromise: "I object to your proposal for such-and-so reasons. You object to my proposal for this-and-that reason. Neither of us agree. If you stop objecting to my proposal, I'll stop objecting to your proposal and we'll put them both in." That again results in an "agreement" of sorts, but instead of just one outstanding unaddressed issue, this sort of compromise results in two, again ignoring them for the sake of expedience.
更糟糕的是“讨价还价”式的妥协：“我出于这样或那样的原因反对你的建议。你出于这样或那样的原因反对我的建议。我们双方都不同意。如果你停止反对我的建议，我将停止反对你的建议，我们将把它们都放进去。”这再次导致了某种“协议”，但是，这种妥协并不是只解决一个悬而未决的问题，而是导致了两个问题，再次为了权宜之计而忽略了它们。
These sorts of "capitulation" or "horse-trading" compromises have no place in consensus decision making. In each case, a chair who looks for "agreement" might find it in these examples because it appears that people have "agreed". But answering technical disagreements is what is needed to achieve consensus, sometimes even when the people who stated the disagreements no longer wish to discuss them.
这种“投降”或“讨价还价”的妥协在共识决策中没有立足之地。在每一种情况下，寻求“同意”的主席可能会在这些例子中找到它，因为人们似乎已经“同意”。但要达成共识，就必须回答技术上的分歧，有时甚至当提出分歧的人不想再讨论这些分歧时也是如此。
Coming to consensus is when everyone (including the person making the objection) comes to the conclusion that either the objections are valid, and therefore make a change to address the objection, or that the objection was not really a matter of importance, but merely a matter of taste. Of course, coming to full consensus like that does not always happen. That's why in the IETF, we talk about "rough consensus".
达成共识是指每个人（包括提出异议的人）都得出结论，要么反对是有效的，因此做出改变以解决反对，要么反对不是真正重要的问题，而只是品味问题。当然，像这样达成全面共识并不总是会发生的。这就是为什么在IETF中，我们谈论“大致共识”。
3. Rough consensus is achieved when all issues are addressed, but not necessarily accommodated
3. 当所有问题都得到解决，但不一定得到解决时，就可以达成大致的共识
The preceding discussion gives an example where the working group comes to consensus on a point: Either the objector is satisfied with the answer to the objection, or the working group is satisfied that the objection is valid and changes course. But that doesn't happen all of the time, and it's certainly not the problematic case. Again, engineering is always a set of tradeoffs. Often, a working group will encounter an objection where everyone understands the issue and acknowledges that it is a real shortcoming in the proposed solution, but the vast majority of the working group believes that accommodating the objection is not worth the tradeoff of fixing the problem.
前面的讨论给出了一个工作组就某一点达成共识的例子：要么反对者对反对的答案感到满意，要么工作组认为反对是有效的并改变了方向。但这并不是一直都会发生，当然也不是问题所在。同样，工程总是一系列的权衡。通常，工作组会遇到反对意见，因为每个人都理解这一问题，并承认这是拟议解决方案中的一个真正缺点，但绝大多数工作组认为，接受反对意见并不值得在解决问题上进行权衡。
So, an objector might say, "The proposal to go with protocol X is much more complicated than going with protocol Y. Protocol Y is a much more elegant and clean solution, which I can code much more easily, and protocol X is a hack." The working group might consider this input, and someone might respond, "But we have a great deal of code already written that is similar to protocol X. While I agree that protocol Y is more elegant, the risks to interoperability with an untested solution are not worth it compared to the advantages of going with the well-understood protocol X." If the chair finds, in their technical judgement, that the issue has truly been considered, and that the vast majority of the working group has come to the conclusion that the tradeoff is worth making, even in the face of continued objection from the person(s) who raised the issue, the chair can declare that the group has come to rough consensus. (And even though this is framed in terms of a "vast majority", even that is not necessarily true. This point is discussed in more detail in Sections 6 and 7.)
因此，一个反对者可能会说，“与协议X一起运行的建议比协议Y要复杂得多。协议Y是一个更优雅、更干净的解决方案，我可以更容易地进行编码，而协议X是一个黑客。”工作组可能会考虑这个输入，有人可能会回应。“但我们已经编写了大量类似于协议X的代码。虽然我同意协议Y更优雅，但与众所周知的协议X相比，与未经测试的解决方案的互操作性风险并不值得。“如果主席在其技术判断中认为该问题确实得到了审议，并且工作组绝大多数成员得出结论认为，即使在提出该问题的人继续反对的情况下，也值得作出权衡，主席可以宣布该小组已达成初步共识。（即使这是以“绝大多数”来界定的，也不一定是真的。第6节和第7节将更详细地讨论这一点。）
Note that this portrays rough consensus as a fallback. In one sense, it is: As a working group does its work and makes its choices, it behaves as if it is striving toward full consensus and tries to get all issues addressed to the satisfaction of everyone in the group, even those who originally held objections. It treats rough consensus as a sort of "exception processing", to deal with cases where the person objecting still feels strongly that their objection is valid
请注意，这将粗略的共识描述为一种退路。从某种意义上说，它是：当一个工作组开展工作并做出选择时，它的行为就好像它正在努力达成完全的共识，并试图使所有问题得到解决，以使工作组中的每个人都满意，即使是那些最初持反对意见的人。它将粗略的共识视为一种“例外处理”，以处理反对者仍然强烈认为他们的反对是有效的情况
and must be accommodated. But it is certainly true that, more often than not in the IETF, at least someone in the group will be unsatisfied with a particular decision. In that sense, rough consensus might be closer to the norm than the exception. However, when a participant says, "That's not my favorite solution, but I can live with it; I'm satisfied that we've made a reasonable choice", that participant is not in the "rough" part of a rough consensus; the group actually reached consensus if that person is satisfied with the outcome. It's when the chair has to declare that an unsatisfied person still has an open issue, but that the group has truly answered the objection, that the consensus is only rough.
而且必须适应。但确实，在IETF中，至少有人会对某个特定的决定感到不满意。从这个意义上说，粗略的共识可能比例外更接近于规范。然而，当一名参与者说，“这不是我最喜欢的解决方案，但我可以接受它；我对我们做出了合理的选择感到满意”，该参与者并不在粗略共识的“粗略”部分；如果这个人对结果感到满意，小组实际上达成了共识。当主席不得不宣布一个不满意的人仍然有一个悬而未决的问题，但该小组确实回答了反对意见，达成的共识只是粗略的。
Now, a conclusion of having only rough consensus relies heavily on the good judgement of the consensus caller. The group must truly consider and weigh an issue before the objection can be dismissed as being "in the rough". ("In the rough" is terminology from golf. "The rough" is the term for the longer grass at the side of the fairway, and if your ball has landed in the rough you are off course and away from the normal direction of play. The phrase gets used quite a bit in the IETF as a play on words to complement "rough consensus" meaning that you are "in the rough" if you find yourself not agreeing with the rough consensus.) The chair of a working group who is about to find that there is only rough consensus is going to have to decide that not only has the working group taken the objection seriously, but that it has fully examined the ramifications of not making a change to accommodate it, and that the outcome does not constitute a failure to meet the technical requirements of the work. In order to do this, the chair will need to have a good idea of the purpose and architecture of the work being done, perhaps referring to the charter of the working group or a previously published requirements document, or even consulting with other experts on the topic, and then the chair will use their own technical judgement to make sure that the solution meets those requirements. It is possible that the chair can come to the wrong conclusion, and the chair's conclusion is always appealable should that occur, but the chair must use their judgement in these cases. What can't happen is that the chair bases their decision solely on hearing a large number of voices simply saying, "The objection isn't valid." That would simply be to take a vote. A valid justification needs to me made.
现在，只有粗略共识的结论在很大程度上取决于共识调用者的良好判断。在反对被驳斥为“粗暴”之前，小组必须真正考虑和权衡问题。（“粗野”是高尔夫术语。“粗野”是指球道一侧较长的草地，如果你的球落在了粗野处，你就偏离了球场，偏离了正常的比赛方向。这个短语在IETF中经常被用作对“粗野共识”的补充，意思是你“在粗野中”如果你发现自己不同意粗略的共识。）即将发现只有粗略的共识的工作组主席将不得不决定，工作组不仅认真对待了反对意见，而且已经充分审查了不作出改变以适应反对意见的后果，结果不构成不符合工程技术要求。为了做到这一点，主席需要对正在进行的工作的目的和结构有一个很好的了解，可能会参考工作组章程或以前发布的要求文件，甚至就这一主题咨询其他专家，然后主席将使用他们自己的技术判断来确保解决方案满足这些要求。主席可能会得出错误的结论，如果出现这种情况，主席的结论总是可以上诉的，但主席必须在这些情况下运用他们的判断。不可能发生的是，主席的决定完全基于听到大量的声音，只是说：“反对无效。”那就是投票。需要给我一个合理的理由。
It is important to recognize that this view of rough consensus is a change from the way it sometimes has been characterized in the IETF. RFC 1603 [RFC1603] described rough consensus as the "dominant view" of the group:
重要的是要认识到，这种粗略共识的观点与IETF中有时描述的方式不同。RFC 1603[RFC1603]将大致共识描述为该集团的“主导观点”：
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).
工作组通过“粗略的共识”过程作出决定。IETF共识并不要求所有参与者都同意，尽管这当然是首选。一般而言，应以工作组的主导意见为准。（但是，必须指出，“支配地位”不是根据数量或持续性来确定的，而是更普遍的一致性。）协商一致可以通过投票、哼唱或工作组同意的任何其他方式（当然是通过粗略协商一致）来确定。
The above says that consensus can be "determined" by balloting and humming, and there are certainly IETF folks who have thought of rough consensus as being primarily about the percentage of people who agree with a decision. Indeed, RFC 2418 [RFC2418] adds on to the above text by stating, "Note that 51% of the working group does not qualify as 'rough consensus' and 99% is better than rough." This document actually disagrees with the idea that simply balloting or otherwise looking at percentages can "determine" consensus. While counting heads might give a good guess as to what the rough consensus will be, doing so can allow important minority views to get lost in the noise. One of the strengths of a consensus model is that minority views are addressed, and using a rough consensus model should not take away from that. That is why this document talks a great deal about looking at open issues rather than just counting the number of people who do or do not support any given issue. Doing so has some interesting and surprising implications that are discussed in subsequent sections.
上面说，共识可以通过投票和哼唱来“确定”，当然也有IETF的人认为大致的共识主要是关于同意决定的人的百分比。事实上，RFC 2418[RFC2418]在上述文本的基础上补充说，“请注意，51%的工作组成员不符合‘粗略共识’的条件，99%的工作组成员优于粗略共识。”该文件实际上不同意简单投票或以其他方式查看百分比就可以“确定”共识的观点。虽然计算人头数可以很好地猜测大致的共识是什么，但这样做会让重要的少数群体观点在噪音中迷失。共识模型的优点之一是可以解决少数人的观点，而使用粗略的共识模型不应剥夺这一点。这就是为什么这份文件大量讨论了如何看待未决问题，而不仅仅是统计支持或不支持某一特定问题的人数。这样做有一些有趣和令人惊讶的含义，将在后续章节中讨论。
Any finding of rough consensus needs, at some level, to provide a reasoned explanation to the person(s) raising the issue of why their concern is not going to be accommodated. A good outcome is for the objector to understand the decision taken and accept the outcome, even though their particular issue is not being accommodated in the final product.
在某种程度上，任何粗略共识的发现都需要向提出问题的人提供一个合理的解释，说明为什么他们的担忧不会得到解决。一个好的结果是反对者理解所做的决定并接受结果，即使他们的特定问题没有在最终产品中得到解决。
Remember, if the objector feels that the issue is so essential that it must be attended to, they always have the option to file an appeal. A technical error is always a valid basis for an appeal. The chair in making the consensus call (or whoever is responsible to hear an appeal) may determine that the issue was addressed and understood, but they also have the freedom and the responsibility to say, "The group did not take this technical issue into proper account" when appropriate. Simply having a large majority of people
请记住，如果反对者认为该问题非常重要，必须加以处理，他们始终可以选择提起上诉。技术错误始终是上诉的有效依据。进行协商一致呼吁的主席（或负责听取上诉的任何人）可以确定该问题已得到解决和理解，但他们也有自由和责任在适当的时候说：“本集团没有适当考虑该技术问题”。仅仅是拥有大多数人
agreeing to dismiss an objection is not enough to claim there is rough consensus; the group must have honestly considered the objection and evaluated that other issues weighed sufficiently against it. Failure to do that reasoning and evaluating means that there is no true consensus.
同意驳回反对意见并不足以声称存在大致的共识；工作组必须诚实地考虑了反对意见，并评估了其他问题是否足以对其产生不利影响。没有做到这一点，推理和评估意味着没有真正的共识。
We don't vote in the IETF. In some ways, we can't vote: Since the IETF is not a membership organization, it's nearly impossible to figure out who would get a vote for any given question. We can't know who the "members" of any given working group would be at any one time, and we certainly can't know who all of the "members" of the IETF would be: That's why we refer to "participants" in the IETF; the IETF doesn't really have "members". Indeed, we often recruit additional implementers and other experts into working groups in order to ensure that broader views are brought into the discussion. So, voting is simply not practical. We've also decided that coming to consensus (albeit sometimes rough consensus) is an important thing to do. Final decisions are supposed to be taken on the mailing list, which reinforces the idea that we come to consensus by looking at the open issues and not counting heads. We do, on occasion, take informal polls to get a sense of the direction of the discussion, but we try not to treat a poll as a vote that decides the issue. When we do discuss things face-to-face, we don't want to vote there either; we want to show that we are coming to consensus. So, sometimes, to reinforce the notion that we're not voting, instead of a show of hands, we often "hum".
我们在IETF中不投票。在某些方面，我们不能投票：因为IETF不是一个会员组织，所以几乎不可能知道谁会为任何给定的问题投票。我们不知道任何一个工作组的“成员”是谁，当然也不知道IETF的所有“成员”是谁：这就是为什么我们在IETF中提到“参与者”；IETF实际上没有“成员”。事实上，我们经常招募更多的实施者和其他专家加入工作组，以确保将更广泛的观点纳入讨论。因此，投票根本不现实。我们还决定达成共识（尽管有时是粗略的共识）是一件重要的事情。最后的决定应该在邮件列表上做出，这强化了我们通过查看未解决的问题而不是计算人头来达成共识的想法。我们有时会进行非正式投票，以了解讨论的方向，但我们尽量不将投票视为决定问题的投票。当我们面对面讨论事情时，我们也不想在那里投票；我们想表明我们正在达成共识。所以，有时候，为了强化我们不是在投票，而不是举手的观念，我们经常“哼”。
However, more and more we see people who think that a hum is a sort of anonymous vote, with some chairs calling every question they have for the working group by asking for a hum and judging the result by the loudest hum, even saying things like, "There were lots of hums for choice 1 and very few hums for choice 2, so it sounds like we have rough consensus for choice 1." This misses some really important points of using humming and is almost certainly mis-assessing the consensus. Hums should not be used as votes.
然而，我们越来越多地看到人们认为嗡嗡声是一种匿名投票，一些主席通过发出嗡嗡声并根据最大的嗡嗡声判断结果，向工作组提出每一个问题，甚至说，“选择1的哼唱声很多，选择2的哼唱声很少，所以听起来我们对选择1有大致的共识。”这忽略了使用哼唱的一些真正重要的要点，几乎可以肯定是对共识的错误评估。哼唱声不应该被用作投票。
So, why should we engage in this strange practice of humming? What are good reasons to "take a hum"? One reason is pragmatic. Quite often, a chair is faced with a room full of people who seem to be diametrically opposed on some choice facing the group. In order to find a starting place for the conversation, it can be useful for the chair to ask for a hum to see if one of the choices already has a stronger base of support than the other (or any significant base of support at all, for that matter). Sometimes the hum can tell a chair
那么，我们为什么要进行这种奇怪的哼唱呢？“哼哼”的好理由是什么？一个原因是务实。很多时候，一张椅子面对的是一屋子人，他们似乎在面对群体的某些选择上截然相反。为了找到对话的起点，主席可以要求哼唱，看看其中一个选项是否比另一个选项有更强大的支持基础（或者任何重要的支持基础）。有时，嗡嗡声能分辨出椅子的声音
that the room isn't all that contentious after all, that it's just a few voices who were being especially vociferous during the initial discussion.
房间里毕竟不是那么有争议，只是一些声音在最初的讨论中特别吵闹。
Sometimes, the hum will make it clear that choice "foo" has a significant amount more support than choice "bar", and it is therefore likely easier to start the discussion by saying, "OK, 'foo' seems to have quite a bit of support. Let's have the people that think 'foo' is a bad idea come up and tell us why it is problematic." At that point, the group can start going through the issues and see if any of them are showstoppers. It could always turn out that one of the objections is instantly recognized by the entire group as a fatal flaw in "foo" and the group will then turn to a discussion of the merits (and demerits) of "bar" instead. All that the hum does is give the chair a starting point: The hum indicated that there were less objections to "foo" than to "bar" at the beginning of the discussion, so starting with the objections to "foo" might shorten the discussion.
有时，嗡嗡声会清楚地表明，选择“foo”比选择“bar”有更多的支持，因此，开始讨论时可能更容易说，“好吧，'foo'似乎有相当多的支持。让我们让那些认为“foo”是个坏主意的人来告诉我们为什么它有问题。”，小组可以开始讨论这些问题，看看是否有任何问题是阻碍展示的。结果可能是，整个团队都会立即将其中一个反对意见视为“foo”中的致命缺陷，然后团队会转而讨论“bar”的优点（和缺点）。hum所做的只是为主席提供了一个起点：hum表明在讨论开始时对“foo”的反对比对“bar”的反对要少，因此从对“foo”的反对开始可能会缩短讨论。
Another good reason for us to hum is because it actually gives the chair the opportunity to take the temperature of the room. A smaller bunch of loud hums for choice A and a larger number of non-committal hums for choice B might indicate that some people believe that there are serious problems with choice B, albeit the more popular by sheer number of people. The chair might decide that starting with choice A and getting objections to it is the easier path forward and more likely to result in consensus in the end. Remember, coming to consensus is a matter of eliminating disagreements, so the chair wants to choose the path that gets to the least objections fastest. A bunch of people who are not strongly committed to B might have no real technical objection to A, even though it is not their first preference. There is always a chance that this could be misleading, or even abused, because some people are more willing to hum loudly than others (just by dint of personality), or that one of the quieter hums actually turns out to be a show-stopper that makes the original choice impossible. However, keep in mind that taking the hum in this case is to figure out how to start the conversation. The chair could always be surprised because the hum turns out to be unanimous and no further discussion is needed. Otherwise, the hum begins the discussion, it doesn't end it.
我们哼哼的另一个很好的理由是，它实际上给了椅子测量房间温度的机会。选择A的一小部分响亮的嗡嗡声和选择B的大量非承诺性嗡嗡声可能表明一些人认为选择B存在严重问题，尽管从人数上看，选择B更受欢迎。主席可能会决定，从选择A开始并获得反对意见是更容易的前进道路，最终更有可能达成共识。请记住，达成共识是消除分歧的问题，因此主席希望选择最快达成最少反对意见的途径。一群对B没有强烈承诺的人可能对A没有真正的技术异议，即使这不是他们的第一选择。这总是有可能误导甚至滥用，因为有些人比其他人更愿意大声哼唱（仅仅凭借个性），或者一种更安静的哼唱实际上是一种阻碍表演的声音，使得最初的选择变得不可能。但是，请记住，在这种情况下，发出嗡嗡声是为了找出如何开始对话。主席总是会感到惊讶，因为嗡嗡声是一致的，不需要进一步讨论。否则，嗡嗡声会开始讨论，但不会结束讨论。
But couldn't all of the above could have been done with a show of hands instead of a hum? Absolutely. Indeed, on a mailing list there is no way to use humming and so a different kind of polling would be needed. Even in face-to-face situations, sometimes we do use a show of hands. But there are more symbolic reasons for using a hum instead of a show of hands when face-to-face: Of course, a chair could get the temperature of the room by doing a show of hands too,
但是，难道不能用举手而不是嗡嗡声来完成上述所有工作吗？绝对地事实上，在邮件列表中没有办法使用哼唱，因此需要一种不同的投票方式。即使在面对面的情况下，有时我们也会举手示意。但面对面时，用嗡嗡声代替举手还有更多象征性的原因：当然，椅子也可以通过举手来测量房间的温度，
and knowing who specifically feels one way or another can help a good chair guide the subsequent conversation. However, a show of hands might leave the impression that the number of people matters in some formal way. A chair and a working group with a solid understanding of how consensus works can certainly do a show of hands and achieve exactly the same result as a hum. But with less experienced folks, a show of hands can end up reinforcing the mistaken notion that a vote is taking place. A chair can always take the hum and then later ask for specific folks to identify themselves to elicit more discussion. The advantage of the hum is that it makes it perfectly clear that the chair is simply figuring out the direction of the conversation.
知道谁特别有这样或那样的感觉可以帮助一个好的椅子指导接下来的对话。然而，举手可能会给人留下这样的印象：人数在某种形式上很重要。一位主席和一个对共识如何运作有着坚实理解的工作组当然可以举手示意，并取得与哼唱完全相同的结果。但对于经验不足的人来说，举手表决最终会强化投票正在进行的错误观念。椅子总是可以发出嗡嗡声，然后要求特定的人确认自己的身份，以引发更多的讨论。嗡嗡声的优势在于，它可以清楚地表明，椅子只是在计算对话的方向。
This also points to another misuse of any kind of informal polling: If the chair is already convinced that the group has come to consensus, there isn't much reason to take a poll. In fact, taking a poll can serve to discourage those who might be in the minority from voicing their concerns to the group in the face of a large majority who wants to move forward. Often, the right thing for the chair to do if they already sense consensus is to say, "It sounds to me like we have consensus for choice A. Does anybody have any concerns about or objections to going with A?" This allows folks to bring up issues to the group that the chair might have mistakenly missed without having them feel that the majority has "already spoken".
这也表明了对任何形式的非正式投票的另一种滥用：如果主席已经确信该小组已经达成共识，那么就没有太多理由进行投票。事实上，进行民意调查可以阻止那些可能属于少数群体的人在大多数人希望进步的情况下向该群体表达他们的担忧。通常，如果主席已经感觉到共识，那么他们应该做的正确的事情是说，“在我看来，我们对选择A有共识。有人对选择A有任何担心或反对吗？”这使得人们可以向小组提出主席可能错误地遗漏的问题，而不会让他们觉得大多数人已经“发言”。
The reverse situation can also have similar advantages and disadvantages: Sometimes a chair (say, of a birds-of-a-feather session, or a working group discussing a new proposed document) might want to make sure that there really is a good base of support to go forward with a proposal, and takes a hum. This can let the chair see if there are more than a handful of active people who are really interested in the new work. However, this has pitfalls as well: Someone may be dissuaded from raising what could be an essential concern if they feel that the group is overwhelmingly in favor of going forward, or conversely some folks may decide to "hum along with the crowd" even though they're not committed to the outcome. Indeed, the formulation, or even the order, of questions asked during a hum can have huge effects on the outcome: Asking simply, "Who supports going forward with this proposal?", and asking it first, can itself cause more people to hum in the affirmative than would for differently formulated questions, or asking the same question after some more "negatively" framed questions. 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.
相反的情况也可能有类似的优点和缺点：有时主席（比如说，一场势均力敌的会议，或一个讨论新提议文件的工作组）可能希望确保确实有一个良好的支持基础来推进一项提议，并发出嗡嗡声。这可以让主席看看是否有超过少数活跃的人真正对新工作感兴趣。然而，这也有陷阱：如果有人觉得团队中绝大多数人都赞成继续前进，他们可能会被劝阻，不去提出可能是一个基本问题的问题，或者相反，一些人可能会决定“随大流”，即使他们不致力于结果。事实上，在哼唱过程中提出的问题的形式，甚至顺序，都会对结果产生巨大影响：简单地问“谁支持推进这项提案？”并先问它，其本身就可能导致更多的人对哼唱持肯定态度，而不是对不同形式的问题，或者再问同样的问题“消极”的框架问题。任何形式的投票，无论是哼哼或举手，都必须谨慎进行，并且几乎总是用于提示讨论和问题，而不是总结问题。
There are times where the result of a hum is a pretty even split. In practical terms, that means it doesn't matter where the chair starts the discussion. And in fact, we've had working groups where a coin
有时，嗡嗡声的结果是相当均匀的分裂。实际上，这意味着主席从哪里开始讨论并不重要。事实上，我们已经成立了工作组
flip decided which proposal to start with. That doesn't mean that the coin flip determined the outcome; if a fatal technical flaw was found in the solution that won the coin flip, it is still incumbent upon the group to address the issue raised or abandon that solution and find another. Rough consensus on the technical points, in the end, is always required. Any way to find a place to start, be it the hum or the coin flip, is only getting to the beginning of the discussion, not the end.
flip决定从哪个提案开始。这并不意味着掷硬币决定了结果；如果在赢得掷硬币的解决方案中发现致命的技术缺陷，集团仍有责任解决提出的问题，或放弃该解决方案，寻找另一个解决方案。最终，在技术问题上达成大致的共识是必须的。任何找到起点的方法，无论是嗡嗡声还是抛硬币，都只是讨论的开始，而不是结束。
We don't try to reach consensus in the IETF as an end in itself. We use consensus-building as a tool to get to the best technical (and sometimes procedural) outcome when we make decisions. Experience has shown us that traditional voting leads to gaming of the system, "compromises" of the wrong sort as described earlier, important minority views being ignored, and, in the end, worse technical outcomes.
我们不试图在IETF中达成共识，这本身就是目的。当我们做出决策时，我们将建立共识作为一种工具，以获得最佳的技术（有时是程序）结果。经验告诉我们，传统投票会导致系统博弈，如前所述，“妥协”是错误的，重要的少数派观点被忽视，最终导致更糟糕的技术结果。
Coming to consensus by looking for objections, tracking open issues, and using hums as the start of discussions and not the end can all take some patience. Indeed, sometimes objection-based or issue-based decision making can be extremely difficult because there can be large factions who have diametrically opposed views. And there is no doubt that we do see some amount of political compromise (that is, the undesirable kind of compromise) from time to time in the IETF.
通过寻找反对意见、跟踪未解决的问题以及将哼哼作为讨论的开始而不是结束来达成共识都需要一些耐心。事实上，有时基于反对或基于问题的决策可能非常困难，因为可能会有意见截然相反的大派别。毫无疑问，我们确实在IETF中不时看到一些政治妥协（即不受欢迎的妥协）。
However, accepting these things has its price. When we decide that a discussion is too factious and opt to simply go with a majority, it creates more polarized arguments in the future: Instead of working toward the best technical outcome that most everyone can accept, people are much quicker to run to opposing sides and dig in to their positions. And when we allow real technical issues to drop because proponents have simply capitulated or have "horse-traded" to allow other technical problems to remain, the end product is weaker. Though the IETF can never be perfectly principled with regard to rough consensus, failing to be vigilant about sticking to the principles makes it increasingly hard to stick to them in the future, and ends us up with worse technical output.
然而，接受这些东西是有代价的。当我们认为一场讨论太有争议，而选择简单地以多数票进行时，它会在未来产生更多两极分化的争论：人们不会朝着大多数人都能接受的最佳技术结果努力，而是会更快地跑到对立的一边，并坚持自己的立场。当我们允许真正的技术问题下降，因为支持者只是投降或“马匹交易”以允许其他技术问题继续存在时，最终产品就变弱了。尽管IETF在粗略的共识方面永远不可能有完美的原则，但如果对坚持原则不保持警惕，未来就越来越难坚持这些原则，并最终导致我们的技术产出更差。
Again, coming to consensus is not the goal in itself. Coming to consensus is what we do during our processes to arrive at the best solution. In particular, "declaring" consensus is not an end goal. Attempts to declare consensus at the end of a discussion just for the sake of being able to say that there is consensus often get us back into the voting mentality that we're trying to avoid.
再次强调，达成共识本身并不是目标。达成共识是我们在过程中为达成最佳解决方案所做的事情。特别是，“宣布”共识不是最终目标。试图在讨论结束时宣布共识，只是为了能够说有共识，这往往会让我们回到我们试图避免的投票心态。
We often hear chairs say that they are making a "consensus call". Sometimes, they simply mean they are making a call _of_ the consensus; that is, they are declaring the consensus that has, in their view, been reached when the discussion has reached an end. That's a fine thing and what chairs are supposed to do: They are "calling" the consensus. Sometimes, when a chair says that they are making a "consensus call", the chair is actually making a call _for discussion_ of a particular point in order to reach consensus. Although it's a bit odd to call that a "consensus call" (as opposed to a "call for discussion" or the like), it is fine for a chair to occasionally identify a particular point of contention and get the group to focus discussion on it in order to reach consensus. But more and more often, we hear chairs say that they are making a "consensus call" at the end of a discussion, where the chair will pose the classic "Who is in favor of choice A? Who is in favor of choice B?" questions to the working group. That's not really a "consensus call", and has the same potential problems as the "hum" at the end of a discussion: It can be tantamount to asking for a vote. Even talk of "confirming consensus" has this problem: It implies that you can confirm that there is consensus by counting people, not issues. The important thing for a chair to do is to "call consensus" in the sense of declaring the consensus; others can always object and say that the chair has gotten the consensus wrong and ask for reconsideration. However, the chair ought to be looking for consensus throughout the discussion, not asking for it at the end.
我们经常听到主席们说，他们正在进行“协商一致呼吁”。有时，他们只是简单地说，他们在呼吁达成共识；也就是说，他们正在宣布他们认为在讨论结束时已经达成的共识。这是一件好事，也是主席们应该做的：他们正在“呼唤”共识。有时，当主席说他们正在发出“共识呼吁”时，主席实际上是在就某一点发出“讨论呼吁”，以达成共识。尽管称之为“共识呼吁”有点奇怪（与“呼吁讨论”或类似的呼吁相反），但主席偶尔确定一个特定的争论点并让小组集中讨论以达成共识是可以的。但越来越多的情况下，我们听到主席们说，他们正在讨论结束时发出“共识呼吁”，主席将向工作组提出经典的“谁赞成选择a？谁赞成选择B？”问题。这不是一个真正的“共识呼吁”，与讨论结束时的“嗡嗡声”有着同样的潜在问题：这可能等同于要求投票。即使是“确认共识”的说法也有一个问题：它意味着你可以通过计算人而不是问题来确认存在共识。主席要做的重要事情是在宣布共识的意义上“呼吁共识”；其他人总是会反对，说主席的共识是错误的，并要求重新考虑。然而，主席应该在整个讨论过程中寻求共识，而不是在最后要求达成共识。
There are some times where chairs will ask a question or take a poll toward the end of a discussion in order to figure out the state of consensus, but this must be done with extreme caution. This is discussed in the next section.
有些时候，主席会在讨论结束时提出问题或进行民意调查，以确定共识的状态，但这必须非常谨慎。这将在下一节中讨论。
6. One hundred people for and five people against might not be rough consensus
6. 100人赞成，5人反对，这可能不是一个粗略的共识
Section 3 discussed the idea of consensus being achieved when objections had been addressed (that is, properly considered, and accommodated if necessary). Because of this, using rough consensus avoids a major pitfall of a straight vote: If there is a minority of folks who have a valid technical objection, that objection must be dealt with before consensus can be declared. This also reveals one of the great strengths of using consensus over voting: It isn't possible to use "vote stuffing" (simply recruiting a large number of people to support a particular side, even people who have never participated in a working group or the IETF at all) to change the outcome of a consensus call. As long as the chair is looking for outstanding technical objections and not counting heads, vote stuffing shouldn't affect the outcome of the consensus call.
第3节讨论了在处理反对意见时达成共识的想法（即，适当考虑并在必要时予以采纳）。正因为如此，使用粗略的共识避免了直接投票的一个主要陷阱：如果有少数人持有有效的技术性反对意见，那么在宣布共识之前，必须先处理这些反对意见。这也揭示了使用共识而非投票的一大优势：不可能使用“填票”（简单地招募大量的人来支持某一方，即使是从未参加过工作组或IETF的人）来改变共识电话的结果。只要主席在寻找悬而未决的技术反对意见，并且不计算人头数，选票填充就不应该影响协商一致呼吁的结果。
So, in a large working group with over 100 active participants and broad agreement to go forward with a particular protocol, if a few participants say, "This protocol is going to cause congestion on the network, and it has no mechanism to back off when congestion occurs; we object to going forward without such a mechanism in place", and the objection is met with silence on the mailing list, there is no consensus. Even if the working group chair makes a working group "last call" on the document, and 100 people actively reply and say, "This document is ready to go forward", if the open issue hasn't been addressed, there's still no consensus, not even rough consensus. It's the existence of the unaddressed open issue, not the number of people, which is determinative in judging consensus. As discussed earlier, you can have rough consensus with issues that have been purposely dismissed, but not ones that have been ignored.
因此，在一个拥有100多名积极参与者的大型工作组中，如果少数参与者说，“该协议将在网络上造成拥塞，并且在拥塞发生时没有回退机制；我们反对在没有这样一个机制的情况下继续进行”，而反对意见在邮件列表上被沉默，没有达成共识。即使工作组主席对该文件作出工作组“最后呼吁”，100人积极回应并说，“该文件准备好继续”，如果尚未解决未决问题，仍然没有达成共识，甚至没有大致的共识。这是一个尚未解决的公开问题的存在，而不是人数，这是判断共识的决定性因素。如前所述，您可以对故意忽略的问题达成大致共识，但不能对被忽略的问题达成一致。
This brings us back to when a poll could be used (cautiously) at the end of a discussion. Let's say a discussion has been ongoing for some time, and a particular objection seems to be holding up the decision. A diligent chair who's been carefully listening to the discussion might think, "I have heard person X make this objection, and I've heard responses from many other folks that really address the issue. I think we have rough consensus. But the objection keeps coming up. Maybe it's just the one person getting up again and again with the same argument, but maybe we don't have rough consensus. I'm not sure." At this point, the chair might ask for a hum. If only a single hum objecting can be heard, even a loud one, in the face of everyone else humming that the objection has been answered, the chair has pretty good reason to believe that they heard the single objection all along and it really has been addressed. However, to say immediately after the hum, "It sounds like we have rough consensus" and nothing else is at best being slipshod: What the chair really needs to say at that point is, "I believe the only objection we've heard is A (coming from person X), and I've heard answers from the group that fully address that issue. So, unless I hear a different objection than the one I've just described, I find that there is rough consensus to move on." That leaves the door open for someone to tell the chair that the objection was really on different grounds and they misevaluated, but it makes it clear that the chair has found rough consensus due to the discussion, not due to the hum. Again, it's not the hum that ends things, it's that the issues have been addressed. If the small minority (even one person) still has an issue that hasn't been addressed, rough consensus still hasn't been achieved.
这让我们回到了什么时候可以在讨论结束时（谨慎地）使用民意测验。比如说，一场讨论已经进行了一段时间，一个特别的反对意见似乎阻碍了这一决定。一位认真聆听讨论的勤奋主席可能会想，“我听到X个人提出了这一反对意见，我也听到了许多其他人的回应，他们真正解决了这个问题。我认为我们有大致的共识。但反对意见不断出现。也许只是一个人一次又一次地站起来，提出同样的论点，但也许我们没有大致的共识。我不确定。“此时，椅子可能会发出嗡嗡声。如果只有一个嗡嗡声反对，即使是一个响亮的声音，面对所有其他人嗡嗡声反对已经被回答，主席有很好的理由相信他们一直都听到了一个反对，并且它确实得到了解决。然而，在嗡嗡声之后马上说，“听起来我们有大致的共识”，而没有什么别的东西是随意的：主席当时真正需要说的是，“我相信我们听到的唯一反对意见是A（来自X个人），我听到了该小组的回答，充分解决了这一问题。因此，除非我听到与我刚才描述的不同的反对意见，否则我发现大家有大致的共识可以继续。”这为有人告诉主席，反对意见的理由真的不同，并且他们评估错误提供了机会，但它清楚地表明，由于讨论，而不是由于嗡嗡声，主席已经找到了大致的共识。再说一遍，结束事情的不是嗡嗡声，而是问题已经解决了。如果一小部分人（即使是一个人）仍然有一个问题没有得到解决，那么仍然没有达成大致的共识。
Even if no particular person is still standing up for an issue, that doesn't mean an issue can be ignored. As discussed earlier, simple capitulation on an issue is not coming to consensus. But even in a case where someone who is not an active participant, who might not
即使没有特定的人仍然支持某个问题，这并不意味着某个问题可以被忽略。如前所述，在一个问题上简单的投降并没有达成共识。但即使是在一个不是积极参与者的情况下，谁也可能不是
care much about the fate of the work, raises a substantive issue and subsequently disappears, the issue needs to be addressed before the chair can claim that rough consensus exists.
非常关心工作的命运，提出了一个实质性问题，随后又消失了，在主席能够声称存在粗略的共识之前，需要解决这个问题。
7. Five people for and one hundred people against might still be rough consensus
7. 5人赞成，100人反对可能仍然是大致的共识
This one is the real mind-bender for most people, and certainly the most controversial. Say there is a very small working group, one with half a dozen truly active participants who are experts in the field; everybody else is just following along but not contributing to the discussion. The active folks come up with a protocol document that they all agree is the right way forward, and people inside and outside the working group agree that the protocol is likely to get widespread adoption; it is a good solution to a real problem, even if the non-experts don't have the ability to fully judge the details.
对大多数人来说，这是一个真正令人心醉的故事，当然也是最有争议的。假设有一个非常小的工作组，其中有六个真正积极的参与者，他们都是该领域的专家；其他人只是跟着讨论，但没有参与讨论。积极的人们提出了一份协议文件，他们都认为这是正确的前进方向，工作组内外的人都认为该协议可能会得到广泛采用；这是一个解决实际问题的好办法，即使非专家没有能力全面判断细节。
However, one of the active members has an objection to a particular section: The protocol currently uses a well-known algorithm to address an issue, but the objector has a very elegant algorithm to address the issue, one which works especially well on their particular piece of hardware. There is some discussion, and all of the other contributors say, "Yes, that is elegant, but what we're using now is well-understood, widely implemented, and it works perfectly acceptably, even on the objector's hardware. There is always some inherent risk to go with a new, albeit more elegant, algorithm. We should stick to the one we've got." The chair follows the conversation and says, "It sounds like the issue has been addressed and there's consensus to stick with the current solution." The objector is not satisfied, maybe even saying, "But this is silly. You've seen that my algorithm works. We should go with that." The chair makes the judgement that the consensus is rough, in that there is still an objector, but the issue has been addressed and the risk argument has won the day. The chair makes a working group last call.
然而，其中一个活跃成员对某一特定部分有异议：协议目前使用一个众所周知的算法来解决问题，但异议者有一个非常优雅的算法来解决问题，该算法在他们特定的硬件上特别有效。有一些讨论，所有其他贡献者都说，“是的，这很好，但我们现在使用的是被很好地理解、广泛地实现的，并且它可以完美地工作，甚至在反对者的硬件上。使用一个新的、尽管更优雅的算法总是存在一些固有的风险。我们应该坚持我们现有的算法。”主席在对话后说，“听起来问题已经解决了，大家一致同意坚持目前的解决方案。”反对者不满意，甚至可能会说，“但这很愚蠢。你已经看到我的算法是有效的。我们应该这样做。”主席作出判断，一致意见是粗糙的，在这一点上仍然有反对者，但问题已经得到解决，风险论点赢得了胜利。主席向工作组作最后的呼吁。
Then, the worst-case scenario happens. The objector, still unhappy that their preferred solution was not chosen, recruits one hundred people, maybe a few who were silent participants in the working group already, but mostly people who work at the same company as the objector and who never participated before. The objector gets them all to post a message to the list saying, "I believe we should go with the new elegant algorithm in section Z instead of the current one. It is more elegant, and works better on our hardware." The chair sees these dozens of messages coming in and posts a query to each of them: "We discussed this on the list, and we seemed to have consensus that, given the inherent risk of a new algorithm, and the widespread deployment of this current one, it's better to stick with the current one. Do you have further information that indicates
然后，最坏的情况发生了。反对者仍然对没有选择他们喜欢的解决方案感到不满，他招募了100人，也许其中一些人已经是工作组的沉默参与者，但大多数人与反对者在同一家公司工作，而且以前从未参与过。反对者让他们所有人都在列表中发布一条消息，说：“我认为我们应该使用Z部分中的新的优雅算法，而不是当前的算法。它更优雅，在我们的硬件上工作得更好。”主席看到这几十条消息进来，并向他们每个人发布一条查询：“我们在清单上讨论了这一点，我们似乎达成了共识，即考虑到新算法的固有风险，以及当前算法的广泛部署，最好还是坚持使用当前算法。您是否有进一步的信息表明
something different?" And in reply the chair gets utter silence. These posters to the list (say, some of whom were from the company sales and marketing department) thought that they were simply voting and have no answer to give. At that point, it is within bounds for the chair to say, "We have objections, but the objections have been sufficiently answered, and the objectors seem uninterested in participating in the discussion. Albeit rough in the extreme, there is rough consensus to go with the current solution."
有什么不同？”作为回答，主席沉默了。名单上的这些海报（比如，其中一些来自公司销售和营销部门）认为他们只是在投票，没有答案。在这一点上，主席可以说：“我们有异议，但反对意见已得到充分答复，反对者似乎对参与讨论不感兴趣。尽管极端粗糙，但目前的解决方案仍存在大致的共识。”
Though the above example uses the most extreme form of recruiting sheer numbers of people (i.e., from the sales and marketing department), the same principle should hold true no matter how new or how credible the objectors seem: The chair is trying to discover whether objections have been addressed or if there are still open issues. If, instead of a bunch of sales and marketing people, the new people to the conversation are developers or others who are directly involved in creating the technology, or even folks who have been participating the entire time whose knowledge of the technology is not in question at all, the principle is still the same: If the objection has been addressed, and the new voices are not giving informed responses to that point, they can still justifiably be called "in the rough". Of course, the more involved and knowledgable the objectors are, the more difficult it will be for the consensus caller to make the call, but a call of rough consensus is reasonable. The chair in this case needs to understand what the responses mean; only sufficiently well-informed responses that justify the position taken can really "count".
尽管上面的例子使用了最极端的招聘形式（即从销售和市场营销部门招聘），但无论反对者看起来多么新或多么可信，同样的原则都应该适用：主席试图发现反对意见是否已得到解决，或者是否仍然存在未决问题。如果谈话中的新参与者不是一群销售和营销人员，而是直接参与技术开发的开发人员或其他人，甚至是一直参与技术开发的人员，他们的技术知识根本没有问题，原则仍然是一样的：如果反对意见得到了解决，而新的声音没有对这一点作出知情的回应，它们仍然可以被称为“粗略的”。当然，反对者的参与度和知识水平越高，达成共识的人就越难做出呼吁，但达成大致共识是合理的。在这种情况下，主席需要理解答复的含义；只有充分了解情况、证明所采取立场正确的回应才能真正“起作用”。
There is no doubt that this is the degenerate case and a clear indication of something pathological. But, this is precisely what rough consensus is ideally suited to guard against: vote stuffing. In the presence of an objection, the chair can use their technical judgement to decide that the objection has been answered by the group and that rough consensus overrides the objection. Now, the case described here is probably the hardest call for the chair to make (how many of us are willing to make the call that the vast majority of people in the room are simply stonewalling, not trying to come to consensus?), and, if appealed, it would be incredibly difficult for the appeals body to sort out. Indeed, it is likely that if a working group got this dysfunctional, it would put the whole concept of coming to rough consensus at risk. But still, the correct outcome in this case is to look at the very weak signal against the huge background noise in order to find the rough consensus.
毫无疑问，这是一个退化的病例，是某种病理现象的明确迹象。但是，这正是粗略的共识最适合防止的：选票填充。在存在异议的情况下，主席可以使用其技术判断来决定该异议是否已由工作组回答，并且大致一致意见是否凌驾于异议之上。现在，这里描述的案例可能是主席最难做出的呼吁（我们中有多少人愿意做出这个呼吁，而在座的绝大多数人只是在拖延，而不是试图达成共识？），而且，如果上诉，上诉机构将难以解决。事实上，如果一个工作组出现这种功能失调的情况，很可能会危及达成粗略共识的整个概念。但是，在这种情况下，正确的结果是在巨大的背景噪声中观察非常微弱的信号，以便找到大致的一致意见。
Although this document talks quite a bit about the things chairs, working groups, and other IETF participants might do to achieve rough consensus, this document is not really about process and procedures. It describes a way of thinking about how we make our decisions. Sometimes, a show of hands can be useful; sometimes, it can be quite damaging and result in terrible decisions. Sometimes, using a device like a "hum" can avoid those pitfalls; sometimes, it is just a poorly disguised vote. The point of this document is to get all of us to think about how we are coming to decisions in the IETF so that we avoid the dangers of "majority rule" and actually get to rough consensus decisions with the best technical outcomes.
尽管本文件大量讨论了主席、工作组和其他IETF参与者为达成大致共识可能会做的事情，但本文件并不是关于过程和程序。它描述了一种思考我们如何做出决定的方式。有时，举手示意会很有用；有时，它会造成相当大的损害，并导致糟糕的决定。有时，使用“嗡嗡声”这样的设备可以避免这些陷阱；有时，这只是一次伪装得很糟糕的投票。本文件的目的是让我们大家思考如何在IETF中做出决策，从而避免“多数规则”的危险，并以最佳的技术成果做出大致一致的决策。
"He who defends with love will be secure." -- Lao Tzu
“用爱来保卫的人是安全的。”——老子
[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>.
[Clark]Clark，D.，“一个浑浊的水晶球——未来的愿景”，《第二十四届互联网工程特别工作组会议录》，第539-543页，1992年7月<http://www.ietf.org/proceedings/24.pdf>.
[RFC1603] Huizer, E. and D. Crocker, "IETF Working Group Guidelines and Procedures", RFC 1603, March 1994.
[RFC1603]Huizer，E.和D.Crocker，“IETF工作组指南和程序”，RFC 1603，1994年3月。
[RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.
[RFC2418]Bradner，S.，“IETF工作组指南和程序”，BCP 25，RFC 2418，1998年9月。
[Sheeran] Sheeran, M., "Beyond Majority Rule: Voteless Decisions in the Religious Society of Friends", ISBN 978-0941308045, December 1983.
[Sheeran]Sheeran，M.，“超越多数规则：宗教之友协会中的无投票决定”，ISBN 978-09413080451983年12月。
This document is the result of conversations with many IETF participants, too many to name individually. I greatly appreciate all of the discussions and guidance. I do want to extend special thanks to Peter Saint-Andre, who sat me down and pushed me to start writing, and to Melinda Shore for pointing me to "Beyond Majority Rule" [Sheeran], which inspired some of the thinking in this document.
本文件是与许多IETF参与者对话的结果，这些参与者太多，无法单独命名。我非常感谢所有的讨论和指导。我要特别感谢彼得·圣安德烈（Peter Saint Andre），他让我坐下来，推动我开始写作，并感谢梅琳达·肖尔（Melinda Shore）为我指出了“超越多数规则”[Sheeran]，这激发了本文中的一些思考。
Author's Address
作者地址
Pete Resnick Qualcomm Technologies, Inc. 5775 Morehouse Drive San Diego, CA 92121 US
Pete Resnick高通技术有限公司，美国加利福尼亚州圣地亚哥Morehouse大道5775号，邮编92121
Phone: +1 858 651 4478
EMail: presnick@qti.qualcomm.com
Phone: +1 858 651 4478
EMail: presnick@qti.qualcomm.com