]>

Melbourne Australia mnot@mnot.net https://mnot.net/

Urbana USA resnick@episteme.net https://episteme.net/

consensus rough consensus process decision This document specifies Best Current Practice for making decisions in IETF Working Groups. It updates . About This Document Status information for this document may be found at . information can be found at . Source for this draft and an issue tracker can be found at .

Introduction The IETF guides its decisions with "rough consensus and running code." However, does not explicitly define how that consensus is achieved; it only highlights the importance of "broad" consensus. is more detailed: While this guidance has served the IETF well for more than thirty years, the IETF community has grown, and our decisions increasingly affect people who do not participate in them. To help both participants and those who use our standards understand our process, this document outlines the procedures we use to make Working Group decisions in more detail. It is not intended to establish new policy, only articulate existing practices more carefully. Every document published in the IETF Stream carries a claim of IETF rough consensus; see . Working Group decisions are where most of that consensus is built, and this document describes how they are made. This document replaces . Most of that text remains accurate. Three aspects of it, however, are not carried forward: practice has diverged from them, and they have proven misleading. Consensus is not determined by the "dominant view" prevailing; objections are addressed on their merits, and the number of participants holding a view is not what settles the question. A show of hands, a hum, or a poll does not determine consensus; such mechanisms gauge support, which is one input to a determination made by the consensus caller (see ). And no proportion of the group -- neither 51% nor 99% -- establishes or fails to establish rough consensus, because it is not a vote. outlines the principles that guide the rest of this document. provides guidelines for making decisions that require consensus; notes the kinds of decisions that do not require consensus. This document describes decision making in Working Groups. It does not describe how the IESG or the IAB make decisions; those bodies have their own documented procedures (see and ).

Principles This section establishes the principles for decision making at the IETF. The openness of the IETF has significant influence on our decision-making process. Because we have no concept of membership and anyone can participate, decision making by voting is inappropriate -- it would make our processes vulnerable to rule by majority and vote stuffing. Instead, we use a consensus process, described in . This assures that viewpoints are heard and considered. This is not a representative process: the IETF's legitimacy rests upon its expertise and the success of its output, rather than representative input. As a result, the number of people supporting or objecting on any given issue is not essential to the decision of whether rough consensus exists. While a significant number of people stating objections may give a consensus caller pause regarding whether a particular issue has achieved rough consensus, the objection must still be evaluated on its merits to determine whether it has been addressed by the remainder of the group. Conversely, while a very small number of people, or even a single person, objecting might point toward rough consensus being achieved, any outstanding objection still needs to be addressed. Our work must also conclude. We use "rough consensus" because requiring unanimity would allow any single objection to stop the work. An outstanding objection is not sufficient on its own to show lack of rough consensus. If the objection has been heard, understood, and addressed (even if not accommodated), rough consensus can still be declared. We do not recognise authorities. A statement of support or an objection is not accepted merely on the basis of the title or purported expertise of the person(s) making it. This is especially true of an objection put forward by the consensus caller themself, or of a position they have argued for. Each must stand or fall on its own merits. Certainly a consensus caller may be inclined to exercise more diligence if someone with relevant expertise has offered their view, but that is no substitute for determining whether the outcome has sufficient support and whether objections have been heard, understood, and addressed. We do not weigh the person. Participation is open and participants act as individuals, so a person's history with the group, their affiliation, and their reputation are not inputs to a determination. What is evaluated is what was said, not who said it. We do not allow ballot stuffing. Volume does not decide in either direction: a large number of voices simply stating an objection does not establish a lack of consensus, and a large number simply stating support does not establish its presence. In both cases the consensus caller weighs what was said, not how many said it. Where the people objecting are not making a coherent claim, cannot explain the reasoning behind their objections, or cannot explain why the group's answers to them are inadequate, those objections can be addressed on the merits. We assume good faith. The process requires participants to state the reasons they actually hold, to consider the answers they are given, and to be open to persuasion; it works because most people do this. Someone participating strategically -- objecting to delay a decision, or restating a position without engaging with the response to it -- can stall a group indefinitely. The remedy is not to diagnose motive. An accusation of bad faith is rarely provable, and treating a sincere objection as insincere denies the objector the consideration this process exists to provide. The mechanisms here address the conduct without requiring a judgement about what lies behind it: an objection whose basis cannot be explained, or that does not engage with the group's answers, can be addressed on the merits regardless of why it was raised (see ), and a failed call cannot be made into consensus by repetition (see ). Where the problem is a participant's conduct rather than any particular objection, it is not a matter for the consensus process; see .

Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the term "consensus caller" to indicate the person(s) making the determination of consensus. In Working Groups, this will be the Chair(s). Following , this document distinguishes between an objection being addressed and being accommodated. An objection is accommodated when the proposal is changed to satisfy it. An objection is addressed when it has been heard, understood, and no longer blocks the decision, whether or not the proposal changes as a result; sets out the ways this can occur. Rough consensus requires that objections be addressed; it does not require that they be accommodated.

