<?xmlversion="1.0" encoding="US-ASCII"?> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="4"?> <?rfc rfcedstyle="yes"?> <?rfc subcompact="no"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY RFC1358 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1358.xml'> <!ENTITY RFC1601 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1601.xml'> <!ENTITY RFC2026 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2026.xml'> <!ENTITY RFC2555 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2555.xml'> <!ENTITY RFC2850 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2850.xml'> <!ENTITY RFC3932 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3932.xml'> <!ENTITY RFC3967 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3967.xml'> <!ENTITY RFC5378 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5378.xml'> <!ENTITY RFC4714 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4714.xml'> <!ENTITY RFC4845 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4845.xml'> <!ENTITY RFC4846 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4846.xml'> <!ENTITY RFC4897 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4897.xml'> <!ENTITY RFC5743 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5743.xml'> <!ENTITY RFC5744 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5744.xml'> <!ENTITY RFC5745 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5745.xml'> <!ENTITY RFC7223 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7223.xml'> <!ENTITY RFC7997 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7997.xml'> <!ENTITY IASA2 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-iasa2-rfc4071bis.xml'> <!ENTITY INDSUB PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-iasa2-rfc6548bis.xml'> <!ENTITY MODEL PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-iasa2-rfc6635bis.xml'> ]>version='1.0' encoding='utf-8'?> <rfcsubmissionType="IETF"xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" consensus="true" docName="draft-ietf-iasa2-rfc4844-bis-05" indexInclude="true" ipr="trust200902" number="8729" obsoletes="4844"category="info" ipr="trust200902">prepTime="2020-02-26T18:04:03" scripts="Common,Latin" sortRefs="true" submissionType="IAB" symRefs="true" tocDepth="4" tocInclude="true" xml:lang="en"> <link href="https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc4844-bis-05" rel="prev"/> <link href="https://dx.doi.org/10.17487/rfc8729" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/> <front> <title abbrev="The RFC Series and RFC Editor">The RFC Series and RFC Editor</title> <seriesInfo name="RFC" value="8729" stream="IAB"/> <author fullname="Russ Housley" initials="R." surname="Housley" role="editor"> <organizationabbrev="Vigil Security">Vigil Security, LLC</organization>showOnFrontPage="true"/> <address> <email>housley@vigilsec.com</email> </address> </author> <author fullname="Leslie L. Daigle" initials="L." surname="Daigle" role="editor"> <organizationabbrev="Thinking Cat">Thinking Cat Enterprises</organization>showOnFrontPage="true"/> <address> <email>ldaigle@thinkingcat.com</email> </address> </author> <dateday= "30" month="October" year="2019"/> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on http://www.rfc-editor.org/search.html. --> <keyword></keyword> <abstract> <t>month="02" year="2020"/> <keyword>IASA</keyword> <keyword>IASA2</keyword> <keyword>technical publisher</keyword> <abstract pn="section-abstract"> <t pn="section-abstract-1"> This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate.</t> <t> Cover Note: </t> <t> {{This document obsoletes RFCEditor: Please remove this cover note prior to publication. }}4844. </t><t> The IASA2 WG asks</abstract> <boilerplate> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1"> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name> <t pn="section-boilerplate.1-1"> This document is not an Internet Standards Track specification; it is published for informational purposes. </t> <t pn="section-boilerplate.1-2"> This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable topublish this replacementprovide forRFC 4844. The document is changedpermanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved foralignment withpublication by thenew structureIAB are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. </t> <t pn="section-boilerplate.1-3"> Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <eref target="https://www.rfc-editor.org/info/rfc8729" brackets="none"/>. </t> </section> <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2"> <name slugifiedName="name-copyright-notice">Copyright Notice</name> <t pn="section-boilerplate.2-1"> Copyright (c) 2020 IETFAdministrative Support Activity (IASA), eliminating all referencesTrust and the persons identified as the document authors. All rights reserved. </t> <t pn="section-boilerplate.2-2"> This document is subject to BCP 78 and the IETFAdministrative Oversight Committee (IAOC).Trust's Legal Provisions Relating to IETF Documents (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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. </t></abstract></section> </boilerplate> <toc> <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1"> <name slugifiedName="name-table-of-contents">Table of Contents</name> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1"> <li pn="section-toc.1-1.1"> <t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t> </li> <li pn="section-toc.1-1.2"> <t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-rfc-series-mission">RFC Series Mission</xref></t> </li> <li pn="section-toc.1-1.3"> <t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-roles-and-responsibilities">Roles and Responsibilities</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2"> <li pn="section-toc.1-1.3.2.1"> <t keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-rfc-editor">RFC Editor</xref></t> </li> <li pn="section-toc.1-1.3.2.2"> <t keepWithNext="true" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iab">IAB</xref></t> </li> <li pn="section-toc.1-1.3.2.3"> <t keepWithNext="true" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-operational-oversight">Operational Oversight</xref></t> </li> <li pn="section-toc.1-1.3.2.4"> <t keepWithNext="true" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-policy-oversight">Policy Oversight</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.4"> <t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-framework">Framework</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2"> <li pn="section-toc.1-1.4.2.1"> <t keepWithNext="true" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-document-approval">Document Approval</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.1.2"> <li pn="section-toc.1-1.4.2.1.2.1"> <t keepWithNext="true" pn="section-toc.1-1.4.2.1.2.1.1"><xref derivedContent="4.1.1" format="counter" sectionFormat="of" target="section-4.1.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-definition">Definition</xref></t> </li> <li pn="section-toc.1-1.4.2.1.2.2"> <t keepWithNext="true" pn="section-toc.1-1.4.2.1.2.2.1"><xref derivedContent="4.1.2" format="counter" sectionFormat="of" target="section-4.1.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-operational-implementation">Operational Implementation</xref></t> </li> <li pn="section-toc.1-1.4.2.1.2.3"> <t keepWithNext="true" pn="section-toc.1-1.4.2.1.2.3.1"><xref derivedContent="4.1.3" format="counter" sectionFormat="of" target="section-4.1.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-process-change">Process Change</xref></t> </li> <li pn="section-toc.1-1.4.2.1.2.4"> <t keepWithNext="true" pn="section-toc.1-1.4.2.1.2.4.1"><xref derivedContent="4.1.4" format="counter" sectionFormat="of" target="section-4.1.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-existing-approval-process-d">Existing Approval Process Documents</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.4.2.2"> <t keepWithNext="true" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-editing-processing-and-publ">Editing, Processing, and Publication of Documents</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2"> <li pn="section-toc.1-1.4.2.2.2.1"> <t keepWithNext="true" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-definition-2">Definition</xref></t> </li> <li pn="section-toc.1-1.4.2.2.2.2"> <t keepWithNext="true" pn="section-toc.1-1.4.2.2.2.2.1"><xref derivedContent="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-operational-implementation-2">Operational Implementation</xref></t> </li> <li pn="section-toc.1-1.4.2.2.2.3"> <t keepWithNext="true" pn="section-toc.1-1.4.2.2.2.3.1"><xref derivedContent="4.2.3" format="counter" sectionFormat="of" target="section-4.2.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-process-change-2">Process Change</xref></t> </li> <li pn="section-toc.1-1.4.2.2.2.4"> <t keepWithNext="true" pn="section-toc.1-1.4.2.2.2.4.1"><xref derivedContent="4.2.4" format="counter" sectionFormat="of" target="section-4.2.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-existing-process-documents">Existing Process Documents</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.4.2.3"> <t keepWithNext="true" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-archiving-indexing-and-acce">Archiving, Indexing, and Accessibility</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.3.2"> <li pn="section-toc.1-1.4.2.3.2.1"> <t keepWithNext="true" pn="section-toc.1-1.4.2.3.2.1.1"><xref derivedContent="4.3.1" format="counter" sectionFormat="of" target="section-4.3.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-definition-3">Definition</xref></t> </li> <li pn="section-toc.1-1.4.2.3.2.2"> <t keepWithNext="true" pn="section-toc.1-1.4.2.3.2.2.1"><xref derivedContent="4.3.2" format="counter" sectionFormat="of" target="section-4.3.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-operational-implementation-3">Operational Implementation</xref></t> </li> <li pn="section-toc.1-1.4.2.3.2.3"> <t keepWithNext="true" pn="section-toc.1-1.4.2.3.2.3.1"><xref derivedContent="4.3.3" format="counter" sectionFormat="of" target="section-4.3.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-process-change-3">Process Change</xref></t> </li> <li pn="section-toc.1-1.4.2.3.2.4"> <t keepWithNext="true" pn="section-toc.1-1.4.2.3.2.4.1"><xref derivedContent="4.3.4" format="counter" sectionFormat="of" target="section-4.3.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-existing-process-documents-2">Existing Process Documents</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.4.2.4"> <t keepWithNext="true" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-series-wide-guidelines-and-">Series-Wide Guidelines and Rules</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.4.2"> <li pn="section-toc.1-1.4.2.4.2.1"> <t keepWithNext="true" pn="section-toc.1-1.4.2.4.2.1.1"><xref derivedContent="4.4.1" format="counter" sectionFormat="of" target="section-4.4.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-definition-4">Definition</xref></t> </li> <li pn="section-toc.1-1.4.2.4.2.2"> <t keepWithNext="true" pn="section-toc.1-1.4.2.4.2.2.1"><xref derivedContent="4.4.2" format="counter" sectionFormat="of" target="section-4.4.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-operational-implementation-4">Operational Implementation</xref></t> </li> <li pn="section-toc.1-1.4.2.4.2.3"> <t keepWithNext="true" pn="section-toc.1-1.4.2.4.2.3.1"><xref derivedContent="4.4.3" format="counter" sectionFormat="of" target="section-4.4.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-process-change-4">Process Change</xref></t> </li> <li pn="section-toc.1-1.4.2.4.2.4"> <t keepWithNext="true" pn="section-toc.1-1.4.2.4.2.4.1"><xref derivedContent="4.4.4" format="counter" sectionFormat="of" target="section-4.4.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-existing-process-documents-3">Existing Process Documents</xref></t> </li> </ul> </li> </ul> </li> <li pn="section-toc.1-1.5"> <t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-rfc-streams">RFC Streams</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2"> <li pn="section-toc.1-1.5.2.1"> <t keepWithNext="true" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-rfc-approval-processes">RFC Approval Processes</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.1.2"> <li pn="section-toc.1-1.5.2.1.2.1"> <t keepWithNext="true" pn="section-toc.1-1.5.2.1.2.1.1"><xref derivedContent="5.1.1" format="counter" sectionFormat="of" target="section-5.1.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-ietf-document-stream">IETF Document Stream</xref></t> </li> <li pn="section-toc.1-1.5.2.1.2.2"> <t keepWithNext="true" pn="section-toc.1-1.5.2.1.2.2.1"><xref derivedContent="5.1.2" format="counter" sectionFormat="of" target="section-5.1.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iab-document-stream">IAB Document Stream</xref></t> </li> <li pn="section-toc.1-1.5.2.1.2.3"> <t keepWithNext="true" pn="section-toc.1-1.5.2.1.2.3.1"><xref derivedContent="5.1.3" format="counter" sectionFormat="of" target="section-5.1.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-irtf-document-stream">IRTF Document Stream</xref></t> </li> <li pn="section-toc.1-1.5.2.1.2.4"> <t keepWithNext="true" pn="section-toc.1-1.5.2.1.2.4.1"><xref derivedContent="5.1.4" format="counter" sectionFormat="of" target="section-5.1.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-independent-submission-stre">Independent Submission Stream</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.5.2.2"> <t keepWithNext="true" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-rfc-technical-publication-r">RFC Technical Publication Requirements</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.2.2"> <li pn="section-toc.1-1.5.2.2.2.1"> <t keepWithNext="true" pn="section-toc.1-1.5.2.2.2.1.1"><xref derivedContent="5.2.1" format="counter" sectionFormat="of" target="section-5.2.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-ietf-documents">IETF Documents</xref></t> </li> <li pn="section-toc.1-1.5.2.2.2.2"> <t keepWithNext="true" pn="section-toc.1-1.5.2.2.2.2.1"><xref derivedContent="5.2.2" format="counter" sectionFormat="of" target="section-5.2.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iab-documents">IAB Documents</xref></t> </li> <li pn="section-toc.1-1.5.2.2.2.3"> <t keepWithNext="true" pn="section-toc.1-1.5.2.2.2.3.1"><xref derivedContent="5.2.3" format="counter" sectionFormat="of" target="section-5.2.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-irtf-documents">IRTF Documents</xref></t> </li> <li pn="section-toc.1-1.5.2.2.2.4"> <t keepWithNext="true" pn="section-toc.1-1.5.2.2.2.4.1"><xref derivedContent="5.2.4" format="counter" sectionFormat="of" target="section-5.2.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-independent-submissions">Independent Submissions</xref></t> </li> </ul> </li> </ul> </li> <li pn="section-toc.1-1.6"> <t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t> </li> <li pn="section-toc.1-1.7"> <t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-changes-since-rfc-4844">Changes Since RFC 4844</xref></t> </li> <li pn="section-toc.1-1.8"> <t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t> </li> <li pn="section-toc.1-1.9"> <t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-a-retrospective-of-iab-char">A Retrospective of IAB Charters and RFC Editor</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2"> <li pn="section-toc.1-1.9.2.1"> <t keepWithNext="true" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="A.1" format="counter" sectionFormat="of" target="section-a.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-1992">1992</xref></t> </li> <li pn="section-toc.1-1.9.2.2"> <t keepWithNext="true" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="A.2" format="counter" sectionFormat="of" target="section-a.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-1994">1994</xref></t> </li> <li pn="section-toc.1-1.9.2.3"> <t keepWithNext="true" pn="section-toc.1-1.9.2.3.1"><xref derivedContent="A.3" format="counter" sectionFormat="of" target="section-a.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-2000">2000</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.10"> <t keepWithNext="true" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-iab-members-at-the-time-of-">IAB Members at the Time of Approval</xref></t> </li> <li pn="section-toc.1-1.11"> <t keepWithNext="true" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t> </li> </ul> </section> </toc> </front> <middle> <section anchor="intro"title="Introduction"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-1"> <name slugifiedName="name-introduction">Introduction</name> <t pn="section-1-1"> The first Request for Comments (RFC) document was published in April of 1969 as part of the effort to design and build what we now know of as the Internet. Since then, the RFC Series has been the archival series dedicated to documenting Internet technical specifications, including both general contributions from the Internet research and engineering community as well as standards documents. </t><t><t pn="section-1-2"> As described in the history of the first 30 years of RFCs (<xreftarget="RFC2555"/>),target="RFC2555" format="default" sectionFormat="of" derivedContent="RFC2555"/>), the RFC Series was created for the purpose of capturing the research and engineering thought that underlie the design of (what we now know of as) the Internet. As the Internet Engineering Task Force (IETF) was formalized to carry out the discussion and documentation of Internet standards, IETF documents have become a large part (but not the entirety) of the RFC Series. </t><t><t pn="section-1-3"> As the IETF has grown up and celebrated its own 30 years of history, its requirements for archival publication of its output have changed and become more rigorous. Perhaps most significantly, the IETF must be able to define (based on its own open consensus discussion processes and leadership directions) and implement adjustments to its publication processes. </t><t><t pn="section-1-4"> At the same time, the Internet engineering and research community as a whole has grown and come to require more openness and accountability in all organizations supporting it. More than ever, this community needs an RFC Series that is supported (operationally and in terms of its principles) such that there is a balance of: </t><t><list style="symbols"> <t><ul spacing="normal" bare="false" empty="false" pn="section-1-5"> <li pn="section-1-5.1"> expert implementation;</t> <t></li> <li pn="section-1-5.2"> clear management and direction -- for operations and evolution across the whole RFC Series (whether originating in the IETF or not); and</t> <t></li> <li pn="section-1-5.3"> appropriate community input into and review of activities.</t> </list></t> <t></li> </ul> <t pn="section-1-6"> In the past, there has been confusion and therefore sometimes tension over where and how to address RFC issues that are particular to contributing groups (e.g., the IETF, the Internet Architecture Board (IAB), or independent individuals). It was not always clear where there should be community involvement versus RFC Editor control; depending on the issue, there might be more or less involvement from the IAB, the Internet Engineering Steering Group (IESG), or the community at large. There are similar issues with handling RFC Series-wide issues -- where to discuss and resolve them in a way that is balanced across the whole series. </t><t><t pn="section-1-7"> For example, there have been discussions about Intellectual Property Rights (IPR) for IETF-generated documents, but it's not clear when or how to abstract the portions of those discussions that are relevant to the rest of the RFC Series. Discussions of labeling (of RFCs in general, IETF documents in particular, or some combination thereof) generally must be applied to the whole RFCSeries-wideSeries or not at all. Without an agreed-on framework for managing the RFC Series, it is difficult to have those discussions in a non-polarized fashion -- either the IETF dictating the reality of the rest of the RFC Series, or the RFC Series imposing undue restrictions on documents from the IETF. </t><t><t pn="section-1-8"> As part of its charter (see <xreftarget="iabcharterhistory"/>),target="iabcharterhistory" format="default" sectionFormat="of" derivedContent="Appendix A"/>), the IAB has a responsibility for the RFC Editor. Acknowledging the IETF's needs and the general Internet engineering and research community's evolving needs, the IAB supports a future for the RFC Series that continues to meet its original mandate of providing the archival series for the technical research and engineering documentation that describes the Internet. </t><t><t pn="section-1-9"> With this document, the IAB provides the framework for the RFC Series and an RFC Editor function with the specific purpose of ensuring that the RFC Series is maintained and supported in ways that are consistent with the stated purpose of the RFC Series and the realities of today's Internet research and engineering community. The framework describes the existing "streams" of RFCs, draws a roadmap of existing process documents already defining the implementation, and provides clear direction of how to evolve this framework and its supporting pieces through discussion and future document revision. </t><t><t pn="section-1-10"> Specifically, this document provides a brief charter for the RFC Series, describes the role of the RFC Editor, the IAB, and the IETF Administrative Support Activity (IASA) in a framework for managing the RFC Series, and discusses the streams of input to the RFC Series from the various constituencies it serves. </t> </section> <section anchor="charter"title="RFC Series Mission"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-2"> <name slugifiedName="name-rfc-series-mission">RFC Series Mission</name> <t pn="section-2-1"> The RFC Series is the archival series dedicated to documenting Internet technical specifications, including general contributions from the Internet research and engineering community as well as standards documents. </t><t><t pn="section-2-2"> RFCs are available free of charge to anyone via the Internet. </t> </section> <section anchor="roles"title="Roles and Responsibilities"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-3"> <name slugifiedName="name-roles-and-responsibilities">Roles and Responsibilities</name> <t pn="section-3-1"> As this document sets out the framework for supporting the RFC Series mission, this section reviews the updated roles and responsibilities of the entities that have had, and will have, involvement in continued support of the mission. </t> <sectiontitle="RFC Editor"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-3.1"> <name slugifiedName="name-rfc-editor">RFC Editor</name> <t pn="section-3.1-1"> Originally, there was a single person acting as editor of the RFC Series (the RFC Editor). The task has grown, and the work now requires the organized activity of several experts, so there are RFC Editors, or an RFC Editor organization. In time, there may be multiple organizations working together to undertake the work required by the RFC Series. For simplicity's sake, and without attempting to predict how the role might be subdivided among them, this document refers to this collection of experts and organizations as the "RFC Editor". </t><t><t pn="section-3.1-2"> The RFC Editor is an expert technical editor and series editor, acting to support the mission of the RFC Series. As such, the RFC Editor is the implementer handling the editorial management of the RFC Series, in accordance with the defined processes. In addition, the RFC Editor is expected to be the expert and prime mover in discussions about policies for editing, publishing, and archiving RFCs. </t> </section> <section anchor="iab"title="IAB"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-3.2"> <name slugifiedName="name-iab">IAB</name> <t pn="section-3.2-1"> In this model, the role of the IAB is to ensure that the RFC Series mission is being appropriately fulfilled for the whole community for which it was created. The IAB does not, organizationally, have comprehensive publishing or editorial expertise. Therefore, the role of the IAB is focused on ensuring that principles are met, the appropriate bodies and communities are duly informed and consulted, and the RFC Editor has what it needs in order to execute on the material that is in their mandate. </t><t><t pn="section-3.2-2"> It is the responsibility of the IAB to approve the appointment of the RFC Editor and to approve the general policy followed by the RFC Editor. </t> </section> <section anchor="ops"title="Operational Oversight"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-3.3"> <name slugifiedName="name-operational-oversight">Operational Oversight</name> <t pn="section-3.3-1"> The IETF Administration Limited Liability Company (IETF LLC), as part of the IETF Administrative Support Activity (IASA), is responsible for administrative and financial matters for the IETF, the IAB, and the Internet Research Task Force (IRTF) <xreftarget="I-D.ietf-iasa2-rfc4071bis"/>.target="RFC8711" format="default" sectionFormat="of" derivedContent="RFC8711"/>. The IASA is tasked with providing the funding for the RFC Editor. The IASA, through the IETF Executive Director, provides contractual and financial oversight of the RFC Editor. Additionally, as described inSection 3.1 of<xreftarget="I-D.ietf-iasa2-rfc6635bis"/>,target="RFC8728" section="3.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8728#section-3.1" derivedContent="RFC8728"/>, the RFC Series Oversight Committee (RSOC), acting with authority delegated from the IAB, is responsible for ensuring that the RFC Series is run in a transparent and accountable manner, including design and execution of the RFC Series Editor selection process. </t><t><t pn="section-3.3-2"> The IETF Executive Director works with the IAB to identify suitable persons or entities to fulfill the mandate of the RFC Production Center and the RFC Publisher roles as defined in <xreftarget="I-D.ietf-iasa2-rfc6635bis"/>.target="RFC8728" format="default" sectionFormat="of" derivedContent="RFC8728"/>. </t><t><t pn="section-3.3-3"> The IETF Executive Director establishes appropriate contractual agreements with the selected persons or entities to carry out the work that will satisfy the technical publication requirements defined for the various RFC input streams (see <xreftarget="reqs"/>).target="reqs" format="default" sectionFormat="of" derivedContent="Section 5.2"/>). The IETF Executive Director may define additional operational requirements and policies for management purposes to meet the requirements defined by the various communities. </t><t><t pn="section-3.3-4"> The IETF Administration LLC Board approves a budget for operation of the RFC Editor activity, and the IETF Executive Director establishes and manages the necessary operational agreements for the RFC Editor activity. </t> </section> <sectiontitle="Policy Oversight"> <t>anchor="policyoversight" numbered="true" toc="include" removeInRFC="false" pn="section-3.4"> <name slugifiedName="name-policy-oversight">Policy Oversight</name> <t pn="section-3.4-1"> The IAB monitors the effectiveness of the policies in force and their implementation to ensure that the RFC Editor activity meets the editorial management and document publication needs as referenced in this document. In the event of serious non-conformance, the IAB, either on its own initiative or at the request of the IETF Administration LLC Board, may require the IETF Executive Director to vary or terminate and renegotiate the arrangements for the RFC Editor activity. </t> </section> </section> <section anchor="framework"title="Framework"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-framework">Framework</name> <t pn="section-4-1"> With the RFC Series mission outlined above, this document describes a framework for supporting </t><t><list style="symbols"> <t><ul spacing="normal" bare="false" empty="false" pn="section-4-2"> <li pn="section-4-2.1"> the operational implementation of the RFC Series,</t> </list></t> <t></li> </ul> <t pn="section-4-3"> based on </t><t><list style="symbols"> <t><ul spacing="normal" bare="false" empty="false" pn="section-4-4"> <li pn="section-4-4.1"> public process and definition documents,</t> </list></t> <t></li> </ul> <t pn="section-4-5"> for which there are </t><t><list style="symbols"> <t><ul spacing="normal" bare="false" empty="false" pn="section-4-6"> <li pn="section-4-6.1"> clear responsibilities and mechanisms for update and change.</t> </list></t> <t></li> </ul> <t pn="section-4-7"> Generally speaking, the RFC Editor is responsible for the operational implementation of the RFC Series. As outlined in <xreftarget="ops"/>,target="ops" format="default" sectionFormat="of" derivedContent="Section 3.3"/>, the IETF Executive Director provides the oversight of this operational role. </t><t><t pn="section-4-8"> The process and definition documents are detailed below, including responsibility for the individual process documents (maintenance and update). The RFC Editor works with the appropriate community to ensure that the process documents reflect current requirements. The IAB is charged with the role of verifying that appropriate community input has been sought and that any changes appropriately account for community requirements. </t><t><t pn="section-4-9"> There are three categories of activity, and a fourth category of series-wide rules and guidelines, described for implementing the RFC Series to support its mission: </t><t><list style="symbols"> <t><ul spacing="normal" bare="false" empty="false" pn="section-4-10"> <li pn="section-4-10.1"> Approval of documents.</t> <t></li> <li pn="section-4-10.2"> Editing, processing, and publication of documents.</t> <t></li> <li pn="section-4-10.3"> Archiving and indexing the documents and making them accessible.</t> <t></li> <li pn="section-4-10.4"> Series rules and guidelines.</t> </list></t></li> </ul> <sectiontitle="Document Approval"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-4.1"> <name slugifiedName="name-document-approval">Document Approval</name> <t pn="section-4.1-1"> The RFC Series mission implicitly requires that documents be reviewed and approved for acceptance into the series. </t> <sectiontitle="Definition"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-4.1.1"> <name slugifiedName="name-definition">Definition</name> <t pn="section-4.1.1-1"> <xreftarget="approval"/>target="approval" format="default" sectionFormat="of" derivedContent="Section 5.1"/> describes the different streams of documents that are put to the RFC Editor for publication as RFCs today. While there may be general policies for approval of documents as RFCs (to ensure the coherence of the RFC Series), there are also policies defined for the approval of documents in each stream. Generally speaking, there is a different approving body for each stream. The current definitions are catalogued in <xreftarget="approval"/>.target="approval" format="default" sectionFormat="of" derivedContent="Section 5.1"/>. </t> </section> <sectiontitle="Operational Implementation"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-4.1.2"> <name slugifiedName="name-operational-implementation">Operational Implementation</name> <t pn="section-4.1.2-1"> Each stream has its own documented approval process. The RFC Editor is responsible for the approval of documents in one of the streams (Independent Submission stream, see <xreftarget="independent-approval"/>)target="independent-approval" format="default" sectionFormat="of" derivedContent="Section 5.1.4"/>) and works with the other approving bodies to ensure smooth passage of approved documents into the next phases, ultimately to publication and archiving as an RFC. </t> </section> <sectiontitle="Process Change"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-4.1.3"> <name slugifiedName="name-process-change">Process Change</name> <t pn="section-4.1.3-1"> From time to time, it may be necessary to change the approval processes for any given stream, or even add or remove streams. This may occur when the RFC Editor, the IAB, the body responsible for a given stream of documents, or the community determines that there are issues to be resolved in general for RFC approval or for per-stream approval processes. </t><t><t pn="section-4.1.3-2"> In this framework, the general approach is that the IAB will work with the RFC Editor and other parties to get communityinputinput, and it will verify that any changes appropriately account for community requirements. </t> </section> <sectiontitle="Existingnumbered="true" toc="include" removeInRFC="false" pn="section-4.1.4"> <name slugifiedName="name-existing-approval-process-d">Existing Approval ProcessDocuments"> <t>Documents</name> <t pn="section-4.1.4-1"> The existing documents describing the approval processes for each stream are detailed in <xreftarget="approval"/>.target="approval" format="default" sectionFormat="of" derivedContent="Section 5.1"/>. </t> </section> </section> <sectiontitle="Editing,numbered="true" toc="include" removeInRFC="false" pn="section-4.2"> <name slugifiedName="name-editing-processing-and-publ">Editing, Processing, and Publication ofDocuments"> <t>Documents</name> <t pn="section-4.2-1"> Producing and maintaining a coherent, well-edited document series requires specialized skills and subject matter expertise. This is the domain of the RFC Editor. Nevertheless, the community served by the RFC Series and the communities served by the individual streams of RFCs have requirements that help define the nature of the series. </t> <sectiontitle="Definition"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-4.2.1"> <name slugifiedName="name-definition-2">Definition</name> <t pn="section-4.2.1-1"> General and stream-specific requirements for the RFC Series are documented in community-approved documents (catalogued in <xreftarget="reqs"/>target="reqs" format="default" sectionFormat="of" derivedContent="Section 5.2"/> below). </t><t><t pn="section-4.2.1-2"> Any specific interfaces, numbers, or concrete values required to make the requirements operational are the subject of agreements between the IASA and the RFC Editor (e.g., contracts, statements of work, service level agreements, etc). </t> </section> <sectiontitle="Operational Implementation"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-4.2.2"> <name slugifiedName="name-operational-implementation-2">Operational Implementation</name> <t pn="section-4.2.2-1"> The RFC Editor is responsible for ensuring that editing, processing, and publication of RFCs are carried out in a way that is consistent with the requirements laid out in the appropriate documents. The RFC Editor works with the IASA to provide regular reporting and feedback on these operations. </t> </section> <sectiontitle="Process Change"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-4.2.3"> <name slugifiedName="name-process-change-2">Process Change</name> <t pn="section-4.2.3-1"> From time to time, it may be necessary to change the requirements for any given stream, or the RFC Series in general. This may occur when the RFC Editor, the IAB, the approval body for a given stream of documents, or the community determines that there are issues to be resolved in general for RFCs or for per-stream requirements. </t><t><t pn="section-4.2.3-2"> In this model, the general approach is that the IAB will work with the RFC Editor to get communityinputinput, and it will approve changes by validating appropriate consideration of community requirements. </t> </section> <sectiontitle="Existingnumbered="true" toc="include" removeInRFC="false" pn="section-4.2.4"> <name slugifiedName="name-existing-process-documents">Existing ProcessDocuments"> <t>Documents</name> <t pn="section-4.2.4-1"> Documents describing existing requirements for the streams are detailed in <xreftarget="reqs"/>.target="reqs" format="default" sectionFormat="of" derivedContent="Section 5.2"/>. </t> </section> </section> <sectiontitle="Archiving,numbered="true" toc="include" removeInRFC="false" pn="section-4.3"> <name slugifiedName="name-archiving-indexing-and-acce">Archiving, Indexing, andAccessibility"> <t>Accessibility</name> <t pn="section-4.3-1"> The activities of archiving, indexing, and making accessible the RFC Series can be informed by specific subject matter expertise in general document series editing. It is also important that they are informed by requirements from the whole community. As long as the RFC Series is to remain coherent, there should be uniform archiving and indexing of RFCs across all streams and a common method of accessing the resulting documents. </t> <sectiontitle="Definition"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-4.3.1"> <name slugifiedName="name-definition-3">Definition</name> <t pn="section-4.3.1-1"> In principle, there should be a community consensus document describing the archiving, indexing, and accessibility requirements for the RFC Series. In practice, we continue with the archive as built by the capable RFC Editors since the series' inception. </t><t><t pn="section-4.3.1-2"> Any specific concrete requirements for the archive, index, and accessibility operations are the subject of agreements between the IASA and the RFC Editor (e.g., contracts, statements of work, service level agreements, etc). </t> </section> <sectiontitle="Operational Implementation"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-4.3.2"> <name slugifiedName="name-operational-implementation-3">Operational Implementation</name> <t pn="section-4.3.2-1"> The RFC Editor is responsible for ensuring that the RFC archive and index are maintained appropriately and that the resulting documents are made available to anybody wishing to access them via the Internet. The RFC Editor works with the IASA for regular reporting and feedback. </t> </section> <sectiontitle="Process Change"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-4.3.3"> <name slugifiedName="name-process-change-3">Process Change</name> <t pn="section-4.3.3-1"> Should there be a community move to propose changes to the requirements for the RFC archive and index or accessibility, the IAB will work with the RFC Editor to get communityinputinput, and it will approve changes by validating appropriate consideration of community requirements. </t> </section> <sectiontitle="Existingnumbered="true" toc="include" removeInRFC="false" pn="section-4.3.4"> <name slugifiedName="name-existing-process-documents-2">Existing ProcessDocuments"> <t>Documents</name> <t pn="section-4.3.4-1"> There are no applicable process documents. </t> </section> </section> <sectiontitle="Series-Widenumbered="true" toc="include" removeInRFC="false" pn="section-4.4"> <name slugifiedName="name-series-wide-guidelines-and-">Series-Wide Guidelines andRules"> <t>Rules</name> <t pn="section-4.4-1"> The RFC Series style and content can be shaped by subject matter expertise in document series editing. They are also informed by requirements by the using community. As long as the RFC Series is to remain coherent, there should be uniform style and content for RFCs across all streams. This includes, but is not limited to, acceptable language, use of references, and copyright rules. </t> <sectiontitle="Definition"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-4.4.1"> <name slugifiedName="name-definition-4">Definition</name> <t pn="section-4.4.1-1"> In principle, there should be a community consensus document (or set of documents) describing the content requirements for the RFC Series. In practice, some do exist, though some need reviewing and more may be needed over time. </t> </section> <sectiontitle="Operational Implementation"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-4.4.2"> <name slugifiedName="name-operational-implementation-4">Operational Implementation</name> <t pn="section-4.4.2-1"> The RFC Editor is responsible for ensuring that the RFC Series guidelines are upheld within the RFC Series. </t> </section> <sectiontitle="Process Change"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-4.4.3"> <name slugifiedName="name-process-change-4">Process Change</name> <t pn="section-4.4.3-1"> When additions or changes are needed to series-wide definitions, the IAB will work with the RFC Editor and stream stakeholders to get community input and review. The IAB will approve changes by validating appropriate consideration of community requirements. </t> </section> <sectiontitle="Existingnumbered="true" toc="include" removeInRFC="false" pn="section-4.4.4"> <name slugifiedName="name-existing-process-documents-3">Existing ProcessDocuments"> <t>Documents</name> <t pn="section-4.4.4-1"> Existing series-wide rules and guidelines documents include: </t><t><list style="symbols"> <t><ul spacing="normal" bare="false" empty="false" pn="section-4.4.4-2"> <li pn="section-4.4.4-2.1"> RFC Style Guide <xreftarget="RFC7223"/>, </t> <t>target="RFC7322" format="default" sectionFormat="of" derivedContent="RFC7322"/>, </li> <li pn="section-4.4.4-2.2"> The Use of Non-ASCII Characters in RFCs <xreftarget="RFC7997"/>, </t> <t>target="RFC7997" format="default" sectionFormat="of" derivedContent="RFC7997"/>, </li> <li pn="section-4.4.4-2.3"> Copyright and intellectual property rules <xreftarget="RFC5378"/>, </t> <t>target="RFC5378" format="default" sectionFormat="of" derivedContent="RFC5378"/>, </li> <li pn="section-4.4.4-2.4"> Normative references <xreftarget="RFC3967"/>target="RFC3967" format="default" sectionFormat="of" derivedContent="RFC3967"/> <xreftarget="RFC4897"/>. </t> </list></t>target="RFC4897" format="default" sectionFormat="of" derivedContent="RFC4897"/>, <xref target="RFC8067" format="default" sectionFormat="of" derivedContent="RFC8067"/>. </li> </ul> </section> </section> </section> <section anchor="streams"title="RFC Streams"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-5"> <name slugifiedName="name-rfc-streams">RFC Streams</name> <t pn="section-5-1"> Various contributors provide input to the RFC Series. These contributors come from several different communities, each with its own defined process for approving documents that will be published by the RFC Editor. This is nothing new; however, over time the various communities and document requirements have grown and separated. In order to promote harmony in discussing the collective set of requirements, it is useful to recognize each in their own space -- and they are referred to here as "streams". </t><t><t pn="section-5-2"> Note that by identifying separate streams, there is no intention of dividing them or undermining their management as one series. Rather, the opposite is true -- by clarifying the constituent parts, it is easier to make them work together without the friction that sometimes arises when discussing various requirements. </t><t><t pn="section-5-3"> The subsections below identify the streams that exist today. There is no immediate expectation of new streams being created, and it is preferable that new streams NOT be created. Creation of streams and all policies surrounding general changes to the RFC Series are discussed above in <xreftarget="framework"/>.target="framework" format="default" sectionFormat="of" derivedContent="Section 4"/>. </t> <section anchor="approval"title="RFCnumbered="true" toc="include" removeInRFC="false" pn="section-5.1"> <name slugifiedName="name-rfc-approval-processes">RFC ApprovalProcesses"> <t>Processes</name> <t pn="section-5.1-1"> Processes for approval of documents (or requirements) for each stream are defined by the community that defines the stream. The IAB is charged with the role of verifying that appropriate community input has been sought and that the changes are consistent with the RFC Series mission and this overall framework. </t><t><t pn="section-5.1-2"> The RFC Editor is expected to publish all documents passed to it after appropriate review and approval in one of the identified streams. </t> <section anchor="ietf-approval"title="IETFnumbered="true" toc="include" removeInRFC="false" pn="section-5.1.1"> <name slugifiedName="name-ietf-document-stream">IETF DocumentStream"> <t>Stream</name> <t pn="section-5.1.1-1"> The IETF document stream includes IETF WG documents as well as "individual submissions" sponsored by an IESG area director. Any document being published as part of the IETF standards process must follow this stream -- no other stream can approve Standards-Track RFCs or Best Current Practice (BCP) RFCs. </t><t><t pn="section-5.1.1-2"> Approval of documents in the IETF stream is defined by </t><t><list style="symbols"> <t><ul spacing="normal" bare="false" empty="false" pn="section-5.1.1-3"> <li pn="section-5.1.1-3.1"> the IETF standards process <xreftarget="RFC2026"/>target="RFC2026" format="default" sectionFormat="of" derivedContent="RFC2026"/> (and its successors).</t> <t></li> <li pn="section-5.1.1-3.2"> the IESG process for sponsoring individual submissions <xreftarget="SPONSOR"/>. </t> </list></t> <t>target="SPONSOR" format="default" sectionFormat="of" derivedContent="SPONSOR"/>. </li> </ul> <t pn="section-5.1.1-4"> Changes to the approval process for this stream are made by updating the IETF standards process documents. </t> </section> <section anchor="iab-approval"title="IABnumbered="true" toc="include" removeInRFC="false" pn="section-5.1.2"> <name slugifiedName="name-iab-document-stream">IAB DocumentStream"> <t>Stream</name> <t pn="section-5.1.2-1"> The IAB defines the processes by which it approves documents in its stream. Consistent with the above, any documents that the IAB wishes to publish as part of the IETF Standards Track (Standards or BCPs) are subject to the approval processes referred to in <xreftarget="ietf-approval"/>.target="ietf-approval" format="default" sectionFormat="of" derivedContent="Section 5.1.1"/>. </t><t><t pn="section-5.1.2-2"> The review and approval process for documents in the IAB stream is described in </t><t><list style="symbols"> <t><ul spacing="normal" bare="false" empty="false" pn="section-5.1.2-3"> <li pn="section-5.1.2-3.1"> the IAB process for review and approval of its documents <xreftarget="RFC4845"/>. </t> </list></t>target="RFC4845" format="default" sectionFormat="of" derivedContent="RFC4845"/>. </li> </ul> </section> <section anchor="irtf-approval"title="IRTFnumbered="true" toc="include" removeInRFC="false" pn="section-5.1.3"> <name slugifiedName="name-irtf-document-stream">IRTF DocumentStream"> <t>Stream</name> <t pn="section-5.1.3-1"> The IRTF is chartered as an activity of the IAB. With the approval of the IAB, the IRTF may publish and update a process for publication of its own, non-IETF Standards-Track, documents. </t><t><t pn="section-5.1.3-2"> The review and approval process for documents in the IRTF stream is described in </t><t><list style="symbols"> <t><ul spacing="normal" bare="false" empty="false" pn="section-5.1.3-3"> <li pn="section-5.1.3-3.1"> IRTF Research Group RFCs <xreftarget="RFC5743"/>. </t> </list></t>target="RFC5743" format="default" sectionFormat="of" derivedContent="RFC5743"/>. </li> </ul> </section> <section anchor="independent-approval"title="Independentnumbered="true" toc="include" removeInRFC="false" pn="section-5.1.4"> <name slugifiedName="name-independent-submission-stre">Independent SubmissionStream"> <t>Stream</name> <t pn="section-5.1.4-1"> The RFC Series has always served a broader Internet technical community than the IETF. The "Independent Submission" stream is defined to provide review and (possible) approval of documents that are outside the scope of the streams identified above. </t><t><t pn="section-5.1.4-2"> Generally speaking, approval of documents in this stream falls under the purview of the RFC Editor, and the RFC Editor seeks input to its review from the IESG. </t><t><t pn="section-5.1.4-3"> The process for reviewing and approving documents in the Independent Submission stream is defined by </t><t><list style="symbols"> <t><ul spacing="normal" bare="false" empty="false" pn="section-5.1.4-4"> <li pn="section-5.1.4-4.1"> Procedures for Rights Handling in the RFC Independent Submission Stream <xreftarget="RFC5744"/>, </t> <t>target="RFC5744" format="default" sectionFormat="of" derivedContent="RFC5744"/>, </li> <li pn="section-5.1.4-4.2"> Independent Submission Editor Model <xreftarget="I-D.ietf-iasa2-rfc6548bis"/>, </t> <t>target="RFC8730" format="default" sectionFormat="of" derivedContent="RFC8730"/>, </li> <li pn="section-5.1.4-4.3"> Independent Submissions to the RFC Editor <xreftarget="RFC4846"/>, </t> <t>target="RFC4846" format="default" sectionFormat="of" derivedContent="RFC4846"/>, </li> <li pn="section-5.1.4-4.4"> The IESG and RFC Editor Documents: Procedures <xreftarget="RFC3932"/>. </t> </list></t>target="RFC5742" format="default" sectionFormat="of" derivedContent="RFC5742"/>. </li> </ul> </section> </section> <section anchor="reqs"title="RFCnumbered="true" toc="include" removeInRFC="false" pn="section-5.2"> <name slugifiedName="name-rfc-technical-publication-r">RFC Technical PublicationRequirements"> <t>Requirements</name> <t pn="section-5.2-1"> The Internet engineering and research community has not only grown, it has become more diverse, and sometimes more demanding. The IETF, as a standards-developing organization, has publication requirements that extend beyond those of an academic journal. The IAB does not have the same interdependence with IANA assignments as the IETF stream does. Therefore, there is the need to both codify the publishing requirements of each stream, and endeavor to harmonize them to the extent that is reasonable. </t><t><t pn="section-5.2-2"> Therefore, it is expected that the community of effort behind each document stream will outline their technical publication requirements. </t><t><t pn="section-5.2-3"> As part of the RFC Editor oversight, the IAB must agree that the requirements are consistent with and implementable as part of the RFC Editor activity. </t> <section anchor="ietf-req"title="IETF Documents"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-5.2.1"> <name slugifiedName="name-ietf-documents">IETF Documents</name> <t pn="section-5.2.1-1"> The requirements for this stream are defined in <xreftarget="RFC4714"/>.target="RFC4714" format="default" sectionFormat="of" derivedContent="RFC4714"/>. </t> </section> <section anchor="iab-req"title="IAB Documents"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-5.2.2"> <name slugifiedName="name-iab-documents">IAB Documents</name> <t pn="section-5.2.2-1"> Although they were developed for the IETF standards process, the IAB has identified applicable requirements in <xreftarget="RFC4714"/>target="RFC4714" format="default" sectionFormat="of" derivedContent="RFC4714"/> for its stream. In addition, procedures related to IPR for the IAB stream are captured in <xreftarget="RFC5745"/>.target="RFC5745" format="default" sectionFormat="of" derivedContent="RFC5745"/>. </t><t><t pn="section-5.2.2-2"> If the IAB elects to define other requirements, they should deviate minimally from those (in an effort to keep the collective technical publication requirements reasonably managed by one technical publisher). </t> </section> <section anchor="irtf-req"title="IRTF Documents"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-5.2.3"> <name slugifiedName="name-irtf-documents">IRTF Documents</name> <t pn="section-5.2.3-1"> The IRTF has identified applicable requirements in <xreftarget="RFC5743"/>target="RFC5743" format="default" sectionFormat="of" derivedContent="RFC5743"/> for its stream. </t><t><t pn="section-5.2.3-2"> If the IRTF elects to define other requirements, they should deviate minimally from those (in an effort to keep the collective technical publication requirements reasonably managed by one technical publisher). </t> </section> <section anchor="independent-req"title="Independent Submissions"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-5.2.4"> <name slugifiedName="name-independent-submissions">Independent Submissions</name> <t pn="section-5.2.4-1"> Procedures and processes for the Independent Stream are described in <xreftarget="RFC4846"/>target="RFC4846" format="default" sectionFormat="of" derivedContent="RFC4846"/> and <xreftarget="I-D.ietf-iasa2-rfc6548bis"/>.target="RFC8730" format="default" sectionFormat="of" derivedContent="RFC8730"/>. </t><t><t pn="section-5.2.4-2"> Although they were developed for the IETF standards process, the RFC Editor has identified applicable requirements in <xreftarget="RFC4714"/>target="RFC4714" format="default" sectionFormat="of" derivedContent="RFC4714"/> for theindependent submissionsIndependent Submissions stream. In addition, procedures related to IPR for the independent submissions stream are captured in <xreftarget="RFC5744"/>.target="RFC5744" format="default" sectionFormat="of" derivedContent="RFC5744"/>. </t><t><t pn="section-5.2.4-3"> If the RFC Editor elects to define other requirements, they should deviate minimally from those (in an effort to keep the collective technical publication requirements reasonably managed by one technical publisher). </t> </section> </section> </section> <section anchor="security"title="Security Considerations"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-6"> <name slugifiedName="name-security-considerations">Security Considerations</name> <t pn="section-6-1"> The processes for the publication of documents must prevent the introduction of unapproved changes. Since the RFC Editor maintains the index of publications, sufficient security must be in place to prevent these published documents from being changed by external parties. The archive of RFC documents, any source documents needed to recreate the RFC documents, and any associated original documents (such as lists of errata, tools, and, for some early items, non-machine readable originals) need to be secured against failure of the storage medium and other similar disasters. </t> </section> <section anchor="changes"title="Changesnumbered="true" toc="include" removeInRFC="false" pn="section-7"> <name slugifiedName="name-changes-since-rfc-4844">Changes SinceRFC4844"> <t>RFC 4844</name> <t pn="section-7-1"> Sections3.3, 3.4,<xref target="ops" format="counter" sectionFormat="of" derivedContent="3.3"/>, <xref target="policyoversight" format="counter" sectionFormat="of" derivedContent="3.4"/>, and4<xref target="framework" format="counter" sectionFormat="of" derivedContent="4"/> have been updated to align with the restructuring of the IETF Administrative Support Activity (IASA). Under the new structure, the IETF LLC performs the tasks related to IASA that were previously assigned to the IETF Administrative Director and to the Internet Society. </t><t><t pn="section-7-2"> Many references were updated to point to the most recent documents. </t><t><t pn="section-7-3"> Minor editorial changes were made to reflect 10 years of using the framework provided in RFC 4884. For example, RFC 4844 said, "... this document sets out a revised framework ...", and it is now more appropriate to say, "... this document sets out the framework ...". </t> </section><!-- <section title="Acknowledgements"> <t> </t> </section> --></middle> <back> <referencestitle="Informative References"> &IASA2; &INDSUB; &MODEL; &RFC1358; &RFC1601; &RFC2026; &RFC2555; &RFC2850; &RFC3932; &RFC3967; &RFC4714; &RFC4845; &RFC4846; &RFC4897; &RFC5378; &RFC5743; &RFC5744; &RFC5745; &RFC7223; &RFC7997;pn="section-8"> <name slugifiedName="name-informative-references">Informative References</name> <referenceanchor="SPONSOR" target="http://www.ietf.org/iesg/statement/ad-sponsoring-docs.html">anchor="RFC1358" target="https://www.rfc-editor.org/info/rfc1358" quoteTitle="true" derivedAnchor="RFC1358"> <front><title>Guidance on Area Director Sponsoring<title>Charter ofDocuments</title> <author><organization>IESG</organization></author>the Internet Architecture Board (IAB)</title> <author initials="L." surname="Chapin" fullname="L. Chapin"> <organization showOnFrontPage="true"/> </author> <datemonth="March" year="2007"/>year="1992" month="August"/> <abstract> <t>The Internet Architecture Board (IAB) shall be constituted and shall operate as a technical advisory group of the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard.</t> </abstract> </front> <seriesInfo name="RFC" value="1358"/> <seriesInfo name="DOI" value="10.17487/RFC1358"/> </reference> <reference anchor="RFC1601" target="https://www.rfc-editor.org/info/rfc1601" quoteTitle="true" derivedAnchor="RFC1601"> <front> <title>Charter of the Internet Architecture Board (IAB)</title> <author initials="C." surname="Huitema" fullname="C. Huitema"> <organization showOnFrontPage="true"/> </author> <date year="1994" month="March"/> <abstract> <t>This memo documents the composition, selection, roles, and organization of the Internet Architecture Board and its subsidiary organizations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</t> </abstract> </front> <seriesInfo name="RFC" value="1601"/> <seriesInfo name="DOI" value="10.17487/RFC1601"/> </reference> <reference anchor="RFC2026" target="https://www.rfc-editor.org/info/rfc2026" quoteTitle="true" derivedAnchor="RFC2026"> <front> <title>The Internet Standards Process -- Revision 3</title> <author initials="S." surname="Bradner" fullname="S. Bradner"> <organization showOnFrontPage="true"/> </author> <date year="1996" month="October"/> <abstract> <t>This 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.</t> </abstract> </front> <seriesInfo name="BCP" value="9"/> <seriesInfo name="RFC" value="2026"/> <seriesInfo name="DOI" value="10.17487/RFC2026"/> </reference> <reference anchor="RFC2555" target="https://www.rfc-editor.org/info/rfc2555" quoteTitle="true" derivedAnchor="RFC2555"> <front> <title>30 Years of RFCs</title> <author initials="RFC" surname="Editor" fullname="RFC Editor"> <organization showOnFrontPage="true"/> </author> <author initials="et" surname="al." fullname="et al."> <organization showOnFrontPage="true"/> </author> <date year="1999" month="April"/> <abstract> <t>The rest of this document contains a brief recollection from the present RFC Editor Joyce K. Reynolds, followed by recollections from three pioneers: Steve Crocker who wrote RFC 1, Vint Cerf whose long-range vision continues to guide us, and Jake Feinler who played a key role in the middle years of the RFC series. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="2555"/> <seriesInfo name="DOI" value="10.17487/RFC2555"/> </reference> <reference anchor="RFC2850" target="https://www.rfc-editor.org/info/rfc2850" quoteTitle="true" derivedAnchor="RFC2850"> <front> <title>Charter of the Internet Architecture Board (IAB)</title> <author> <organization showOnFrontPage="true">Internet Architecture Board</organization> </author> <author initials="B." surname="Carpenter" fullname="B. Carpenter" role="editor"> <organization showOnFrontPage="true"/> </author> <date year="2000" month="May"/> <abstract> <t>This memo documents the composition, selection, roles, and organization of the Internet Architecture Board. It replaces RFC 1601. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="39"/> <seriesInfo name="RFC" value="2850"/> <seriesInfo name="DOI" value="10.17487/RFC2850"/> </reference> <reference anchor="RFC3967" target="https://www.rfc-editor.org/info/rfc3967" quoteTitle="true" derivedAnchor="RFC3967"> <front> <title>Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level</title> <author initials="R." surname="Bush" fullname="R. Bush"> <organization showOnFrontPage="true"/> </author> <author initials="T." surname="Narten" fullname="T. Narten"> <organization showOnFrontPage="true"/> </author> <date year="2004" month="December"/> <abstract> <t>IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies). For example, a standards track document may not have a normative reference to an informational RFC. Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards or IETF-specific modes of use of such standards. This document clarifies and updates the procedure used in these circumstances. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="97"/> <seriesInfo name="RFC" value="3967"/> <seriesInfo name="DOI" value="10.17487/RFC3967"/> </reference> <reference anchor="RFC4714" target="https://www.rfc-editor.org/info/rfc4714" quoteTitle="true" derivedAnchor="RFC4714"> <front> <title>Requirements for IETF Technical Publication Service</title> <author initials="A." surname="Mankin" fullname="A. Mankin"> <organization showOnFrontPage="true"/> </author> <author initials="S." surname="Hayes" fullname="S. Hayes"> <organization showOnFrontPage="true"/> </author> <date year="2006" month="October"/> <abstract> <t>The work of the IETF is to discuss, develop, and disseminate technical specifications to support the Internet's operation. Technical publication is the process by which that output is disseminated to the community at large. As such, it is important to understand the requirements on the publication process. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="4714"/> <seriesInfo name="DOI" value="10.17487/RFC4714"/> </reference> <reference anchor="RFC4845" target="https://www.rfc-editor.org/info/rfc4845" quoteTitle="true" derivedAnchor="RFC4845"> <front> <title>Process for Publication of IAB RFCs</title> <author initials="L." surname="Daigle" fullname="L. Daigle" role="editor"> <organization showOnFrontPage="true"/> </author> <author> <organization showOnFrontPage="true">Internet Architecture Board</organization> </author> <date year="2007" month="July"/> <abstract> <t>From time to time, the Internet Architecture Board (IAB) publishes documents as Requests for Comments (RFCs). This document defines the process by which those documents are produced, reviewed, and published in the RFC Series. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="4845"/> <seriesInfo name="DOI" value="10.17487/RFC4845"/> </reference> <reference anchor="RFC4846" target="https://www.rfc-editor.org/info/rfc4846" quoteTitle="true" derivedAnchor="RFC4846"> <front> <title>Independent Submissions to the RFC Editor</title> <author initials="J." surname="Klensin" fullname="J. Klensin" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="D." surname="Thaler" fullname="D. Thaler" role="editor"> <organization showOnFrontPage="true"/> </author> <date year="2007" month="July"/> <abstract> <t>There is a long-standing tradition in the Internet community, predating the Internet Engineering Task Force (IETF) by many years, of use of the RFC Series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms. These documents, known as "Independent Submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants. This document discusses the Independent Submission model and some reasons why it is important. It then describes editorial and processing norms that can be used for Independent Submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="4846"/> <seriesInfo name="DOI" value="10.17487/RFC4846"/> </reference> <reference anchor="RFC4897" target="https://www.rfc-editor.org/info/rfc4897" quoteTitle="true" derivedAnchor="RFC4897"> <front> <title>Handling Normative References to Standards-Track Documents</title> <author initials="J." surname="Klensin" fullname="J. Klensin"> <organization showOnFrontPage="true"/> </author> <author initials="S." surname="Hartman" fullname="S. Hartman"> <organization showOnFrontPage="true"/> </author> <date year="2007" month="June"/> <abstract> <t>The Internet Engineering Task Force (IETF) and Request for Comments (RFC) Editor have a long-standing rule that a document at a given maturity level cannot be published until all of the documents that it references as normative are at that maturity level or higher. This rule has sometimes resulted in very long publication delays for documents and some claims that it was a major obstruction to advancing documents in maturity level. The IETF agreed on a way to bypass this rule with RFC 3967. This document describes a simpler procedure for downward references to Standards-Track and Best Current Practice (BCP) documents, namely "note and move on". The procedure in RFC 3967 still applies for downward references to other classes of documents. In both cases, annotations should be added to such References. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="97"/> <seriesInfo name="RFC" value="4897"/> <seriesInfo name="DOI" value="10.17487/RFC4897"/> </reference> <reference anchor="RFC5378" target="https://www.rfc-editor.org/info/rfc5378" quoteTitle="true" derivedAnchor="RFC5378"> <front> <title>Rights Contributors Provide to the IETF Trust</title> <author initials="S." surname="Bradner" fullname="S. Bradner" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Contreras" fullname="J. Contreras" role="editor"> <organization showOnFrontPage="true"/> </author> <date year="2008" month="November"/> <abstract> <t>The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="78"/> <seriesInfo name="RFC" value="5378"/> <seriesInfo name="DOI" value="10.17487/RFC5378"/> </reference> <reference anchor="RFC5742" target="https://www.rfc-editor.org/info/rfc5742" quoteTitle="true" derivedAnchor="RFC5742"> <front> <title>IESG Procedures for Handling of Independent and IRTF Stream Submissions</title> <author initials="H." surname="Alvestrand" fullname="H. Alvestrand"> <organization showOnFrontPage="true"/> </author> <author initials="R." surname="Housley" fullname="R. Housley"> <organization showOnFrontPage="true"/> </author> <date year="2009" month="December"/> <abstract> <t>This document describes the procedures used by the IESG for handling documents submitted for RFC publication from the Independent Submission and IRTF streams. </t> <t>This document updates procedures described in RFC 2026 and RFC 3710. This memo documents an Internet Best Current Practice.</t> </abstract> </front> <seriesInfo name="BCP" value="92"/> <seriesInfo name="RFC" value="5742"/> <seriesInfo name="DOI" value="10.17487/RFC5742"/> </reference> <reference anchor="RFC5743" target="https://www.rfc-editor.org/info/rfc5743" quoteTitle="true" derivedAnchor="RFC5743"> <front> <title>Definition of an Internet Research Task Force (IRTF) Document Stream</title> <author initials="A." surname="Falk" fullname="A. Falk"> <organization showOnFrontPage="true"/> </author> <date year="2009" month="December"/> <abstract> <t>This memo defines the publication stream for RFCs from the Internet Research Task Force. Most documents undergoing this process will come from IRTF Research Groups, and it is expected that they will be published as Informational or Experimental RFCs by the RFC Editor. This document is not an Internet Standards Track specification; it is published for informational purposes.</t> </abstract> </front> <seriesInfo name="RFC" value="5743"/> <seriesInfo name="DOI" value="10.17487/RFC5743"/> </reference> <reference anchor="RFC5744" target="https://www.rfc-editor.org/info/rfc5744" quoteTitle="true" derivedAnchor="RFC5744"> <front> <title>Procedures for Rights Handling in the RFC Independent Submission Stream</title> <author initials="R." surname="Braden" fullname="R. Braden"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Halpern" fullname="J. Halpern"> <organization showOnFrontPage="true"/> </author> <date year="2009" month="December"/> <abstract> <t>This document specifies the procedures by which authors of RFC Independent Submission documents grant the community "incoming" rights for copying and using the text. It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="5744"/> <seriesInfo name="DOI" value="10.17487/RFC5744"/> </reference> <reference anchor="RFC5745" target="https://www.rfc-editor.org/info/rfc5745" quoteTitle="true" derivedAnchor="RFC5745"> <front> <title>Procedures for Rights Handling in the RFC IAB Stream</title> <author initials="A." surname="Malis" fullname="A. Malis" role="editor"> <organization showOnFrontPage="true"/> </author> <author> <organization showOnFrontPage="true">IAB</organization> </author> <date year="2009" month="December"/> <abstract> <t>This document specifies the procedures by which authors of RFC IAB stream documents grant the community "incoming" rights for copying and using the text. It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="5745"/> <seriesInfo name="DOI" value="10.17487/RFC5745"/> </reference> <reference anchor="RFC7322" target="https://www.rfc-editor.org/info/rfc7322" quoteTitle="true" derivedAnchor="RFC7322"> <front> <title>RFC Style Guide</title> <author initials="H." surname="Flanagan" fullname="H. Flanagan"> <organization showOnFrontPage="true"/> </author> <author initials="S." surname="Ginoza" fullname="S. Ginoza"> <organization showOnFrontPage="true"/> </author> <date year="2014" month="September"/> <abstract> <t>This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide. This document obsoletes RFC 2223, "Instructions to RFC Authors".</t> </abstract> </front> <seriesInfo name="RFC" value="7322"/> <seriesInfo name="DOI" value="10.17487/RFC7322"/> </reference> <reference anchor="RFC7997" target="https://www.rfc-editor.org/info/rfc7997" quoteTitle="true" derivedAnchor="RFC7997"> <front> <title>The Use of Non-ASCII Characters in RFCs</title> <author initials="H." surname="Flanagan" fullname="H. Flanagan" role="editor"> <organization showOnFrontPage="true"/> </author> <date year="2016" month="December"/> <abstract> <t>In order to support the internationalization of protocols and a more diverse Internet community, the RFC Series must evolve to allow for the use of non-ASCII characters in RFCs. While English remains the required language of the Series, the encoding of future RFCs will be in UTF-8, allowing for a broader range of characters than typically used in the English language. This document describes the RFC Editor requirements and gives guidance regarding the use of non-ASCII characters in RFCs.</t> <t>This document updates RFC 7322. Please view this document in PDF form to see the full text.</t> </abstract> </front> <seriesInfo name="RFC" value="7997"/> <seriesInfo name="DOI" value="10.17487/RFC7997"/> </reference> <reference anchor="RFC8067" target="https://www.rfc-editor.org/info/rfc8067" quoteTitle="true" derivedAnchor="RFC8067"> <front> <title>Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level</title> <author initials="B." surname="Leiba" fullname="B. Leiba"> <organization showOnFrontPage="true"/> </author> <date year="2017" month="January"/> <abstract> <t>RFC 3967 specifies a process for allowing normative references to documents at lower maturity levels ("downrefs"), which involves calling out the downref explicitly in the Last Call notice. That requirement has proven to be unnecessarily strict, and this document updates RFC 3967, allowing the IESG more flexibility in accepting downrefs in Standards Track documents.</t> </abstract> </front> <seriesInfo name="BCP" value="97"/> <seriesInfo name="RFC" value="8067"/> <seriesInfo name="DOI" value="10.17487/RFC8067"/> </reference> <reference anchor="RFC8711" target="https://www.rfc-editor.org/info/rfc8711" quoteTitle="true" derivedAnchor="RFC8711"> <front> <title>Structure of the IETF Administrative Support Activity, Version 2.0</title> <author initials="B." surname="Haberman"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Hall"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Livingood"> <organization showOnFrontPage="true"/> </author> <date year="2020" month="February"/> </front> <seriesInfo name="BCP" value="101"/> <seriesInfo name="RFC" value="8711"/> <seriesInfo name="DOI" value="10.17487/RFC8711"/> </reference> <reference anchor="RFC8728" target="https://www.rfc-editor.org/info/rfc8728" quoteTitle="true" derivedAnchor="RFC8728"> <front> <title>RFC Editor Model (Version 2)</title> <author initials="O" surname="Kolkman" fullname="Olaf Kolkman" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="J" surname="Halpern" fullname="Joel Halpern" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="R" surname="Hinden" fullname="Robert Hinden" role="editor"> <organization showOnFrontPage="true"/> </author> <date month="February" year="2020"/> </front> <seriesInfo name="RFC" value="8728"/> <seriesInfo name="DOI" value="10.17487/RFC8728"/> </reference> <reference anchor="RFC8730" target="https://www.rfc-editor.org/info/rfc8730" quoteTitle="true" derivedAnchor="RFC8730"> <front> <title>Independent Submission Editor Model</title> <author initials="N" surname="Brownlee" fullname="Nevil Brownlee" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="R" surname="Hinden" fullname="Robert Hinden" role="editor"> <organization showOnFrontPage="true"/> </author> <date month="February" year="2020"/> </front> <seriesInfoname="IESG Statement" value=""/>name="RFC" value="8730"/> <seriesInfo name="DOI" value="10.17487/RFC8730"/> </reference> <reference anchor="SPONSOR" target="http://www.ietf.org/iesg/statement/ad-sponsoring-docs.html" quoteTitle="true" derivedAnchor="SPONSOR"> <front> <title>Guidance on Area Director Sponsoring of Documents</title> <author> <organization showOnFrontPage="true">IESG</organization> </author> <date month="March" year="2007"/> </front> <refcontent>IESG Statement</refcontent> </reference> </references> <section anchor="iabcharterhistory"title="Anumbered="true" toc="include" removeInRFC="false" pn="section-appendix.a"> <name slugifiedName="name-a-retrospective-of-iab-char">A Retrospective of IAB Charters and RFCEditor"> <t>Editor</name> <t pn="section-appendix.a-1"> With this document, the IAB's role with respect to the RFC Series and the RFC Editor is being adjusted to work more directly with the RFC Editor and provide oversight to ensure the RFC Series mission principles and communities' input are addressed appropriately. </t><t><t pn="section-appendix.a-2"> This section provides an overview of the role of the IAB with respect to the RFC Editor as it has been presented in IAB Charter RFCs dating back to 1992. The point of this section is that the IAB's role has historically been substantive -- whether it is supposed to be directly responsible for the RFC Series' editorial management (circa 1992, <xreftarget="circa1992"/>),target="circa1992" format="default" sectionFormat="of" derivedContent="Appendix A.1"/>), or appointment of the RFC Editor organization and approval of general policy (circa 2000, <xreftarget="circa2000"/>).target="circa2000" format="default" sectionFormat="of" derivedContent="Appendix A.3"/>). </t> <section anchor="circa1992"title="1992"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-a.1"> <name slugifiedName="name-1992">1992</name> <t pn="section-a.1-1"> <xreftarget="RFC1358"/> says: </t> <figure><artwork>target="RFC1358" format="default" sectionFormat="of" derivedContent="RFC1358"/> says:</t> <blockquote pn="section-a.1-2"> <artwork name="" type="" align="left" alt="" pn="section-a.1-2.1"> [The IAB's] responsibilities shall include: [...] (2) The editorial management and publication of the Request for Comments (RFC) document series, which constitutes the archival publication series for Internet Standards and related contributions by the Internet research and engineering community.</artwork></figure></artwork> </blockquote> </section> <section anchor="circa1994"title="1994"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-a.2"> <name slugifiedName="name-1994">1994</name> <t pn="section-a.2-1"> <xreftarget="RFC1601"/> says: </t> <figure><artwork>target="RFC1601" format="default" sectionFormat="of" derivedContent="RFC1601"/> says:</t> <blockquote pn="section-a.2-2"> <artwork name="" type="" align="left" alt="" pn="section-a.2-2.1"> [The IAB's] responsibilities under this charter include: (d) RFC Series and IANA The IAB is responsible for editorial management and publication of the Request for Comments (RFC) document series, and for administration of the various Internet assigned numbers.which</artwork> </blockquote> <t pn="section-a.2-3"> Which it elaboratesasas: </t> <blockquote pn="section-a.2-4"> <artwork name="" type="" align="left" alt="" pn="section-a.2-4.1"> 2.4 RFC Series and Assigned Numbers The RFC Series constitutes the archival publication channel for Internet Standards and for other contributions by the Internet research and engineering community. The IAB shall select an RFC Editor, who shall be responsible for the editorial management and publication of the RFC Series.</artwork></figure></artwork> </blockquote> </section> <section anchor="circa2000"title="2000"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-a.3"> <name slugifiedName="name-2000">2000</name> <t pn="section-a.3-1"> The most recent IAB Charter <xreftarget="RFC2850"/>target="RFC2850" format="default" sectionFormat="of" derivedContent="RFC2850"/> says: </t><figure><artwork><blockquote pn="section-a.3-2"> <artwork name="" type="" align="left" alt="" pn="section-a.3-2.1"> (d) RFC Series and IANA The RFC Editor executes editorial management and publication of the IETF "Request for Comment" (RFC) document series, which is the permanent document repository of the IETF. The RFC Series constitutes the archival publication channel for Internet Standards and for other contributions by the Internet research and engineering community. RFCs are available free of charge to anyone via the Internet. The IAB must approve the appointment of an organization to act as RFC Editor and the general policy followed by the RFCEditor. </artwork></figure>Editor.</artwork> </blockquote> </section> </section> <sectiontitle="IABnumbered="false" toc="include" removeInRFC="false" pn="section-appendix.b"> <name slugifiedName="name-iab-members-at-the-time-of-">IAB Members at the Time ofApproval"> <t> {{Approval</name> <t pn="section-appendix.b-1"> The IAB members at the time of approval of RFCEditor: Fill in4844 were: </t> <ul empty="true" spacing="compact" bare="false" pn="section-appendix.b-2"> <li pn="section-appendix.b-2.1"> <t pn="section-appendix.b-2.1.1"><contact fullname="Bernard Aboba"/></t> </li> <li pn="section-appendix.b-2.2"> <t pn="section-appendix.b-2.2.1"><contact fullname="Loa Andersson"/></t> </li> <li pn="section-appendix.b-2.3"> <t pn="section-appendix.b-2.3.1"><contact fullname="Brian Carpenter"/></t> </li> <li pn="section-appendix.b-2.4"> <t pn="section-appendix.b-2.4.1"><contact fullname="Leslie Daigle"/></t> </li> <li pn="section-appendix.b-2.5"> <t pn="section-appendix.b-2.5.1"><contact fullname="Elwyn Davies"/></t> </li> <li pn="section-appendix.b-2.6"> <t pn="section-appendix.b-2.6.1"><contact fullname="Kevin Fall"/></t> </li> <li pn="section-appendix.b-2.7"> <t pn="section-appendix.b-2.7.1"><contact fullname="Olaf Kolkman"/></t> </li> <li pn="section-appendix.b-2.8"> <t pn="section-appendix.b-2.8.1"><contact fullname="Kurtis Lindqvist"/></t> </li> <li pn="section-appendix.b-2.9"> <t pn="section-appendix.b-2.9.1"><contact fullname="David Meyer"/></t> </li> <li pn="section-appendix.b-2.10"> <t pn="section-appendix.b-2.10.1"><contact fullname="David Oran"/></t> </li> <li pn="section-appendix.b-2.11"> <t pn="section-appendix.b-2.11.1"><contact fullname="Eric Rescorla"/></t> </li> <li pn="section-appendix.b-2.12"> <t pn="section-appendix.b-2.12.1"><contact fullname="Dave Thaler"/></t> </li> <li pn="section-appendix.b-2.13"> <t pn="section-appendix.b-2.13.1"><contact fullname="Lixia Zhang"/></t> </li> </ul> <t pn="section-appendix.b-3"> The IAB members at thecurrent membership. }}time of approval of this document were: </t> <ul empty="true" spacing="compact" bare="false" pn="section-appendix.b-4"> <li pn="section-appendix.b-4.1"> <t pn="section-appendix.b-4.1.1"><contact fullname="Jari Arkko"/></t> </li> <li pn="section-appendix.b-4.2"> <t pn="section-appendix.b-4.2.1"><contact fullname="Alissa Cooper"/></t> </li> <li pn="section-appendix.b-4.3"> <t pn="section-appendix.b-4.3.1"><contact fullname="Stephen Farrell"/></t> </li> <li pn="section-appendix.b-4.4"> <t pn="section-appendix.b-4.4.1"><contact fullname="Wes Hardaker"/></t> </li> <li pn="section-appendix.b-4.5"> <t pn="section-appendix.b-4.5.1"><contact fullname="Ted Hardie"/></t> </li> <li pn="section-appendix.b-4.6"> <t pn="section-appendix.b-4.6.1"><contact fullname="Christian Huitema"/></t> </li> <li pn="section-appendix.b-4.7"> <t pn="section-appendix.b-4.7.1"><contact fullname="Zhenbin Li"/></t> </li> <li pn="section-appendix.b-4.8"> <t pn="section-appendix.b-4.8.1"><contact fullname="Erik Nordmark"/></t> </li> <li pn="section-appendix.b-4.9"> <t pn="section-appendix.b-4.9.1"><contact fullname="Mark Nottingham"/></t> </li> <li pn="section-appendix.b-4.10"> <t pn="section-appendix.b-4.10.1"><contact fullname="Melinda Shore"/></t> </li> <li pn="section-appendix.b-4.11"> <t pn="section-appendix.b-4.11.1"><contact fullname="Jeff Tantsura"/></t> </li> <li pn="section-appendix.b-4.12"> <t pn="section-appendix.b-4.12.1"><contact fullname="Martin Thomson"/></t> </li> <li pn="section-appendix.b-4.13"> <t pn="section-appendix.b-4.13.1"><contact fullname="Brian Trammell"/></t> </li> </ul> </section> <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c"> <name slugifiedName="name-authors-addresses">Authors' Addresses</name> <author fullname="Russ Housley" initials="R." surname="Housley" role="editor"> <organization showOnFrontPage="true"/> <address> <email>housley@vigilsec.com</email> </address> </author> <author fullname="Leslie L. Daigle" initials="L." surname="Daigle" role="editor"> <organization showOnFrontPage="true"/> <address> <email>ldaigle@thinkingcat.com</email> </address> </author> </section> </back> </rfc>