rfc8789xml2.original.xml		rfc8789.xml
			<?xml version="1.0" encoding="UTF-8"?>
			<rfc submissionType="IETF" category="bcp" consensus="true" ipr="trust200902"
			updates="2026"
			docName="draft-halpern-gendispatch-consensusinformational-04"
			number="8789" version="3" tocInclude="true" symRefs="true" sortRefs="true"
			xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude">
			<front>
			<title abbrev="IETF Document Consensus">IETF Stream Documents Require IETF R
			ough Consensus</title>
			<seriesInfo name="RFC" value="8789"/>
			<seriesInfo name="BCP" value="9"/>
			<author fullname="Joel Halpern" initials="J." role="editor"
			surname="Halpern">
			<organization abbrev="Ericsson">Ericsson</organization>
			<address>
			<postal>
			<street>P.O. Box 6049</street>
			<city>Leesburg</city>
			<region>VA</region>
			<code>20178</code>
			<country>United States of America</country>
			</postal>
			<email>joel.halpern@ericsson.com</email>
			</address>
			</author>
			<author fullname="Eric Rescorla" initials="E." role="editor"
			surname="Rescorla">
			<organization abbrev="Mozilla">Mozilla</organization>
			<address>
			<postal>
			<street>331 E. Evelyn Ave.</street>
			<city>Mountain View</city>
			<region>CA</region>
			<code>94101</code>
			<country>United States of America</country>
			</postal>
			<email>ekr@rtfm.com</email>
			</address>
			</author>
			<date month="May" year="2020" />
			<area>General</area>
			<abstract>
			<t>This document requires that the IETF never publish any IETF
			Stream RFCs without IETF rough consensus. This updates RFC 2026.</t>
			</abstract>
			</front>
			<middle>
			<section title="Introduction">
			<t> IETF procedures, as defined by <xref target="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". </t>
			<t>As a consequence, the IESG was permitted to
			approve an Internet-Draft for publication as an RFC without IETF
			rough consensus.</t>
			</section>
			<section title="Terminology">
			<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
			"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
			NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
			"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
			"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
			be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
			target="RFC8174"/> when, and only when, they appear in all capitals, as
			shown here.
			</t>
			</section>
			<section anchor="Action" title="Action">
			<t>The IETF <bcp14>MUST NOT</bcp14> publish RFCs on the IETF Stream withou
			t
			establishing IETF rough consensus for publication.
			</t>
			</section>
			<section anchor="Discussion" title="Discussion">
			<t>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
			<xref target="IESG-STATE-AD"></xref>. 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 <xref target="RFC2026"/>
			suggests, this had the IESG explicitly publishing documents on
			the IETF Stream that have failed to achieve rough consensus.</t>
			<t>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.</t>
			</section>
			<section title="IANA Considerations">
			<t>This document has no IANA actions.</t>
			</section>
			<section title="Security Considerations">
			<t>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.</t>
			</section>
			</middle>
			<back>
			<references>
			<name>Normative References</name>
			<xi:include
			href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2026.xml
			"/>
			<xi:include
			href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml
			"/>
			<xi:include
			href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
			</references>
			<references>
			<name>Informative References</name>
			<reference anchor="IESG-STATE-AD"
			target="https://ietf.org/about/groups/iesg/statements/area-director-spons
			oring-documents/">
			<front>
			<title>Guidance on Area
			Director Sponsoring of Documents</title>
			<author><organization>IESG</organization></author>
			<date month="March" year="2007"/>
			</front>
			<refcontent>IESG Statement</refcontent>
			</reference>
			</references>
			</back>
			</rfc>
End of changes. 1 change blocks.
	lines changed or deleted		lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/