Consensus Decisions Decisions that require rough consensus MUST fulfil these requirements, as expanded upon in the following subsections:

1. The decision is within the authority of the body
2. The outcome has sufficient support
3. Any objections have been addressed

Only the consensus caller can determine consensus; participants cannot declare consensus, and should not characterise it before it is established. A consensus caller SHOULD NOT determine consensus on a document they author, or on a proposal they have put forward themselves. Where the group has other Chairs, one of them makes the determination; otherwise, the responsible Area Director can be asked to. Working Groups are required to establish rough consensus to progress a document in the process. Some groups only formally declare consensus on a document's content with a Working Group Last Call; others make calls for consensus on selected decisions to establish agreement on parts of the design earlier in the process. Consensus callers can make an informal determination -- i.e., characterise the consensus of a group without a formal call -- but this is necessarily more open to contestation than a formal declaration. To avoid confusion, make our process and the status of decisions legible to newcomers, and facilitate review, groups MUST record their consensus decisions; see . A failure to record a decision does not by itself invalidate it; the remedy is to produce the record. Once rough consensus is established and documented, it can only be reconsidered if genuinely new information becomes available. A change in the circumstances the decision relied upon is new information; a participant who was not part of the discussion is not. The consensus caller determines whether this bar is met, and for a contested case may put the question of reopening to the group; see . Like other decisions, that determination is appealable. A call that does not establish consensus does not settle the question, and the consensus caller may make a further call. There are good reasons to do so: the proposal may have changed, more time may be needed, or a heated discussion may benefit from a pause. What a further call cannot do is establish consensus by attrition. Where the objections are unchanged and unaddressed, repeating the call does not address them. Deferring a decision is a legitimate outcome, and sometimes the right one -- where a revised proposal, further background work, or more time to consider the options would change the discussion.

Assuring Authority All consensus decisions MUST be within the authority of the body making them. For Working Groups, this means that they are required to be within the declared scope of the group's charter. This does not mean that a charter needs to enumerate all questions that a group makes decisions upon; assuring authority is a necessarily interpretive act. When there is a dispute about the authority to make a given decision, the consensus caller will make a determination. Like all decisions, this is appealable. Authority is also bounded by decisions already settled at a broader level. The IETF reaches consensus on matters that apply across its work -- architectural principles, and positions such as the treatment of pervasive monitoring as an attack . Where such a decision applies, a group cannot set it aside by reaching its own local consensus; the broader decision is not within the group's authority to overturn. A group may apply a settled principle to its particular circumstances, and may raise genuinely new information that bears on it (which is grounds to revisit the broader decision through the appropriate body, not to depart from it locally). But local consensus does not override wider consensus. Whether a broader decision applies at all is a separate question, and one the group can legitimately decide. For example, gives strong guidance about congestion control, but a group might determine that the only environment its protocol can be deployed in is one where that guidance does not apply. Such a determination is itself a decision subject to this document: the reasoning for it needs to be stated explicitly and recorded, and like any other decision it is open to objection and appeal. A determination of this kind usually rests on an assumption about the environment the protocol will be deployed in, and such assumptions have often proven wrong over time. Such determinations warrant caution.

