<?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 Rough 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 without
      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-sponsoring-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>