Making Decisions in IETF Working Groups
draft-nottnick-ietf-decisions-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Mark Nottingham , Pete Resnick | ||
| Last updated | 2026-08-20 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-nottnick-ietf-decisions-01
Network Working Group M. Nottingham
Internet-Draft
Updates: 2418 (if approved) P. Resnick
Intended status: Best Current Practice 20 August 2026
Expires: 21 February 2027
Making Decisions in IETF Working Groups
draft-nottnick-ietf-decisions-01
Abstract
This document specifies Best Current Practice for making decisions in
IETF Working Groups.
It updates Section 3.3 of [RFC2418].
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-nottnick-ietf-decisions/.
information can be found at https://projects.mnot.net/I-D/.
Source for this draft and an issue tracker can be found at
https://github.com/mnot/I-D/labels/ietf-decisions.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 21 February 2027.
Nottingham & Resnick Expires 21 February 2027 [Page 1]
Internet-Draft Making Decisions in IETF Working Groups August 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Principles . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 5
2. Consensus Decisions . . . . . . . . . . . . . . . . . . . . . 6
2.1. Assuring Authority . . . . . . . . . . . . . . . . . . . 7
2.2. Determining Support . . . . . . . . . . . . . . . . . . . 8
2.3. Addressing Objections . . . . . . . . . . . . . . . . . . 9
2.4. Deciding Trade-offs . . . . . . . . . . . . . . . . . . . 11
2.5. Communicating Decisions . . . . . . . . . . . . . . . . . 12
3. Non-Consensus Decisions . . . . . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Other Definitions of Consensus . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
The IETF guides its decisions with "rough consensus and running
code." However, [BCP9] does not explicitly define how that consensus
is achieved; it only highlights the importance of "broad" consensus.
Section 3.3 of [RFC2418] is more detailed:
Nottingham & Resnick Expires 21 February 2027 [Page 2]
Internet-Draft Making Decisions in IETF Working Groups August 2026
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 a show of hands, humming, or any other means on
which the WG agrees (by rough consensus, of course). Note that 51%
of the working group does not qualify as "rough consensus" and 99% is
better than rough. It is up to the Chair to determine if rough
consensus has been reached.
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 Section 3 of [RFC8789]. Working Group decisions
are where most of that consensus is built, and this document
describes how they are made.
This document replaces Section 3.3 of [RFC2418]. 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 Section 2.2). And no proportion of the
group -- neither 51% nor 99% -- establishes or fails to establish
rough consensus, because it is not a vote.
Section 1.1 outlines the principles that guide the rest of this
document. Section 2 provides guidelines for making decisions that
require consensus; Section 3 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 [BCP39] and [RFC3710]).
Nottingham & Resnick Expires 21 February 2027 [Page 3]
Internet-Draft Making Decisions in IETF Working Groups August 2026
1.1. 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 Section 2. 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.
Nottingham & Resnick Expires 21 February 2027 [Page 4]
Internet-Draft Making Decisions in IETF Working Groups August 2026
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
Section 2.3), and a failed call cannot be made into consensus by
repetition (see Section 2).
Where the problem is a participant's conduct rather than any
particular objection, it is not a matter for the consensus process;
see [BCP54].
1.2. 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 [RFC2119] [RFC8174] 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).
Nottingham & Resnick Expires 21 February 2027 [Page 5]
Internet-Draft Making Decisions in IETF Working Groups August 2026
Following [RFC7282], 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; Section 2.3 sets out the ways this can occur. Rough
consensus requires that objections be addressed; it does not require
that they be accommodated.
2. 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 Section 2.5. 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
Nottingham & Resnick Expires 21 February 2027 [Page 6]
Internet-Draft Making Decisions in IETF Working Groups August 2026
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
Section 4.1.3 of [RFC8874]. 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.
2.1. 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 [BCP188]. 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, [BCP41] 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
Nottingham & Resnick Expires 21 February 2027 [Page 7]
Internet-Draft Making Decisions in IETF Working Groups August 2026
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.
2.2. 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
Section 2.3, 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.
Nottingham & Resnick Expires 21 February 2027 [Page 8]
Internet-Draft Making Decisions in IETF Working Groups August 2026
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
Section 2.3).
If a proposal is determined to have support but there are objections,
those objections need to be addressed according to Section 2.3.
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. [RFC7942] describes one way for a
document to record them.
2.3. 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.
Nottingham & Resnick Expires 21 February 2027 [Page 9]
Internet-Draft Making Decisions in IETF Working Groups August 2026
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 Section 2.1. 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
Section 2.2.
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.
Nottingham & Resnick Expires 21 February 2027 [Page 10]
Internet-Draft Making Decisions in IETF Working Groups August 2026
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 Section 2.4; 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 Section 2.1, 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 Section 6.5 of [RFC2026].
2.4. 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.
Nottingham & Resnick Expires 21 February 2027 [Page 11]
Internet-Draft Making Decisions in IETF Working Groups August 2026
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. [RFC8890] 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.
2.5. 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 Section 2.3;
* 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.
3. 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.
Nottingham & Resnick Expires 21 February 2027 [Page 12]
Internet-Draft Making Decisions in IETF Working Groups August 2026
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 Section 2 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
Section 6.5 of [RFC2026]); however, lack of consensus is not a valid
basis.
4. IANA Considerations
This document has no considerations for IANA.
5. 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.
6. References
6.1. Normative References
Nottingham & Resnick Expires 21 February 2027 [Page 13]
Internet-Draft Making Decisions in IETF Working Groups August 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
6.2. Informative References
[BCP9] Best Current Practice 9,
<https://www.rfc-editor.org/info/bcp9>.
At the time of writing, this BCP comprises the following:
Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
<https://www.rfc-editor.org/info/rfc2026>.
Dusseault, L. and R. Sparks, "Guidance on Interoperation
and Implementation Reports for Advancement to Draft
Standard", BCP 9, RFC 5657, DOI 10.17487/RFC5657,
September 2009, <https://www.rfc-editor.org/info/rfc5657>.
Housley, R., Crocker, D., and E. Burger, "Reducing the
Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
DOI 10.17487/RFC6410, October 2011,
<https://www.rfc-editor.org/info/rfc6410>.
Resnick, P., "Retirement of the "Internet Official
Protocol Standards" Summary Document", BCP 9, RFC 7100,
DOI 10.17487/RFC7100, December 2013,
<https://www.rfc-editor.org/info/rfc7100>.
Kolkman, O., Bradner, S., and S. Turner, "Characterization
of Proposed Standards", BCP 9, RFC 7127,
DOI 10.17487/RFC7127, January 2014,
<https://www.rfc-editor.org/info/rfc7127>.
Dawkins, S., "Increasing the Number of Area Directors in
an IETF Area", BCP 9, RFC 7475, DOI 10.17487/RFC7475,
March 2015, <https://www.rfc-editor.org/info/rfc7475>.
Halpern, J., Ed. and E. Rescorla, Ed., "IETF Stream
Documents Require IETF Rough Consensus", BCP 9, RFC 8789,
DOI 10.17487/RFC8789, June 2020,
<https://www.rfc-editor.org/info/rfc8789>.
Nottingham & Resnick Expires 21 February 2027 [Page 14]
Internet-Draft Making Decisions in IETF Working Groups August 2026
Rosen, B., "Responsibility Change for the RFC Series",
BCP 9, RFC 9282, DOI 10.17487/RFC9282, June 2022,
<https://www.rfc-editor.org/info/rfc9282>.
[BCP39] Best Current Practice 39,
<https://www.rfc-editor.org/info/bcp39>.
At the time of writing, this BCP comprises the following:
IAB and B. Carpenter, Ed., "Charter of the Internet
Architecture Board (IAB)", BCP 39, RFC 2850,
DOI 10.17487/RFC2850, May 2000,
<https://www.rfc-editor.org/info/rfc2850>.
Carpenter, B., Ed., "IAB Charter Update for RFC Editor
Model", BCP 39, RFC 9283, DOI 10.17487/RFC9283, June 2022,
<https://www.rfc-editor.org/info/rfc9283>.
[BCP41] Best Current Practice 41,
<https://www.rfc-editor.org/info/bcp41>.
At the time of writing, this BCP comprises the following:
Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/info/rfc2914>.
Briscoe, B. and J. Manner, "Byte and Packet Congestion
Notification", BCP 41, RFC 7141, DOI 10.17487/RFC7141,
February 2014, <https://www.rfc-editor.org/info/rfc7141>.
[BCP54] Best Current Practice 54,
<https://www.rfc-editor.org/info/bcp54>.
At the time of writing, this BCP comprises the following:
Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54,
RFC 7154, DOI 10.17487/RFC7154, March 2014,
<https://www.rfc-editor.org/info/rfc7154>.
[BCP188] Best Current Practice 188,
<https://www.rfc-editor.org/info/bcp188>.
At the time of writing, this BCP comprises the following:
Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418,
September 1998, <https://www.rfc-editor.org/rfc/rfc2418>.
Nottingham & Resnick Expires 21 February 2027 [Page 15]
Internet-Draft Making Decisions in IETF Working Groups August 2026
[RFC3710] Alvestrand, H., "An IESG charter", RFC 3710,
DOI 10.17487/RFC3710, February 2004,
<https://www.rfc-editor.org/rfc/rfc3710>.
[RFC7282] Resnick, P., "On Consensus and Humming in the IETF",
RFC 7282, DOI 10.17487/RFC7282, June 2014,
<https://www.rfc-editor.org/rfc/rfc7282>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/rfc/rfc7942>.
[RFC8874] Thomson, M. and B. Stark, "Working Group GitHub Usage
Guidance", RFC 8874, DOI 10.17487/RFC8874, August 2020,
<https://www.rfc-editor.org/rfc/rfc8874>.
[RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890,
DOI 10.17487/RFC8890, August 2020,
<https://www.rfc-editor.org/rfc/rfc8890>.
Appendix A. 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
Section 2.3 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 Section 2.2.
Authors' Addresses
Nottingham & Resnick Expires 21 February 2027 [Page 16]
Internet-Draft Making Decisions in IETF Working Groups August 2026
Mark Nottingham
Melbourne
Australia
Email: mnot@mnot.net
URI: https://mnot.net/
Pete Resnick
Urbana
United States of America
Email: resnick@episteme.net
URI: https://episteme.net/
Nottingham & Resnick Expires 21 February 2027 [Page 17]