1 files changed, 157 insertions, 0 deletions
diff --git a/doc/rfc/rfc8789.txt b/doc/rfc/rfc8789.txt
new file mode 100644
index 0000000..0f10036
--- /dev/null
+++ b/doc/rfc/rfc8789.txt
@@ -0,0 +1,157 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                   J. Halpern, Ed.
+Request for Comments: 8789                                      Ericsson
+BCP: 9                                                  E. Rescorla, Ed.
+Updates: 2026                                                    Mozilla
+Category: Best Current Practice                                June 2020
+ISSN: 2070-1721
+
+
+           IETF Stream Documents Require IETF Rough Consensus
+
+Abstract
+
+   This document requires that the IETF never publish any IETF Stream
+   RFCs without IETF rough consensus.  This updates RFC 2026.
+
+Status of This Memo
+
+   This memo documents 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 has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   BCPs is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8789.
+
+Copyright Notice
+
+   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, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+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
+
+   IETF procedures, as defined by [RFC2026], allow for Informational or
+   Experimental RFCs to be published without IETF rough consensus.  For
+   context, it should be remembered that this RFC predates the
+   separation of the various streams (e.g., IRTF, IAB, and Independent.)
+   When it was written, there were only "RFCs".
+
+   As a consequence, the IESG was permitted to approve an Internet-Draft
+   for publication as an RFC without IETF rough consensus.
+
+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
+
+   The IETF procedures prior to publication of this BCP permitted such
+   informational or experimental publication without IETF rough
+   consensus.  In 2007, the IESG issued a statement saying that no
+   document will be issued without first conducting an IETF Last Call
+   [IESG-STATE-AD].  While this apparently improved the situation, when
+   looking more closely, it made it worse.  Rather than publishing
+   documents without verifying that there is rough consensus, as the
+   wording in [RFC2026] suggests, this had the IESG explicitly
+   publishing documents on the IETF Stream that have failed to achieve
+   rough consensus.
+
+   One could argue that there is a need for publishing some documents
+   that the community cannot agree on.  However, we have an explicit
+   path for such publication, namely the Independent Stream.  Or, for
+   research documents, 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 is a
+   process document about changes to the rules for certain corner cases
+   in publishing IETF Stream RFCs.  However, this procedure will prevent
+   publication of IETF Stream documents that have not reached rough
+   consensus about their security aspects, thus potentially improving
+   security aspects of IETF Stream documents.
+
+7.  Normative References
+
+   [RFC2026]  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>.
+
+   [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/info/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/info/rfc8174>.
+
+8.  Informative References
+
+   [IESG-STATE-AD]
+              IESG, "Guidance on Area Director Sponsoring of Documents",
+              IESG Statement, March 2007,
+              <https://ietf.org/about/groups/iesg/statements/area-
+              director-sponsoring-documents/>.
+
+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