IETF Stream Documents Require IETF Rough ConsensusEricssonP.O. Box 6049LeesburgVA20178United States of Americajoel.halpern@ericsson.comMozilla331 E. Evelyn Ave.Mountain ViewCA94101United States of Americaekr@rtfm.com
General
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
.
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
() 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
. Introduction
. Terminology
. Action
. Discussion
. IANA Considerations
. Security Considerations
. Normative References
. Informative References
Authors' Addresses
Introduction IETF procedures, as defined by ,
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.TerminologyThe 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.
ActionThe IETF MUST NOT publish RFCs on the IETF Stream without
establishing IETF rough consensus for publication.
DiscussionThe 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
. 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
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.IANA ConsiderationsThis document has no IANA actions.Security ConsiderationsThis 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.Normative ReferencesThe Internet Standards Process -- Revision 3This 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.Key words for use in RFCs to Indicate Requirement LevelsIn 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.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 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 ReferencesGuidance on Area Director Sponsoring of DocumentsIESGIESG StatementAuthors' AddressesEricssonP.O. Box 6049LeesburgVA20178United States of Americajoel.halpern@ericsson.comMozilla331 E. Evelyn Ave.Mountain ViewCA94101United States of Americaekr@rtfm.com