Making Decisions in the IETF
draft-nottnick-ietf-decisions-00

Network Working Group                                      M. Nottingham
Internet-Draft                                                          
Updates: 2418 (if approved)                                   P. Resnick
Intended status: Best Current Practice                      21 July 2026
Expires: 22 January 2027

                      Making Decisions in the IETF
                    draft-nottnick-ietf-decisions-00

Abstract

   This document specifies Best Current Practice for making decisions
   within the IETF process.

   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/SHORT.

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 22 January 2027.

Nottingham & Resnick     Expires 22 January 2027                [Page 1]
Internet-Draft        Making Decisions in the IETF             July 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  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Notational Conventions  . . . . . . . . . . . . . . . . .   4
   2.  Consensus Decisions . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Assuring Authority  . . . . . . . . . . . . . . . . . . .   5
     2.2.  Determining Support . . . . . . . . . . . . . . . . . . .   5
     2.3.  Handling Objections . . . . . . . . . . . . . . . . . . .   7
   3.  Non-Consensus Decisions . . . . . . . . . . . . . . . . . . .   7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   The IETF guides its decisions with "rough consensus and running
   code."  However, [BCP9] does not explicitly define how consensus is
   achieved; it only highlights the importants of "broad" consensus.

   Section 3.3 of [RFC2418] is more detailed:

Nottingham & Resnick     Expires 22 January 2027                [Page 2]
Internet-Draft        Making Decisions in the IETF             July 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 the decisions we make are
   more relevant than ever to society.  To help both participants and
   those who use our standards understand our process, this document
   outlines the procedures we use to make decisions in more detail.  It
   is not intended to establish new policy, only articulate existing
   practices more carefully.

   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.

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

Nottingham & Resnick     Expires 22 January 2027                [Page 3]
Internet-Draft        Making Decisions in the IETF             July 2026

   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.  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.  The objection 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 made
   the objection, but that is no substitute for actually making the
   judgement of whether the objection has been heard, understood, and
   addressed.

   We do not allow ballot stuffing.  As a corollary to the above, even
   an overwhelming majority of voices simply stating an objection does
   not necessarily indicate a lack of consensus.  If the people making
   those objections are not making a coherent claim, cannot explain the
   reasoning behind their objections, or cannot explain why the answers
   to their objections are valid after given answers by the rest of the
   group, such objections can be dismissed on the merits.

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).

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

Nottingham & Resnick     Expires 22 January 2027                [Page 4]
Internet-Draft        Making Decisions in the IETF             July 2026

   2.  The outcome has sufficient support

   3.  Any objections have been handled

   Only the consensus caller can determine consensus; participants
   cannot declare consensus, and should avoid attempting to characterise
   consensus before it is established.

   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 informally determine consensus -- i.e.,
   characterise the consensus of a group without a formal call or
   determination -- but this is necessarily more open to contestation
   than formally determined consensus.

   Once rough consensus is established and documented, it can only be
   reconsidered if genuinely new information becomes available.  The
   consensus caller determines whether this bar is met; like other
   decisions, that determination is appealable.

   To avoid confusion, make our process and the status of decisions
   legible to newcomers, and facilitate review, groups SHOULD maintain a
   record of decisions, including characterisation of support and any
   objections indicating the disposition of their handling.  This might
   be in e-mail, a publicly available document, or an issues list.

2.1.  Assuring Authority

   All 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.

2.2.  Determining Support

   All decisions MUST demonstrate substantial support within the group
   for the outcome.

Nottingham & Resnick     Expires 22 January 2027                [Page 5]
Internet-Draft        Making Decisions in the IETF             July 2026

   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.

   There is no exact proportion of the group that is required to
   demonstrate support in order for a proposal to be successful, because
   determining support is not a voting process.

   If a significant number 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 partipants 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.

   If support is indicated for a proposal but there are objections,
   those objections need to be handled 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 handled.

   When determining support for a technical proposal, a consensus caller
   MAY give weight to interest by implementers or potential
   implementers, or lack thereof.

   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 surface 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.

Nottingham & Resnick     Expires 22 January 2027                [Page 6]
Internet-Draft        Making Decisions in the IETF             July 2026

2.3.  Handling Objections

   Objections to a proposal are first considered by the consensus
   caller.  Trivial and off-topic objections can be discarded outright.
   Objections that have already been handled can be satisfied by a
   reference to the previously handled objection, so long as they are
   comparable.

   Substantial and new 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.  Successful objection handling 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.

   If an objection nevertheless persists after full consideration, the
   consensus caller should make a determination of its disposition.

   A persistent objection has one of two dispositions.  It is upheld
   when the consensus caller finds it coherent and on the merits, and
   not addressed by the group.  An upheld objection means rough
   consensus has not been reached for the proposal as it stands; the
   proposal must be revised, the objection otherwise addressed, or the
   decision deferred.

   It is discounted when, after full consideration, the consensus caller
   finds it does not bear on the merits — for instance, it is
   incoherent, cannot be explained by the person raising it, restates an
   already-handled objection without new grounds, or has been answered
   by the group without substantive reply.  A discounted objection does
   not prevent a finding of rough consensus.  The consensus caller
   records the disposition and its basis.  Either determination can be
   appealed."

   As with other aspects of decision making in the IETF, objection
   handling can be appealed; see Section 6.5 of [RFC2026].

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.

   For example, a Working Group chair does not need to establish
   consensus to adopt a draft as a work item, because that would
   necessitate going through the full process in Section 2 for the
   draft's content, effectively making it ready for publication.

Nottingham & Resnick     Expires 22 January 2027                [Page 7]
Internet-Draft        Making Decisions in the IETF             July 2026

   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.

   Not requiring consensus does not mean that these decisions can 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 (for example, naming of protocol elements).
   Objections to these decisions SHOULD be considered, but need not be
   handled according to the consensus process.  Instead, we rely upon
   other checks and balances to assure good outcomes.

   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 to assure that the protocols we build provide the properties
   that end users rely upon are present.

6.  References

6.1.  Normative References

   [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>.

Nottingham & Resnick     Expires 22 January 2027                [Page 8]
Internet-Draft        Making Decisions in the IETF             July 2026

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>.

              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>.

   [BCP188]   Best Current Practice 188,
              <https://www.rfc-editor.org/info/bcp188>.
              At the time of writing, this BCP comprises the following:

Nottingham & Resnick     Expires 22 January 2027                [Page 9]
Internet-Draft        Making Decisions in the IETF             July 2026

              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>.

Authors' Addresses

   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 22 January 2027               [Page 10]