[要約] RFC 7282は、IETFにおける合意形成と議論の方法についてのガイドラインです。その目的は、IETFのプロトコル開発プロセスを円滑化し、効果的な意思決定を促進することです。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Lack of disagreement is more important than agreement . . . . 4
3. Rough consensus is achieved when all issues are addressed,
but not necessarily accommodated . . . . . . . . . . . . . . 7
4. Humming should be the start of a conversation, not the end . 10
5. Consensus is the path, not the destination . . . . . . . . . 13
6. One hundred people for and five people against might not be
rough consensus . . . . . . . . . . . . . . . . . . . . . . . 14
7. Five people for and one hundred people against might still be
rough consensus . . . . . . . . . . . . . . . . . . . . . . . 16
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. Informative References . . . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19
Almost every IETF participant knows the aphorism from Dave Clark's 1992 plenary presentation [Clark] regarding how we make decisions in the IETF:
ほとんどすべてのIETF参加者は、IETFでどのように意思決定を行うかに関するDave Clarkの1992年本会議[Clark]の格言を知っています。
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.
つまり、私たちの信条は、1人の個人が決定（王または大統領）を指示することも、投票によって決定を行うことも、実務経験のない真空で決定を下すことも望まないということです。代わりに、すべての参加者の同意を得て決定を下すように努めますが、多少の異論（大まかなコンセンサス）を考慮に入れ、エンジニアリング（実行コード）の実際の製品が理論設計よりも優先されるようにします。
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.
コンセンサスに達し、「妥協」することについても、重要なポイントがあります。残念ながら、「妥協」という言葉は2つの異なる方法で使用されます。コンセンサスに到達するために妥協することは良いことですが、もう一方は重要です。コンセンサスを達成するための妥協は、実際には有害な場合があります。先に述べたように、エンジニアリングには常にトレードオフのバランスが含まれ、あるエンジニアリングの決定が別のエンジニアリングの決定と比較してバランスが取れているかどうかを把握するには、エンジニアリングの「妥協」が必要です。プロセッサの速度を犠牲にして消費電力を下げるか、スループットを犠牲にして輻輳耐性を確保する必要がある。これらの種類の妥協点はエンジニアリングの選択の1つであり、予想され、不可欠です。私たちは常にトレードオフを比較検討し、要件の完全なセットを最もよく満たすセットを集合的に選択したいと考えています。
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.
さらに悪いのは、「競馬」の妥協案です。「私はそのような理由であなたの提案に反対します。あなたはこの理由で私の提案に反対します。どちらも同意しません。私の提案、私はあなたの提案に反対するのをやめ、私たちはそれらを両方に入れます。」それでもやはり「合意」のような結果になりますが、未解決の未解決の問題が1つだけではなく、この種の妥協案では2つになり、便宜上それらを無視します。
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を使用する利点と比較して、それは価値がありません。」議長が技術的な判断で問題が真に検討されており、ワーキンググループの大多数が、その人からの継続的な反対に直面しても、トレードオフの価値があるという結論に達した場合s）問題を提起した人は、議長はグループが大まかなコンセンサスに達したことを宣言できます。 （そして、これは「大多数の大多数」という観点からフレーム化されていますが、それは必ずしも真実ではありません。この点はセクション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のコンセンサスでは、すべての参加者が同意する必要はありませんが、これはもちろん望ましいことです。一般に、ワーキンググループの支配的な見方が優先されます。 （ただし、「優位性」は、量や持続性に基づいて決定されるのではなく、より一般的な合意の感覚に基づいて決定されることに注意する必要があります。）コンセンサスは、投票、ハミング、またはその他の手段によって決定できます。 WGは同意します（もちろん、大まかなコンセンサスによって）。
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％がラフよりも優れていることに注意してください」と付け加えています。このドキュメントは、実際に投票するか、またはパーセンテージを見るだけでコンセンサスを「決定」できるという考えに実際には同意しません。頭を数えることは、大まかなコンセンサスがどうなるかについての良い推測を与えるかもしれませんが、そうすることで、重要な少数派の見解がノイズに負けてしまう可能性があります。コンセンサスモデルの強みの1つは、少数派の見解に対処することであり、大まかなコンセンサスモデルを使用しても、それが損なわれるべきではありません。このため、このドキュメントでは、特定の問題をサポートしている、またはサポートしていない人の数を数えるだけでなく、未解決の問題を検討することについて多くを述べています。これには、後続のセクションで説明する興味深い、驚くべき影響があります。
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.
では、なぜ私たちはこのハミングの奇妙な習慣に取り組むべきなのでしょうか？ 「ハミングする」正当な理由は何ですか？ 1つの理由は実用的です。かなり頻繁に、椅子は、グループが直面しているある選択について正反対に思われる人々でいっぱいの部屋に直面しています。会話の出発点を見つけるために、議長は、選択肢の1つがすでに他の選択肢よりも強力なサポート基盤を持っているかどうかを確認するためにハムを要求するのに役立つ場合があります（またはまったくサポートの重要な基盤、そのことについては）。時々ハムは、部屋が結局それほど不快ではないこと、最初の話し合いの間に特に騒々しかったのはほんの数声であることを椅子に伝えることができます。
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」よりもかなり多くのサポートを持っていることを明確にするので、「OK、 'foo'はかなりあるようだ「foo」は悪い考えだと思っている人に出てもらい、それがなぜ問題があるのか教えてみましょう。」その時点で、グループは問題の調査を開始し、それらのいずれかが見物人であるかどうかを確認できます。反対意見の1つが「foo」の致命的な欠陥としてグループ全体に即座に認識され、グループが「bar」のメリット（およびデメリット）についての議論に移ることが常に判明する可能性があります。ハムがすることはすべて、椅子に開始点を与えることです。ハムは、ディスカッションの最初に「bar」よりも「foo」に対する異議が少ないことを示したため、「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に深刻な問題があると考える人々がいることを示しているかもしれません。議長は、選択肢Aから始めてそれに異議を唱えるほうが簡単な方法であり、最終的には合意に至る可能性が高いと判断する場合があります。コンセンサスに到達することは不一致を排除することの問題であることを忘れないでください。そのため、議長は異論への反対が最も早くなるような道を選択したいと考えています。 Bに強くコミットしていない多くの人々は、それが彼らの最初の選好ではないとしても、Aに実際の技術的な異議を唱えることはないかもしれません。これは誤解を招く、または乱用される可能性が常にあります。人によっては他の人よりも大声で大声で口ずさむ意欲があるため（単に性格のせいで）、または静かな口笛の1つが実際にショーストッパーであることが判明する場合それは元の選択を不可能にします。ただし、この場合のハムを取ることは、会話を開始する方法を理解することであることに注意してください。ハムは満場一致であることが判明し、それ以上の議論は必要ないため、椅子は常に驚かれることでしょう。そうでなければ、ハムが議論を開始し、それはそれを終了しません。
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.
ハムの結果がかなり均等に分割される場合があります。つまり、議長がどこで議論を始めるかは問題ではありません。そして実際には、コインフリップがどの提案から始めるかを決定するワーキンググループがありました。コインフリップが結果を決定したという意味ではありません。コインフリップを獲得したソリューションに致命的な技術的な欠陥が見つかった場合でも、提起された問題に対処するか、そのソリューションを放棄して別のソリューションを見つけることは、依然としてグループの責任です。結局のところ、技術的なポイントに関する大まかなコンセンサスが常に必要です。開始する場所を見つける方法は、それがハムであろうとコインの裏返しであろうと、議論の始まりではなく終わりに過ぎません。
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では、異論に対処した（つまり、適切に検討され、必要に応じて対応された）ときに達成されるコンセンサスの考え方について説明しました。このため、大まかなコンセンサスを使用すると、直接投票の大きな落とし穴を回避できます。有効な技術的な異議を持つ少数の人々がいる場合、コンセンサスを宣言する前にその異議に対処する必要があります。これはまた、投票に関してコンセンサスを使用することの大きな強みの1つを明らかにします。「投票スタッフィング」（単にワーキンググループに参加したことのない人々や、 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がこの異議を唱えるのを聞いたし、問題に本当に取り組む他の多くの人々からの返答を聞いた。私たちは大まかなコンセンサスを持っていると思う。しかし、異議は続いている。たぶんそれは同じ議論で何度も何度も起きているだけの人かもしれませんが、多分私たちは大まかなコンセンサスを持っていません。私にはわかりません。」この時点で、椅子はハムを要求するかもしれません。異議申し立てに答えたとハミングする他のすべての人に直面して、ハムの異議申し立てが1つだけ聞こえた場合でも、大きな音であっても、椅子は、異議申し立てをすべて聞いたと信じる十分な理由があります。対処。しかし、ハムの直後に言うと、「大まかなコンセンサスがあるように聞こえます」というだけであり、せいぜい何もうまくいっていません。その時点で椅子が本当に言う必要があるのは、「私が聞いた唯一の異論は、 A（人Xから）と、その問題に完全に対処するグループからの回答を聞いたので、先ほど説明したものとは異なる異議を聞いていない限り、次に進むには大まかなコンセンサスがあることがわかります」これは、異議が実際には異なる根拠にあり、彼らが誤評価したことを誰かに椅子に伝えるためのドアを開いたままにしますが、椅子がハムのためではなく、議論のために大まかなコンセンサスを見つけたことは明らかです。繰り返しになりますが、物事を終わらせるのはハムではなく、問題が解決されたということです。少数派（1人でも）がまだ対処されていない問題を抱えている場合、大まかなコンセンサスはまだ達成されていません。
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.
これはほとんどの人にとって本当のマインドベンダーであり、確かに最も物議を醸しています。非常に小さなワーキンググループがあり、その分野の専門家である真にアクティブな参加者が6ダースいるとしましょう。他のすべての人は単にフォローしているだけですが、議論には貢献していません。積極的な人々は、すべてが正しい方法であることに同意し、ワーキンググループの内外の人々がプロトコルが広く採用される可能性があることに同意するプロトコルドキュメントを作成します。非専門家が詳細を完全に判断する能力を持っていない場合でも、それは実際の問題の良い解決策です。
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.
ただし、アクティブなメンバーの1人が特定のセクションに異議を唱えています。プロトコルは現在、問題に対処するためによく知られているアルゴリズムを使用していますが、異議申立人は問題に対処するための非常にエレガントなアルゴリズムを持っています。ハードウェアの一部。いくつかの議論があり、他のすべての貢献者は「はい、それはエレガントですが、現在使用しているものは十分に理解され、広く実装されており、オブジェクターのハードウェア上でも完全に許容範囲内で動作します。より洗練された新しいアルゴリズムを使用することには、いくつかの固有のリスクがあります。取得したアルゴリズムに固執する必要があります。」議長は会話に従い、「問題は解決されたようで、現在の解決策に固執するというコンセンサスがあるようです」と述べています。 「でもこれはばかげています。私のアルゴリズムが機能しているのを見てきました。私たちはそれに取り掛かるべきです。」議長は、反対意見はまだあるという点でコンセンサスは大まかなものであるとの判断を下しますが、問題は対処されており、リスクの議論は勝利を収めました。議長がワーキンググループに最後の電話をします。
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 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."
次に、最悪のシナリオが発生します。反対者は、彼らの好ましい解決策が選択されなかったことに不満を抱いており、100人、おそらくすでにワーキンググループのサイレント参加者である少数を募集していますが、ほとんどの場合、反対者と同じ会社で働いており、これまでに参加したことのない人々です。反対者は全員にリストにメッセージを投稿してもらい、「現在のアルゴリズムではなく、セクションZの新しいエレガントなアルゴリズムを使用する必要があると考えています。よりエレガントで、ハードウェア上でよりうまく機能します。」議長はこれらの数十のメッセージの着信を確認し、それぞれにクエリを投稿します。「これについてリストで議論しましたが、新しいアルゴリズムの固有のリスクと、この現在の広範な展開を考えると、コンセンサスがあるようです1つ、現在のものに固執する方が良いです。何か違うことを示す詳細情報はありますか？」そして返事として、椅子は完全に沈黙します。リストへのこれらのポスター（たとえば、会社の営業およびマーケティング部門からの人もいる）は、単に投票しているだけであり、回答することはできないと考えていました。その時点で、議長が「私たちは異議を唱えていますが、異議は十分に解決されており、反対者は議論に参加することに関心がないようです。極端に大雑把ではありますが、大まかなコンセンサスがあります。現在のソリューションで。」
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>.
[クラーク]クラークD.、「曇った水晶玉-未来のビジョン」、第24回インターネットエンジニアリングタスクフォースの議事録、539〜543ページ、1992年7月、<http://www.ietf.org/議事録/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 Working Group Guidelines and Procedures」、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.
[シーラン]シーランM.、「多数決を超えて：宗教協会の無所属議決」、ISBN 978-0941308045、1983年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参加者との会話の結果であり、個別に名前を付けるには多すぎます。すべての議論とガイダンスに感謝します。私を座らせて執筆を開始するように勧めたピーターサンタンドレと、このドキュメントの考えの一部に影響を与えた "Beyond Majority Rule" [Sheeran]を紹介してくれたMelinda Shoreに特に感謝します。 。
Author's Address
著者のアドレス
Pete Resnick Qualcomm Technologies, Inc. 5775 Morehouse Drive San Diego, CA 92121 US
Pete Resnick Qualcomm Technologies、Inc. 5775 Morehouse Drive San Diego、CA 92121 US
Phone: +1 858 651 4478
EMail: presnick@qti.qualcomm.com