RFC 8789

IETF Stream Documents Require IETF Rough Consensus

📅 published June 2020, from ietf

RFC 8789: IETF Stream Documents Require IETF Rough Consensus 🎀

  • Series: Internet Engineering Task Force (IETF)
  • Number: RFC 8789, which is BCP: 9
  • Authors: J. Halpern, Ed. (Ericsson) and E. Rescorla, Ed. (Mozilla) 💜
  • Category: Best Current Practice
  • Date: June 2020
  • Updates: 2026 (that's [RFC2026]) 🦋
  • ISSN: 2070-1721

Abstract ✨

okay so this doc says the IETF must never publish any IETF Stream RFCs without IETF rough consensus 🙅‍♀️ and it updates RFC 2026 too.

Status of This Memo 📋

This memo is an Internet Best Current Practice 🌸

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). More info on BCPs is in Section 2 of RFC 7841.

You can check the current status, any errata, and how to send feedback at https://www.rfc-editor.org/info/rfc8789.

Copyright (c) 2020 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, because 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 they are provided without warranty as described in the Simplified BSD License.

Table of Contents 🗂️

  • 1. Introduction
  • 2. Terminology
  • 3. Action
  • 4. Discussion
  • 5. IANA Considerations
  • 6. Security Considerations
  • 7. Normative References
  • 8. Informative References
  • Authors' Addresses

1. Introduction 🌈

okay so the IETF's procedures, as laid out in [RFC2026], let Informational or Experimental RFCs get published without IETF rough consensus. Context check: this RFC is older than the split into separate streams (IRTF, IAB, and Independent). Back then there were just "RFCs" and that was it 🙈

So the IESG was allowed to approve an Internet-Draft for publication as an RFC without rough consensus. Iconic for them, not for us 💀

2. Terminology 📖

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.

3. Action 🎯

The IETF MUST NOT publish RFCs on the IETF Stream without establishing IETF rough consensus for publication. 💅

4. Discussion 💬

Before this BCP, IETF procedures allowed informational or experimental publication without IETF rough consensus. In 2007 the IESG put out a statement saying that no document would be issued without first conducting an IETF Last Call [IESG-STATE-AD]. That honestly helped a bit, but when you look closer it made things worse 😭 Instead of publishing documents only after checking for rough consensus, which is what the wording in [RFC2026] hints at, the IESG was now explicitly publishing documents on the IETF Stream that had failed to reach rough consensus. Not it. 🙅‍♀️

Sure, you could argue there's a need to publish some stuff the community can't agree on. But we already have a clear path for that: the Independent Stream. And for research documents there's the IRTF Stream, which explicitly publishes minority opinion Informational RFCs 🧚

5. IANA Considerations 📦

This document has no IANA actions.

6. Security Considerations 🔐

This document introduces no new security considerations. It's a process document about changing the rules for certain corner cases in publishing IETF Stream RFCs. Still, this procedure will stop IETF Stream documents from being published before they've reached rough consensus about their security aspects, which could potentially improve the security of IETF Stream documents. Main character energy for security, honestly 👑

7. Normative References 📚

8. Informative References 🌸

Authors' Addresses 🫶

Joel Halpern (editor) Ericsson P.O. Box 6049 Leesburg, VA 20178 United States of America

Email: joel.halpern@ericsson.com

Eric Rescorla (editor) Mozilla 331 E. Evelyn Ave. Mountain View, CA 94101 United States of America

Email: ekr@rtfm.com

📦 where this page comes from