Determining Support All consensus decisions MUST demonstrate substantial support among those who have engaged with the question. Support functions as a threshold. It establishes that enough people have engaged with the question for the group to decide it; it does not establish that the outcome is correct, and it does not dispose of any objection -- objections are addressed on their merits under , whatever the level of support for the proposal they are raised against. Because participation is open and there is no membership, support is not a proportion of any defined body. What the consensus caller assesses is whether those who engaged with the question expressed enough support to proceed. This guards against a decision taken amid general indifference, where a proposal advances because few were paying attention rather than because the group agreed. How support is determined is contextual. For uncontroversial topics that are uninteresting to many participants, expressed support may be sparse. Conversely, controversial topics may attract both strong support and opposition. Often, the group will have two (or more) competing proposals under consideration. When this happens, relative support can be determined through mechanisms like polls. If a significant number of participants indicate support for a proposal and there are no objections, there is clearly support for that proposal. Here "significant" is contextual -- the consensus caller needs to consider how many participants have been active in the discussion, how long they have had to consider the proposal, and how likely objections are. If a small number of participants indicate support for a proposal and there are no objections, support may be present, but the consensus caller should consider its strength. Depending on the nature of the decision, more time or another call for consensus may be necessary. Again, "small" is contextual and requires interpretation by the consensus caller. Where a proposal has not been contested, silence can be taken as assent, provided participants had adequate notice and time to respond. Where views have conflicted, it cannot: an objection is not withdrawn by failing to repeat it, and the consensus caller needs to ask those who disagreed whether they can live with the outcome (see ). If a proposal is determined to have support but there are objections, those objections need to be addressed according to . These two evaluations are iterative, not sequential. Addressing an objection often alters the proposal, which then needs to be re-checked for support; a revised proposal may attract fresh objections. The consensus caller repeats both assessments until the proposal has substantial support with all objections addressed. When determining support for a technical proposal, a consensus caller MAY give weight to interest by implementers or potential implementers, or lack thereof. This is evidence about whether the proposal will be deployed, not standing given to the people expressing it. A statement of intent to implement is weaker evidence than running code: existing implementations, interoperability results and deployment experience. describes one way for a document to record them.

Addressing Objections Most feedback on a proposal is handled by the document's editor(s). Feedback becomes an objection when it is raised against a decision and maintained after the group and the editors have responded to it; only then does it require a determination by the consensus caller. An objection is addressed when:

1. It is accommodated -- the proposal is changed to satisfy it;
2. It is retracted -- the objector withdraws it or declines to press it further, whether or not the proposal has changed; or
3. The consensus caller determines that it does not bear on the merits of the decision, or that it identifies a genuine problem which is outweighed by the weaknesses of the alternatives.

Only the third case calls for a judgement by the consensus caller. An addressed objection does not prevent a finding of rough consensus. Where an objection is neither accommodated nor retracted, and the consensus caller can make neither of the findings in the third case, the objection stands. Rough consensus has not been reached for the proposal as it is: the proposal must be revised, the objection otherwise addressed, or the decision deferred. Not every objection requires the group's full engagement. One that is trivial, nonsensical, poorly described, off-topic, purely editorial, out of charter, or already answered can be set aside by the consensus caller without further discussion, on the ground that it does not bear on the merits. Some objections are directed at whether a question should be decided at all. Where the objection is that the decision is outside the group's authority, it is determined under . Otherwise it is weighed against a concrete proposal rather than in advance of one: the merits of such an objection depend on what is proposed. Otherwise, objections need to be understood fully by the group. This puts a burden on the party making the objection to explain its nature and relevance, and on the group to appreciate and consider it. Successfully addressing an objection is characterised by dialogue and introspection by all parties, with the goal of achieving a consensus that produces the best outcome for the Internet's users. Consensus callers manage the discussion; they can ask that a well-worn argument not be repeated, or that a call for consensus collect positions rather than restart the debate. Doing so does not address any objection -- only the outcomes above do that. Once an objection is understood and has been discussed by the group, the consensus caller weighs the arguments. The best outcome is one that is, after discussion, palatable to all; often, this is determined through polls that ask if participants "can live with" that outcome. When successful, this accommodates or retracts the objection, but the consensus caller is still required to determine a sufficient level of support for the result; see . If such an outcome cannot be negotiated in a reasonable timeframe, the consensus caller determines whether the objection is addressed under the third case, or whether it stands. This determination is made on the merits of the objection; how many people support an objection is not relevant. An objection does not bear on the merits when, after full consideration by the group, the consensus caller finds that it does not identify a problem with the decision -- because the reasoning behind it cannot be explained, because it does not engage with the group's answers to it, or because the concern it raises is not one the decision affects. An objection is outweighed when it identifies a genuine problem, but accommodating it would cause greater harm than leaving it unaccommodated, because the alternatives have worse weaknesses of their own. This arises where a decision involves a trade-off and every available option attracts well-founded objections. The group compares the options according to ; the consensus caller finds that the alternatives were before the group and that the objection was weighed against them. Where the consensus caller makes either finding after the group has fully considered the objection, the declaration MUST state the reasoning for it; where the objection was found to be outweighed, the declaration MUST also identify the alternatives that were weighed against it. An objection set aside without further discussion, as described above, is not subject to this requirement. Arguments that rely on already established IETF consensus (as recorded in IETF stream RFCs) will be substantiated, if necessary by consulting the IESG. Per , where a decision is determined to contradict IETF consensus, an objection on that basis stands; the decision is not within the group's authority to make. As with other aspects of decision making in the IETF, how an objection is addressed can be appealed; see .

Deciding Trade-offs Some consensus decisions have no option that is free of well-founded objections. Letting every such objection stand would prevent the group from deciding anything. Here the group needs to weigh the options against each other. Evaluating a trade-off requires being concrete about who is affected and how. Use cases are the usual vehicle for this: they make the consequences of each option explicit, and an objection that cannot be tied to any use case is difficult to weigh. An objection is not weakened by raising a use case that the group had not previously considered; the group should determine whether that use case is within its scope, and if it is, weigh it alongside the others. The alternatives to be weighed always include leaving the disputed element out and deferring the decision. Options are not compared by counting use cases, because use cases do not carry equal weight. counsels that where interests conflict, those of end users be given priority. In general, a group should prefer an option under which every use case in scope can achieve a useful -- even if not optimal -- result, over one that serves some optimally while leaving others severely harmed. A group should also prefer the option that attracts the weakest objections; the option with the widest support is not necessarily that option. The resulting document SHOULD describe the trade-off that was made and the reasoning behind it.

Communicating Decisions When declaring the outcome of a consensus call, the consensus caller SHOULD explain how the determination was reached. In simple cases this can be very brief. Where the decision was contested or involved a trade-off, a useful declaration includes:

• what was decided, stated precisely enough to act upon;
• the objections the consensus caller addressed under ;
• the options considered and the trade-offs between them, including the use cases weighed against each other;
• what would constitute grounds to revisit the decision, if that is not obvious.

The more contested a decision, the more its declaration needs to explain itself. A good explanation allows those who disagree to see that their objections were weighed rather than counted. Consensus decisions can be recorded in e-mail, a publicly available document, or an issues list. Such a record need not be formal, but the consensus caller remains responsible for being able to cite their determinations.

Non-Consensus Decisions Some IETF decisions do not require a consensus process. In general, these can be characterised as administrative decisions that often have other established procedural requirements. For example, a Working Group chair does not need to establish consensus to adopt a draft as a work item, because that would require the full process in for the draft's content, effectively making it ready for publication. Likewise, establishing the time and location of an interim meeting does not require consensus, as doing so would introduce unreasonable overhead and endanger the group's work. Many decisions are characterised as "editorial" -- that is, they are about how a design is documented, encompassing style, phrasing, organisation of the document and similar issues. Subjecting such decisions to the consensus process is not a good use of the group's time. Deciding the names of protocol elements can become contentious, but making them consensus decisions is rarely a good use of a group's time. Usually, they are best treated as editorial decisions taken with consultation. Decisions that do not require consensus still cannot be made unilaterally or without consultation. Adopting a draft that has little chance of gaining consensus is a waste of the group's time, and a meeting scheduled at a time or place that makes it impossible for contributors to attend is unlikely to be productive. In some cases, editorial decisions do have impact on adoption and implementation. Objections to these decisions SHOULD be considered, but need not be addressed according to the consensus process. Specifically, non-consensus decisions can also be appealed (see ); however, lack of consensus is not a valid basis.

IANA Considerations This document has no considerations for IANA.

Security Considerations The consensus process is critical to Internet security overall -- it helps assure that the protocols we build have the properties end users rely upon.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes the guidelines and procedures for formation and operation of IETF working groups. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol. Historic reports have varied widely in form and level of content and there is little guidance available to new report preparers. This document updates the existing processes and provides more detail on what is appropriate in an interoperability and implementation report. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document updates the Internet Engineering Task Force (IETF) Standards Process defined in RFC 2026. Primarily, it reduces the Standards Process from three Standards Track maturity levels to two. This memo documents an Internet Best Current Practice. This document updates RFC 2026 to no longer use STD 1 as a summary of "Internet Official Protocol Standards". It obsoletes RFC 5000 and requests the IESG to move RFC 5000 (and therefore STD 1) to Historic status. RFC 2026 describes the review performed by the Internet Engineering Steering Group (IESG) on IETF Proposed Standard RFCs and characterizes the maturity level of those documents. This document updates RFC 2026 by providing a current and more accurate characterization of Proposed Standards. This document removes a limit on the number of Area Directors who manage an Area in the definition of "IETF Area". This document updates RFC 2026 (BCP 9) and RFC 2418 (BCP 25). This document requires that the IETF never publish any IETF Stream RFCs without IETF rough consensus. This updates RFC 2026. In RFC 9280, responsibility for the RFC Series moved to the RFC Series Working Group and the RFC Series Approval Board. It is no longer the responsibility of the RFC Editor, and the role of the IAB in the RFC Series is altered. Accordingly, in Section 2.1 of RFC 2026, the sentence "RFC publication is the direct responsibility of the RFC Editor, under the general direction of the IAB" is deleted. Internet Architecture Board This memo documents the composition, selection, roles, and organization of the Internet Architecture Board. It replaces RFC 1601. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document updates the IAB Charter (RFC 2850) to be consistent with version 3 of the RFC Editor Model (RFC 9280). This memo provides a charter for the Internet Engineering Steering Group (IESG), a management function of the Internet Engineering Task Force (IETF). It is meant to document the charter of the IESG as it is presently understood. This memo provides information for the Internet community. This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. The guidelines recognize the diversity of IETF participants, emphasize the value of mutual respect, and stress the broad applicability of our work. This document is an updated version of the guidelines for conduct originally published in RFC 3184. 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. 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. This document provides a set of guidelines for working groups that choose to use GitHub for their work. Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document provides recommendations of best current practice for dropping or marking packets using any active queue management (AQM) algorithm, including Random Early Detection (RED), BLUE, Pre- Congestion Notification (PCN), and newer schemes such as CoDel (Controlled Delay) and PIE (Proportional Integral controller Enhanced). We give three strong recommendations: (1) packet size should be taken into account when transports detect and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) in the specific case of RED, the byte- mode packet drop variant that drops fewer small packets should not be used. This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. This document explains why the IAB believes that, when there is a conflict between the interests of end users of the Internet and other parties, IETF decisions should favor end users. It also explores how the IETF can more effectively achieve this.

Other Definitions of Consensus Standards bodies elsewhere define consensus as general agreement characterised by the absence of sustained opposition on substantial issues from any important part of the concerned interests, arrived at by a process that seeks to take account of all views and to reconcile conflicting arguments. That wording is ISO/IEC's; it is reproduced in European standardisation law and echoed in the principles agreed by the WTO Committee on Technical Barriers to Trade. Most of this document maps onto it. An objection that stands under is sustained opposition on a substantial issue, and rough consensus has not been reached. Objections that are accommodated, retracted, or found not to bear on the merits are not sustained opposition, because the group has taken account of them and either satisfied them or shown that they do not bear on the decision. Two differences do not. Where an objection is found to be outweighed, this document permits a decision over an objection that is both maintained and well-founded; a body applying the definition above would find no consensus. And because the IETF has no membership, support is not measured against a defined body of concerned interests; see .