Diff: rfc8729xml2.original.xml

	rfc8729xml2.original.xml	rfc8729.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version='1.0' encoding='utf-8'?>
	<?rfc toc="yes"?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" cons
	<?rfc tocompact="yes"?>	ensus="true" docName="draft-ietf-iasa2-rfc4844-bis-05" indexInclude="true" ipr="
	<?rfc tocdepth="4"?>	trust200902" number="8729" obsoletes="4844" prepTime="2020-02-26T18:04:03" scrip
	<?rfc rfcedstyle="yes"?>	ts="Common,Latin" sortRefs="true" submissionType="IAB" symRefs="true" tocDepth="
	<?rfc subcompact="no"?>	4" tocInclude="true" xml:lang="en">
	<?rfc symrefs="yes"?>	<link href="https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc4844-bis-05"
	<?rfc sortrefs="yes"?>	rel="prev"/>
		<link href="https://dx.doi.org/10.17487/rfc8729" rel="alternate"/>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [	<link href="urn:issn:2070-1721" rel="alternate"/>
	<!ENTITY RFC1358 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/referen
	ce.RFC.1358.xml'>
	<!ENTITY RFC1601 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/referen
	ce.RFC.1601.xml'>
	<!ENTITY RFC2026 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/referen
	ce.RFC.2026.xml'>
	<!ENTITY RFC2555 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/referen
	ce.RFC.2555.xml'>
	<!ENTITY RFC2850 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/referen
	ce.RFC.2850.xml'>
	<!ENTITY RFC3932 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/referen
	ce.RFC.3932.xml'>
	<!ENTITY RFC3967 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/referen
	ce.RFC.3967.xml'>
	<!ENTITY RFC5378 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/referen
	ce.RFC.5378.xml'>
	<!ENTITY RFC4714 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/referen
	ce.RFC.4714.xml'>
	<!ENTITY RFC4845 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/referen
	ce.RFC.4845.xml'>
	<!ENTITY RFC4846 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/referen
	ce.RFC.4846.xml'>
	<!ENTITY RFC4897 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/referen
	ce.RFC.4897.xml'>
	<!ENTITY RFC5743 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/referen
	ce.RFC.5743.xml'>
	<!ENTITY RFC5744 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/referen
	ce.RFC.5744.xml'>
	<!ENTITY RFC5745 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/referen
	ce.RFC.5745.xml'>
	<!ENTITY RFC7223 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/referen
	ce.RFC.7223.xml'>
	<!ENTITY RFC7997 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/referen
	ce.RFC.7997.xml'>
	<!ENTITY IASA2 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml3/refere
	nce.I-D.ietf-iasa2-rfc4071bis.xml'>
	<!ENTITY INDSUB PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml3/refere
	nce.I-D.ietf-iasa2-rfc6548bis.xml'>
	<!ENTITY MODEL PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml3/refere
	nce.I-D.ietf-iasa2-rfc6635bis.xml'>
	]>

	<rfc submissionType="IETF"
	docName="draft-ietf-iasa2-rfc4844-bis-05"
	obsoletes="4844"
	category="info"
	ipr="trust200902">

	<front>	<front>
	<title abbrev="The RFC Series and RFC Editor">The RFC Series and RFC Editor< /title>	<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 ">	<author fullname="Russ Housley" initials="R." surname="Housley" role="editor ">

	<organization abbrev="Vigil Security">Vigil Security, LLC</organization>	<organization showOnFrontPage="true"/>

	<address>	<address>
	<email>housley@vigilsec.com</email>	<email>housley@vigilsec.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Leslie L. Daigle" initials="L." surname="Daigle" role="edi tor">	<author fullname="Leslie L. Daigle" initials="L." surname="Daigle" role="edi tor">

	<organization abbrev="Thinking Cat">Thinking Cat Enterprises</organization >	<organization showOnFrontPage="true"/>
	<address>	<address>
	<email>ldaigle@thinkingcat.com</email>	<email>ldaigle@thinkingcat.com</email>
	</address>	</address>
	</author>	</author>

		<date month="02" year="2020"/>
	<date day= "30" month="October" year="2019"/>	<keyword>IASA</keyword>
		<keyword>IASA2</keyword>
	<!-- [rfced] Please insert any keywords (beyond those that appear in	<keyword>technical publisher</keyword>
	the title) for use on http://www.rfc-editor.org/search.html. -->	<abstract pn="section-abstract">
		<t pn="section-abstract-1">
	<keyword></keyword>

	<abstract>
	<t>
	This document describes the framework for an RFC Series and an RFC Editor	This document describes the framework for an RFC Series and an RFC Editor
	function that incorporate the principles of organized community	function that incorporate the principles of organized community
	involvement and accountability that has become necessary as the Internet	involvement and accountability that has become necessary as the Internet
	technical community has grown, thereby enabling the RFC Series to	technical community has grown, thereby enabling the RFC Series to

	continue to fulfill its mandate.	continue to fulfill its mandate. This document obsoletes RFC 4844.
	</t>

	<t>
	Cover Note:
	</t>
	<t>
	{{ RFC Editor: Please remove this cover note prior to publication. }}
	</t>
	<t>
	The IASA2 WG asks the IAB to publish this replacement for RFC 4844.
	The document is changed for alignment with the new structure for the
	IETF Administrative Support Activity (IASA), eliminating all references
	to the IETF Administrative Oversight Committee (IAOC).
	</t>	</t>

	</abstract>	</abstract>
		<boilerplate>
	</front>	<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
	<middle>	"exclude" pn="section-boilerplate.1">
		<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
	<section anchor="intro" title="Introduction">	>
	<t>	<t pn="section-boilerplate.1-1">
		This document is not an Internet Standards Track specification; it i
		s
		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
		to provide for permanent record. It represents the consensus of the
		Internet
		Architecture Board (IAB). Documents approved for publication
		by the IAB are not candidates for any level of Internet Standard; se
		e
		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="non
		e"/>.
		</t>
		</section>
		<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
		ude" pn="section-boilerplate.2">
		<name slugifiedName="name-copyright-notice">Copyright Notice</name>
		<t pn="section-boilerplate.2-1">
		Copyright (c) 2020 IETF Trust 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 IETF 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>
		</section>
		</boilerplate>
		<toc>
		<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
		n="section-toc.1">
		<name slugifiedName="name-table-of-contents">Table of Contents</name>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
		c.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 derivedCon
		tent="" format="title" sectionFormat="of" target="name-introduction">Introductio
		n</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 derivedCon
		tent="" format="title" sectionFormat="of" target="name-rfc-series-mission">RFC S
		eries 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 derivedCon
		tent="" format="title" sectionFormat="of" target="name-roles-and-responsibilitie
		s">Roles and Responsibilities</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-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 derive
		dContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-rfc-editor">R
		FC 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 derive
		dContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-iab">IAB</xre
		f></t>
		</li>
		<li pn="section-toc.1-1.3.2.3">
		<t keepWithNext="true" pn="section-toc.1-1.3.2.3.1"><xref derive
		dContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-operational-o
		versight">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 derive
		dContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-policy-oversi
		ght">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 derivedCon
		tent="" format="title" sectionFormat="of" target="name-framework">Framework</xre
		f></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-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 derive
		dContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-document-appr
		oval">Document Approval</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
		ction-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"><xre
		f derivedContent="4.1.1" format="counter" sectionFormat="of" target="section-4.1
		.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-d
		efinition">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"><xre
		f derivedContent="4.1.2" format="counter" sectionFormat="of" target="section-4.1
		.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-o
		perational-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"><xre
		f derivedContent="4.1.3" format="counter" sectionFormat="of" target="section-4.1
		.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-p
		rocess-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"><xre
		f derivedContent="4.1.4" format="counter" sectionFormat="of" target="section-4.1
		.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-e
		xisting-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 derive
		dContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-editing-proce
		ssing-and-publ">Editing, Processing, and Publication of Documents</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
		ction-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"><xre
		f derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2
		.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-d
		efinition-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"><xre
		f derivedContent="4.2.2" format="counter" sectionFormat="of" target="section-4.2
		.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-o
		perational-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"><xre
		f derivedContent="4.2.3" format="counter" sectionFormat="of" target="section-4.2
		.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-p
		rocess-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"><xre
		f derivedContent="4.2.4" format="counter" sectionFormat="of" target="section-4.2
		.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-e
		xisting-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 derive
		dContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-archiving-ind
		exing-and-acce">Archiving, Indexing, and Accessibility</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
		ction-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"><xre
		f derivedContent="4.3.1" format="counter" sectionFormat="of" target="section-4.3
		.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-d
		efinition-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"><xre
		f derivedContent="4.3.2" format="counter" sectionFormat="of" target="section-4.3
		.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-o
		perational-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"><xre
		f derivedContent="4.3.3" format="counter" sectionFormat="of" target="section-4.3
		.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-p
		rocess-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"><xre
		f derivedContent="4.3.4" format="counter" sectionFormat="of" target="section-4.3
		.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-e
		xisting-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 derive
		dContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-series-wide-g
		uidelines-and-">Series-Wide Guidelines and Rules</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
		ction-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"><xre
		f derivedContent="4.4.1" format="counter" sectionFormat="of" target="section-4.4
		.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-d
		efinition-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"><xre
		f derivedContent="4.4.2" format="counter" sectionFormat="of" target="section-4.4
		.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-o
		perational-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"><xre
		f derivedContent="4.4.3" format="counter" sectionFormat="of" target="section-4.4
		.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-p
		rocess-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"><xre
		f derivedContent="4.4.4" format="counter" sectionFormat="of" target="section-4.4
		.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-e
		xisting-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 derivedCon
		tent="" format="title" sectionFormat="of" target="name-rfc-streams">RFC Streams<
		/xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-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 derive
		dContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>. <xre
		f 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="se
		ction-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"><xre
		f derivedContent="5.1.1" format="counter" sectionFormat="of" target="section-5.1
		.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-i
		etf-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"><xre
		f derivedContent="5.1.2" format="counter" sectionFormat="of" target="section-5.1
		.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-i
		ab-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"><xre
		f derivedContent="5.1.3" format="counter" sectionFormat="of" target="section-5.1
		.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-i
		rtf-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"><xre
		f derivedContent="5.1.4" format="counter" sectionFormat="of" target="section-5.1
		.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-i
		ndependent-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 derive
		dContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>. <xre
		f 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="se
		ction-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"><xre
		f derivedContent="5.2.1" format="counter" sectionFormat="of" target="section-5.2
		.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-i
		etf-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"><xre
		f derivedContent="5.2.2" format="counter" sectionFormat="of" target="section-5.2
		.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-i
		ab-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"><xre
		f derivedContent="5.2.3" format="counter" sectionFormat="of" target="section-5.2
		.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-i
		rtf-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"><xre
		f derivedContent="5.2.4" format="counter" sectionFormat="of" target="section-5.2
		.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-i
		ndependent-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 derivedCon
		tent="" 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 derivedCon
		tent="" format="title" sectionFormat="of" target="name-changes-since-rfc-4844">C
		hanges 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 derivedCon
		tent="" format="title" sectionFormat="of" target="name-informative-references">I
		nformative 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-retro
		spective-of-iab-char">A Retrospective of IAB Charters and RFC Editor</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-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 derive
		dContent="A.1" format="counter" sectionFormat="of" target="section-a.1"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-1992">1992</x
		ref></t>
		</li>
		<li pn="section-toc.1-1.9.2.2">
		<t keepWithNext="true" pn="section-toc.1-1.9.2.2.1"><xref derive
		dContent="A.2" format="counter" sectionFormat="of" target="section-a.2"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-1994">1994</x
		ref></t>
		</li>
		<li pn="section-toc.1-1.9.2.3">
		<t keepWithNext="true" pn="section-toc.1-1.9.2.3.1"><xref derive
		dContent="A.3" format="counter" sectionFormat="of" target="section-a.3"/>. <xre
		f derivedContent="" format="title" sectionFormat="of" target="name-2000">2000</x
		ref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.10">
		<t keepWithNext="true" pn="section-toc.1-1.10.1"><xref derivedConten
		t="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derived
		Content="" format="title" sectionFormat="of" target="name-iab-members-at-the-tim
		e-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 derivedConten
		t="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derived
		Content="" format="title" sectionFormat="of" target="name-authors-addresses">Aut
		hors' Addresses</xref></t>
		</li>
		</ul>
		</section>
		</toc>
		</front>
		<middle>
		<section anchor="intro" 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	The first Request for Comments (RFC) document was published in April
	of 1969 as part of the effort to design and build	of 1969 as part of the effort to design and build
	what we now know of as the Internet. Since then, the RFC Series	what we now know of as the Internet. Since then, the RFC Series
	has been the archival series dedicated to documenting	has been the archival series dedicated to documenting
	Internet technical specifications, including both general	Internet technical specifications, including both general
	contributions from the Internet research and engineering	contributions from the Internet research and engineering
	community as well as standards documents.	community as well as standards documents.
	</t>	</t>

	<t>	<t pn="section-1-2">
	As described in the history of the first 30 years of RFCs	As described in the history of the first 30 years of RFCs

	(<xref target="RFC2555"/>), the RFC Series was created for the purpose	(<xref target="RFC2555" format="default" sectionFormat="of" derivedContent="RFC2 555"/>), the RFC Series was created for the purpose
	of capturing the research and engineering thought that underlie	of capturing the research and engineering thought that underlie
	the design of (what we now know of as) the Internet. As the	the design of (what we now know of as) the Internet. As the
	Internet Engineering Task Force (IETF) was formalized to carry out	Internet Engineering Task Force (IETF) was formalized to carry out
	the discussion and documentation of Internet standards, IETF documents	the discussion and documentation of Internet standards, IETF documents
	have become a large part (but not the entirety) of the RFC Series.	have become a large part (but not the entirety) of the RFC Series.
	</t>	</t>

	<t>	<t pn="section-1-3">
	As the IETF has grown up and celebrated its own 30 years of	As the IETF has grown up and celebrated its own 30 years of
	history, its requirements for archival publication of its output	history, its requirements for archival publication of its output
	have changed and become more rigorous. Perhaps most significantly,	have changed and become more rigorous. Perhaps most significantly,
	the IETF must be able to define (based on its own open consensus	the IETF must be able to define (based on its own open consensus
	discussion processes and leadership directions) and implement	discussion processes and leadership directions) and implement
	adjustments to its publication processes.	adjustments to its publication processes.
	</t>	</t>

	<t>	<t pn="section-1-4">
	At the same time, the Internet engineering and research community	At the same time, the Internet engineering and research community
	as a whole has grown and come to require more openness and accountability	as a whole has grown and come to require more openness and accountability
	in all organizations supporting it. More than ever, this community	in all organizations supporting it. More than ever, this community
	needs an RFC Series that is supported (operationally and in terms of	needs an RFC Series that is supported (operationally and in terms of
	its principles) such that there is a balance of:	its principles) such that there is a balance of:
	</t>	</t>

	<t><list style="symbols">	<ul spacing="normal" bare="false" empty="false" pn="section-1-5">
	<t>	<li pn="section-1-5.1">
	expert implementation;	expert implementation;

	</t>	</li>
	<t>	<li pn="section-1-5.2">
	clear management and direction -- for operations and evolution across	clear management and direction -- for operations and evolution across
	the whole RFC Series (whether originating in the IETF or not); and	the whole RFC Series (whether originating in the IETF or not); and

	</t>	</li>
	<t>	<li pn="section-1-5.3">
	appropriate community input into and review of activities.	appropriate community input into and review of activities.

	</t>	</li>
	</list></t>	</ul>
	<t>	<t pn="section-1-6">
	In the past, there has been confusion and therefore sometimes tension over	In the past, there has been confusion and therefore sometimes tension over
	where and how to address RFC issues that are particular to	where and how to address RFC issues that are particular to
	contributing groups (e.g., the IETF, the Internet Architecture Board	contributing groups (e.g., the IETF, the Internet Architecture Board
	(IAB), or independent individuals). It was not always clear where there should	(IAB), or independent individuals). It was not always clear where there should
	be community involvement versus RFC Editor control; depending on the	be community involvement versus RFC Editor control; depending on the
	issue, there might be more or less involvement from the IAB, the	issue, there might be more or less involvement from the IAB, the
	Internet Engineering Steering Group (IESG), or the	Internet Engineering Steering Group (IESG), or the
	community at large. There are similar issues with handling RFC	community at large. There are similar issues with handling RFC
	Series-wide issues -- where to discuss and resolve them in a way that	Series-wide issues -- where to discuss and resolve them in a way that
	is balanced across the whole series.	is balanced across the whole series.
	</t>	</t>

	<t>	<t pn="section-1-7">
	For example, there have been discussions about Intellectual Property	For example, there have been discussions about Intellectual Property
	Rights (IPR) for IETF-generated documents, but it's not clear when or	Rights (IPR) for IETF-generated documents, but it's not clear when or
	how to abstract the portions of those discussions that are relevant	how to abstract the portions of those discussions that are relevant
	to the rest of the RFC Series. Discussions of labeling (of	to the rest of the RFC Series. Discussions of labeling (of
	RFCs in general, IETF documents in particular, or some combination	RFCs in general, IETF documents in particular, or some combination

	thereof) generally must be applied to the whole RFC Series-wide or	thereof) generally must be applied to the whole RFC Series or
	not at all. Without an agreed-on framework for managing the RFC Series, it is	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 --	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	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.	RFC Series imposing undue restrictions on documents from the IETF.
	</t>	</t>

	<t>	<t pn="section-1-8">
	As part of its charter (see <xref target="iabcharterhistory"/>), the IAB has	As part of its charter (see <xref target="iabcharterhistory" format="default" se
		ctionFormat="of" derivedContent="Appendix A"/>), the IAB has
	a responsibility for the RFC Editor. Acknowledging the IETF's needs	a responsibility for the RFC Editor. Acknowledging the IETF's needs
	and the general Internet engineering and research community's evolving	and the general Internet engineering and research community's evolving
	needs, the IAB supports a future for the RFC Series that	needs, the IAB supports a future for the RFC Series that
	continues to meet its original mandate of providing the archival	continues to meet its original mandate of providing the archival
	series for the technical research and engineering documentation that	series for the technical research and engineering documentation that
	describes the Internet.	describes the Internet.
	</t>	</t>

	<t>	<t pn="section-1-9">
	With this document, the IAB provides the framework for the RFC Series and	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	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	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	stated purpose of the RFC Series and the realities of today's Internet
	research and engineering community. The framework describes the existing	research and engineering community. The framework describes the existing
	"streams" of RFCs, draws a roadmap of existing process documents already	"streams" of RFCs, draws a roadmap of existing process documents already
	defining the implementation, and provides clear direction of how to	defining the implementation, and provides clear direction of how to
	evolve this framework and its supporting pieces through discussion and	evolve this framework and its supporting pieces through discussion and
	future document revision.	future document revision.
	</t>	</t>

	<t>	<t pn="section-1-10">
	Specifically, this document provides a brief charter for the RFC Series,	Specifically, this document provides a brief charter for the RFC Series,
	describes the role of the RFC Editor, the IAB, and the IETF	describes the role of the RFC Editor, the IAB, and the IETF
	Administrative Support Activity (IASA) in a framework for managing the	Administrative Support Activity (IASA) in a framework for managing the
	RFC Series, and discusses the streams of input to the RFC Series from the	RFC Series, and discusses the streams of input to the RFC Series from the
	various constituencies it serves.	various constituencies it serves.
	</t>	</t>

	</section>	</section>
		<section anchor="charter" numbered="true" toc="include" removeInRFC="false"
	<section anchor="charter" title="RFC Series Mission">	pn="section-2">
	<t>	<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	The RFC Series is the archival series dedicated to documenting Internet
	technical specifications, including general	technical specifications, including general
	contributions from the Internet research and engineering	contributions from the Internet research and engineering
	community as well as standards documents.	community as well as standards documents.
	</t>	</t>

	<t>	<t pn="section-2-2">
	RFCs are available free of charge to anyone via the Internet.	RFCs are available free of charge to anyone via the Internet.
	</t>	</t>

	</section>	</section>
		<section anchor="roles" numbered="true" toc="include" removeInRFC="false" pn
	<section anchor="roles" title="Roles and Responsibilities">	="section-3">
	<t>	<name slugifiedName="name-roles-and-responsibilities">Roles and Responsibi
		lities</name>
		<t pn="section-3-1">
	As this document sets out the framework for supporting the	As this document sets out the framework for supporting the
	RFC Series mission, this section reviews the updated roles and	RFC Series mission, this section reviews the updated roles and
	responsibilities of the entities that have had, and will have,	responsibilities of the entities that have had, and will have,
	involvement in continued support of the mission.	involvement in continued support of the mission.
	</t>	</t>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-3.1
	<section title="RFC Editor">	">
	<t>	<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	Originally, there was a single person acting as editor of the RFC
	Series (the RFC Editor). The task has grown, and the work now	Series (the RFC Editor). The task has grown, and the work now
	requires the organized activity of several experts, so there are	requires the organized activity of several experts, so there are
	RFC Editors, or an RFC Editor organization. In time, there may be	RFC Editors, or an RFC Editor organization. In time, there may be
	multiple organizations working together to undertake the work required	multiple organizations working together to undertake the work required
	by the RFC Series. For simplicity's sake, and without attempting	by the RFC Series. For simplicity's sake, and without attempting
	to predict how the role might be subdivided among them, this document	to predict how the role might be subdivided among them, this document
	refers to this collection of experts and organizations as the "RFC Editor".	refers to this collection of experts and organizations as the "RFC Editor".
	</t>	</t>

	<t>	<t pn="section-3.1-2">
	The RFC Editor is an expert technical editor and series editor, acting to	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	support the mission of the RFC Series. As such, the RFC Editor
	is the implementer handling the editorial management of the RFC	is the implementer handling the editorial management of the RFC
	Series, in accordance with the defined processes. In addition, the	Series, in accordance with the defined processes. In addition, the
	RFC Editor is expected to be the expert and prime mover in discussions	RFC Editor is expected to be the expert and prime mover in discussions
	about policies for editing, publishing, and archiving RFCs.	about policies for editing, publishing, and archiving RFCs.
	</t>	</t>

	</section>	</section>
		<section anchor="iab" numbered="true" toc="include" removeInRFC="false" pn
	<section anchor="iab" title="IAB">	="section-3.2">
	<t>	<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	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	mission is being appropriately fulfilled for the whole community for
	which it was created. The IAB does not, organizationally, have	which it was created. The IAB does not, organizationally, have
	comprehensive publishing or editorial expertise. Therefore, the role of	comprehensive publishing or editorial expertise. Therefore, the role of
	the IAB is focused on ensuring that principles are met, the appropriate	the IAB is focused on ensuring that principles are met, the appropriate
	bodies and communities are duly informed and consulted, and the RFC	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	Editor has what it needs in order to execute on the material that is in
	their mandate.	their mandate.
	</t>	</t>

	<t>	<t pn="section-3.2-2">
	It is the responsibility of the IAB to approve the	It is the responsibility of the IAB to approve the
	appointment of the RFC Editor and to approve the general	appointment of the RFC Editor and to approve the general
	policy followed by the RFC Editor.	policy followed by the RFC Editor.
	</t>	</t>

	</section>	</section>
		<section anchor="ops" numbered="true" toc="include" removeInRFC="false" pn
	<section anchor="ops" title="Operational Oversight">	="section-3.3">
	<t>	<name slugifiedName="name-operational-oversight">Operational Oversight</
		name>
		<t pn="section-3.3-1">
	The IETF Administration Limited Liability Company (IETF LLC), as part	The IETF Administration Limited Liability Company (IETF LLC), as part
	of the IETF Administrative Support Activity (IASA), is responsible	of the IETF Administrative Support Activity (IASA), is responsible
	for administrative and financial matters for the IETF, the IAB, and	for administrative and financial matters for the IETF, the IAB, and
	the Internet Research Task Force (IRTF)	the Internet Research Task Force (IRTF)

	<xref target="I-D.ietf-iasa2-rfc4071bis"/>. The IASA is tasked with	<xref target="RFC8711" format="default" sectionFormat="of" derivedContent="RFC87 11"/>. The IASA is tasked with
	providing the funding for the RFC Editor. The IASA, through the	providing the funding for the RFC Editor. The IASA, through the
	IETF Executive Director, provides contractual and financial oversight	IETF Executive Director, provides contractual and financial oversight

	of the RFC Editor. Additionally, as described in Section 3.1 of	of the RFC Editor. Additionally, as described in
	<xref target="I-D.ietf-iasa2-rfc6635bis"/>, RFC Series Oversight	<xref target="RFC8728" section="3.1" sectionFormat="of" format="default" derived
		Link="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	Committee (RSOC), acting with authority delegated from the IAB, is
	responsible for ensuring that the RFC Series is run in a transparent	responsible for ensuring that the RFC Series is run in a transparent
	and accountable manner, including design and execution of the	and accountable manner, including design and execution of the
	RFC Series Editor selection process.	RFC Series Editor selection process.
	</t>	</t>

	<t>	<t pn="section-3.3-2">
	The IETF Executive Director works with the IAB to identify suitable	The IETF Executive Director works with the IAB to identify suitable
	persons or entities to fulfill the mandate of the RFC Production	persons or entities to fulfill the mandate of the RFC Production
	Center and the RFC Publisher roles as defined in	Center and the RFC Publisher roles as defined in

	<xref target="I-D.ietf-iasa2-rfc6635bis"/>.	<xref target="RFC8728" format="default" sectionFormat="of" derivedContent="RFC87 28"/>.
	</t>	</t>

	<t>	<t pn="section-3.3-3">
	The IETF Executive Director establishes appropriate	The IETF Executive Director establishes appropriate
	contractual agreements with the selected persons or entities	contractual agreements with the selected persons or entities
	to carry out the work that will satisfy the technical publication requirements	to carry out the work that will satisfy the technical publication requirements

	defined for the various RFC input streams (see <xref target="reqs"/>).	defined for the various RFC input streams (see <xref target="reqs" format="defau lt" sectionFormat="of" derivedContent="Section 5.2"/>).
	The IETF Executive Director may define additional operational requirements	The IETF Executive Director may define additional operational requirements
	and policies for management purposes to meet the requirements defined	and policies for management purposes to meet the requirements defined
	by the various communities.	by the various communities.
	</t>	</t>

	<t>	<t pn="section-3.3-4">
	The IETF Administration LLC Board approves a budget for operation of	The IETF Administration LLC Board approves a budget for operation of
	the RFC Editor activity, and the IETF Executive Director establishes and	the RFC Editor activity, and the IETF Executive Director establishes and
	manages the necessary operational agreements for the RFC Editor activity.	manages the necessary operational agreements for the RFC Editor activity.
	</t>	</t>

	</section>	</section>
		<section anchor="policyoversight" numbered="true" toc="include" removeInRF
	<section title="Policy Oversight">	C="false" pn="section-3.4">
	<t>	<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	The IAB monitors the effectiveness of the policies in force and
	their implementation to ensure that the RFC Editor activity	their implementation to ensure that the RFC Editor activity
	meets the editorial management and document publication needs	meets the editorial management and document publication needs
	as referenced in this document. In the event of serious non-conformance,	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	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	Administration LLC Board, may require the IETF Executive Director to vary
	or terminate and renegotiate the arrangements for the RFC Editor activity.	or terminate and renegotiate the arrangements for the RFC Editor activity.
	</t>	</t>

	</section>	</section>
	</section>	</section>
		<section anchor="framework" numbered="true" toc="include" removeInRFC="false
	<section anchor="framework" title="Framework">	" pn="section-4">
	<t>	<name slugifiedName="name-framework">Framework</name>
		<t pn="section-4-1">
	With the RFC Series mission outlined above, this document describes a	With the RFC Series mission outlined above, this document describes a
	framework for supporting	framework for supporting
	</t>	</t>

	<t><list style="symbols">	<ul spacing="normal" bare="false" empty="false" pn="section-4-2">
	<t>	<li pn="section-4-2.1">
	the operational implementation of the RFC Series,	the operational implementation of the RFC Series,

	</t>	</li>
	</list></t>	</ul>
	<t>	<t pn="section-4-3">
	based on	based on
	</t>	</t>

	<t><list style="symbols">	<ul spacing="normal" bare="false" empty="false" pn="section-4-4">
	<t>	<li pn="section-4-4.1">
	public process and definition documents,	public process and definition documents,

	</t>	</li>
	</list></t>	</ul>
	<t>	<t pn="section-4-5">
	for which there are	for which there are
	</t>	</t>

	<t><list style="symbols">	<ul spacing="normal" bare="false" empty="false" pn="section-4-6">
	<t>	<li pn="section-4-6.1">
	clear responsibilities and mechanisms for update and change.	clear responsibilities and mechanisms for update and change.

	</t>	</li>
	</list></t>	</ul>
	<t>	<t pn="section-4-7">
	Generally speaking, the RFC Editor is responsible for the	Generally speaking, the RFC Editor is responsible for the
	operational implementation of the RFC Series. As outlined	operational implementation of the RFC Series. As outlined

	in <xref target="ops"/>, the IETF Executive Director provides	in <xref target="ops" format="default" sectionFormat="of" derivedContent="Sectio n 3.3"/>, the IETF Executive Director provides
	the oversight of this operational role.	the oversight of this operational role.
	</t>	</t>

	<t>	<t pn="section-4-8">
	The process and definition documents are detailed below, including	The process and definition documents are detailed below, including
	responsibility for the individual process documents (maintenance and	responsibility for the individual process documents (maintenance and
	update). The RFC Editor works with the appropriate community to ensure	update). The RFC Editor works with the appropriate community to ensure
	that the process documents reflect current requirements. The IAB is	that the process documents reflect current requirements. The IAB is
	charged with the role of verifying that appropriate community input has	charged with the role of verifying that appropriate community input has
	been sought and that any changes appropriately account for community	been sought and that any changes appropriately account for community
	requirements.	requirements.
	</t>	</t>

	<t>	<t pn="section-4-9">
	There are three categories of activity, and a fourth category of series-wide	There are three categories of activity, and a fourth category of series-wide
	rules and guidelines, described for implementing the RFC Series to support	rules and guidelines, described for implementing the RFC Series to support
	its mission:	its mission:
	</t>	</t>

	<t><list style="symbols">	<ul spacing="normal" bare="false" empty="false" pn="section-4-10">
	<t>	<li pn="section-4-10.1">
	Approval of documents.	Approval of documents.

	</t>	</li>
	<t>	<li pn="section-4-10.2">
	Editing, processing, and publication of documents.	Editing, processing, and publication of documents.

	</t>	</li>
	<t>	<li pn="section-4-10.3">
	Archiving and indexing the documents and making them accessible.	Archiving and indexing the documents and making them accessible.

	</t>	</li>
	<t>	<li pn="section-4-10.4">
	Series rules and guidelines.	Series rules and guidelines.

	</t>	</li>
	</list></t>	</ul>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-4.1
	<section title="Document Approval">	">
	<t>	<name slugifiedName="name-document-approval">Document Approval</name>
		<t pn="section-4.1-1">
	The RFC Series mission implicitly requires that documents be	The RFC Series mission implicitly requires that documents be
	reviewed and approved for acceptance into the series.	reviewed and approved for acceptance into the series.
	</t>	</t>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-4
	<section title="Definition">	.1.1">
	<t>	<name slugifiedName="name-definition">Definition</name>
	<xref target="approval"/> describes the different streams of documents	<t pn="section-4.1.1-1">
		<xref target="approval" format="default" sectionFormat="of" derivedContent="Sect
		ion 5.1"/> describes the different streams of documents
	that are put to the RFC Editor for publication as RFCs today. While	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	there may be general policies for approval of documents as RFCs (to
	ensure the coherence of the RFC Series), there are also policies defined	ensure the coherence of the RFC Series), there are also policies defined
	for the approval of documents in each stream. Generally speaking, there	for the approval of documents in each stream. Generally speaking, there
	is a different approving body for each stream. The current definitions	is a different approving body for each stream. The current definitions

	are catalogued in <xref target="approval"/>.	are catalogued in <xref target="approval" format="default" sectionFormat="of" de rivedContent="Section 5.1"/>.
	</t>	</t>

	</section>	</section>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-4
	<section title="Operational Implementation">	.1.2">
	<t>	<name slugifiedName="name-operational-implementation">Operational Impl
		ementation</name>
		<t pn="section-4.1.2-1">
	Each stream has its own documented approval process. The RFC Editor is	Each stream has its own documented approval process. The RFC Editor is
	responsible for the approval of documents in one of the streams	responsible for the approval of documents in one of the streams

	(Independent Submission stream, see <xref target="independent-approval"/>)	(Independent Submission stream, see <xref target="independent-approval" format=" default" sectionFormat="of" derivedContent="Section 5.1.4"/>)
	and works with the other approving bodies to ensure smooth passage of	and works with the other approving bodies to ensure smooth passage of
	approved documents into the next phases, ultimately to publication and	approved documents into the next phases, ultimately to publication and
	archiving as an RFC.	archiving as an RFC.
	</t>	</t>

	</section>	</section>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-4
	<section title="Process Change">	.1.3">
	<t>	<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	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	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	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	documents, or the community determines that there are issues to be
	resolved in general for RFC approval or for per-stream approval processes.	resolved in general for RFC approval or for per-stream approval processes.
	</t>	</t>

	<t>	<t pn="section-4.1.3-2">
	In this framework, the general approach is that the IAB will work with	In this framework, the general approach is that the IAB will work with

	the RFC Editor and other parties to get community input and it will verify	the RFC Editor and other parties to get community input, and it will verify
	that any changes appropriately account for community requirements.	that any changes appropriately account for community requirements.
	</t>	</t>

	</section>	</section>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-4
	<section title="Existing Approval Process Documents">	.1.4">
	<t>	<name slugifiedName="name-existing-approval-process-d">Existing Approv
		al Process Documents</name>
		<t pn="section-4.1.4-1">
	The existing documents describing the approval processes for each	The existing documents describing the approval processes for each

	stream are detailed in <xref target="approval"/>.	stream are detailed in <xref target="approval" format="default" sectionFormat="o f" derivedContent="Section 5.1"/>.
	</t>	</t>

	</section>	</section>
	</section>	</section>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-4.2
	<section title="Editing, Processing, and Publication of Documents">	">
	<t>	<name slugifiedName="name-editing-processing-and-publ">Editing, Processi
		ng, and Publication of Documents</name>
		<t pn="section-4.2-1">
	Producing and maintaining a coherent, well-edited document series	Producing and maintaining a coherent, well-edited document series
	requires specialized skills and subject matter expertise. This is	requires specialized skills and subject matter expertise. This is
	the domain of the RFC Editor. Nevertheless, the community served	the domain of the RFC Editor. Nevertheless, the community served
	by the RFC Series and the communities served by the individual	by the RFC Series and the communities served by the individual
	streams of RFCs have requirements that help define the nature of the	streams of RFCs have requirements that help define the nature of the
	series.	series.
	</t>	</t>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-4
	<section title="Definition">	.2.1">
	<t>	<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	General and stream-specific requirements for the RFC Series are documented

	in community-approved documents (catalogued in <xref target="reqs"/>	in community-approved documents (catalogued in <xref target="reqs" format="defau lt" sectionFormat="of" derivedContent="Section 5.2"/>
	below).	below).
	</t>	</t>

	<t>	<t pn="section-4.2.1-2">
	Any specific interfaces, numbers, or concrete values required to make the	Any specific interfaces, numbers, or concrete values required to make the
	requirements operational are the subject of agreements between	requirements operational are the subject of agreements between
	the IASA and the RFC Editor (e.g., contracts, statements of work, service	the IASA and the RFC Editor (e.g., contracts, statements of work, service
	level agreements, etc).	level agreements, etc).
	</t>	</t>

	</section>	</section>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-4
	<section title="Operational Implementation">	.2.2">
	<t>	<name slugifiedName="name-operational-implementation-2">Operational Im
		plementation</name>
		<t pn="section-4.2.2-1">
	The RFC Editor is responsible for ensuring that editing, processing, and	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	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	requirements laid out in the appropriate documents. The RFC Editor works
	with the IASA to provide regular reporting and feedback on these operations.	with the IASA to provide regular reporting and feedback on these operations.
	</t>	</t>

	</section>	</section>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-4
	<section title="Process Change">	.2.3">
	<t>	<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	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	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	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	documents, or the community determines that there are issues to be
	resolved in general for RFCs or for per-stream requirements.	resolved in general for RFCs or for per-stream requirements.
	</t>	</t>

	<t>	<t pn="section-4.2.3-2">
	In this model, the general approach is that the IAB will work with the	In this model, the general approach is that the IAB will work with the

	RFC Editor to get community input and it will approve changes by	RFC Editor to get community input, and it will approve changes by
	validating appropriate consideration of community requirements.	validating appropriate consideration of community requirements.
	</t>	</t>

	</section>	</section>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-4
	<section title="Existing Process Documents">	.2.4">
	<t>	<name slugifiedName="name-existing-process-documents">Existing Process
		Documents</name>
		<t pn="section-4.2.4-1">
	Documents describing existing requirements for the streams are	Documents describing existing requirements for the streams are

	detailed in <xref target="reqs"/>.	detailed in <xref target="reqs" format="default" sectionFormat="of" derivedConte nt="Section 5.2"/>.
	</t>	</t>

	</section>	</section>
	</section>	</section>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-4.3
	<section title="Archiving, Indexing, and Accessibility">	">
	<t>	<name slugifiedName="name-archiving-indexing-and-acce">Archiving, Indexi
		ng, and Accessibility</name>
		<t pn="section-4.3-1">
	The activities of archiving, indexing, and making accessible the RFC	The activities of archiving, indexing, and making accessible the RFC
	Series can be informed by specific subject matter expertise in general	Series can be informed by specific subject matter expertise in general
	document series editing. It is also important that they are informed by	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	requirements from the whole community. As long as the RFC Series is to
	remain coherent, there should be uniform archiving and indexing of RFCs	remain coherent, there should be uniform archiving and indexing of RFCs
	across all streams and a common method of accessing the resulting	across all streams and a common method of accessing the resulting
	documents.	documents.
	</t>	</t>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-4
	<section title="Definition">	.3.1">
	<t>	<name slugifiedName="name-definition-3">Definition</name>
		<t pn="section-4.3.1-1">
	In principle, there should be a community consensus document describing	In principle, there should be a community consensus document describing
	the archiving, indexing, and accessibility requirements for the RFC	the archiving, indexing, and accessibility requirements for the RFC
	Series. In practice, we continue with the archive as built by the	Series. In practice, we continue with the archive as built by the
	capable RFC Editors since the series' inception.	capable RFC Editors since the series' inception.
	</t>	</t>

	<t>	<t pn="section-4.3.1-2">
	Any specific concrete requirements for the archive, index, and	Any specific concrete requirements for the archive, index, and
	accessibility operations are the subject of agreements between the IASA	accessibility operations are the subject of agreements between the IASA
	and the RFC Editor (e.g., contracts, statements of work, service level	and the RFC Editor (e.g., contracts, statements of work, service level
	agreements, etc).	agreements, etc).
	</t>	</t>

		</section>
	</section>	<section numbered="true" toc="include" removeInRFC="false" pn="section-4
	<section title="Operational Implementation">	.3.2">
	<t>	<name slugifiedName="name-operational-implementation-3">Operational Im
		plementation</name>
		<t pn="section-4.3.2-1">
	The RFC Editor is responsible for ensuring that the RFC archive and index	The RFC Editor is responsible for ensuring that the RFC archive and index
	are maintained appropriately and that the resulting documents are made	are maintained appropriately and that the resulting documents are made
	available to anybody wishing to access them via the Internet. The RFC	available to anybody wishing to access them via the Internet. The RFC
	Editor works with the IASA for regular reporting and feedback.	Editor works with the IASA for regular reporting and feedback.
	</t>	</t>

	</section>	</section>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-4
	<section title="Process Change">	.3.3">
	<t>	<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	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	for the RFC archive and index or accessibility, the IAB will work with

	the RFC Editor to get community input and it will approve changes	the RFC Editor to get community input, and it will approve changes
	by validating appropriate consideration of community requirements.	by validating appropriate consideration of community requirements.
	</t>	</t>

	</section>	</section>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-4
	<section title="Existing Process Documents">	.3.4">
	<t>	<name slugifiedName="name-existing-process-documents-2">Existing Proce
		ss Documents</name>
		<t pn="section-4.3.4-1">
	There are no applicable process documents.	There are no applicable process documents.
	</t>	</t>

	</section>	</section>
	</section>	</section>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-4.4
	<section title="Series-Wide Guidelines and Rules">	">
	<t>	<name slugifiedName="name-series-wide-guidelines-and-">Series-Wide Guide
		lines and Rules</name>
		<t pn="section-4.4-1">
	The RFC Series style and content can be shaped by subject matter	The RFC Series style and content can be shaped by subject matter
	expertise in document series editing. They are also informed by	expertise in document series editing. They are also informed by
	requirements by the using community. As long as the RFC Series is to	requirements by the using community. As long as the RFC Series is to
	remain coherent, there should be uniform style and content for RFCs	remain coherent, there should be uniform style and content for RFCs
	across all streams. This includes, but is not limited to, acceptable	across all streams. This includes, but is not limited to, acceptable
	language, use of references, and copyright rules.	language, use of references, and copyright rules.
	</t>	</t>

		<section numbered="true" toc="include" removeInRFC="false" pn="section-4
	<section title="Definition">	.4.1">
	<t>	<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	In principle, there should be a community consensus document (or set of
	documents) describing the content requirements for the RFC Series. In	documents) describing the content requirements for the RFC Series. In
	practice, some do exist, though some need reviewing and more may be	practice, some do exist, though some need reviewing and more may be
	needed over time.	needed over time.
	</t>	</t>

	</section>	</section>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-4
	<section title="Operational Implementation">	.4.2">
	<t>	<name slugifiedName="name-operational-implementation-4">Operational Im
		plementation</name>
		<t pn="section-4.4.2-1">
	The RFC Editor is responsible for ensuring that the RFC Series guidelines	The RFC Editor is responsible for ensuring that the RFC Series guidelines
	are upheld within the RFC Series.	are upheld within the RFC Series.
	</t>	</t>

	</section>	</section>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-4
	<section title="Process Change">	.4.3">
	<t>	<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,	When additions or changes are needed to series-wide definitions,
	the IAB will work with the RFC Editor and stream stakeholders	the IAB will work with the RFC Editor and stream stakeholders
	to get community input and review. The IAB will approve changes by	to get community input and review. The IAB will approve changes by
	validating appropriate consideration of community requirements.	validating appropriate consideration of community requirements.
	</t>	</t>

	</section>	</section>
		<section numbered="true" toc="include" removeInRFC="false" pn="section-4
	<section title="Existing Process Documents">	.4.4">
	<t>	<name slugifiedName="name-existing-process-documents-3">Existing Proce
		ss Documents</name>
		<t pn="section-4.4.4-1">
	Existing series-wide rules and guidelines documents include:	Existing series-wide rules and guidelines documents include:
	</t>	</t>

	<t><list style="symbols">	<ul spacing="normal" bare="false" empty="false" pn="section-4.4.4-2">
	<t>	<li pn="section-4.4.4-2.1">
	RFC Style Guide	RFC Style Guide

	<xref target="RFC7223"/>,	<xref target="RFC7322" format="default" sectionFormat="of" derivedContent="R
	</t>	FC7322"/>,
	<t>	</li>
		<li pn="section-4.4.4-2.2">
	The Use of Non-ASCII Characters in RFCs	The Use of Non-ASCII Characters in RFCs

	<xref target="RFC7997"/>,	<xref target="RFC7997" format="default" sectionFormat="of" derivedContent="R
	</t>	FC7997"/>,
	<t>	</li>
		<li pn="section-4.4.4-2.3">
	Copyright and intellectual property rules	Copyright and intellectual property rules

	<xref target="RFC5378"/>,	<xref target="RFC5378" format="default" sectionFormat="of" derivedContent="R
	</t>	FC5378"/>,
	<t>	</li>
		<li pn="section-4.4.4-2.4">
	Normative references	Normative references

	<xref target="RFC3967"/>	<xref target="RFC3967" format="default" sectionFormat="of" derivedContent="R
	<xref target="RFC4897"/>.	FC3967"/>
	</t>	<xref target="RFC4897" format="default" sectionFormat="of" derived
	</list></t>	Content="RFC4897"/>,
	</section>	<xref target="RFC8067" format="default" sectionFormat="of" derivedContent="R
	</section>	FC8067"/>.
	</section>	</li>
		</ul>
	<section anchor="streams" title="RFC Streams">	</section>
	<t>	</section>
		</section>
		<section anchor="streams" 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	Various contributors provide input to the RFC Series. These
	contributors come from several different communities, each	contributors come from several different communities, each
	with its own defined process for approving documents that	with its own defined process for approving documents that
	will be published by the RFC Editor. This is nothing new;	will be published by the RFC Editor. This is nothing new;
	however, over time the various communities and document	however, over time the various communities and document
	requirements have grown and separated. In order to promote	requirements have grown and separated. In order to promote
	harmony in discussing the collective set of requirements,	harmony in discussing the collective set of requirements,
	it is useful to recognize each in their own space -- and they	it is useful to recognize each in their own space -- and they
	are referred to here as "streams".	are referred to here as "streams".
	</t>	</t>

	<t>	<t pn="section-5-2">
	Note that by identifying separate streams, there is no intention	Note that by identifying separate streams, there is no intention
	of dividing them or undermining their management as one series. Rather,	of dividing them or undermining their management as one series. Rather,
	the opposite is true -- by clarifying the constituent parts,	the opposite is true -- by clarifying the constituent parts,
	it is easier to make them work together without the friction that	it is easier to make them work together without the friction that
	sometimes arises when discussing various requirements.	sometimes arises when discussing various requirements.
	</t>	</t>

	<t>	<t pn="section-5-3">
	The subsections below identify the streams that exist today.	The subsections below identify the streams that exist today.
	There is no immediate expectation of new streams being created,	There is no immediate expectation of new streams being created,
	and it is preferable that new streams NOT be created. Creation of	and it is preferable that new streams NOT be created. Creation of
	streams and all policies surrounding general changes to the	streams and all policies surrounding general changes to the

	RFC Series are discussed above in <xref target="framework"/>.	RFC Series are discussed above in <xref target="framework" format="default" sect ionFormat="of" derivedContent="Section 4"/>.
	</t>	</t>

		<section anchor="approval" numbered="true" toc="include" removeInRFC="fals
	<section anchor="approval" title="RFC Approval Processes">	e" pn="section-5.1">
	<t>	<name slugifiedName="name-rfc-approval-processes">RFC Approval Processes
		</name>
		<t pn="section-5.1-1">
	Processes for approval of documents (or requirements) for each stream are	Processes for approval of documents (or requirements) for each stream are
	defined by the community that defines the stream. The IAB is charged	defined by the community that defines the stream. The IAB is charged
	with the role of verifying that appropriate community input has been	with the role of verifying that appropriate community input has been
	sought and that the changes are consistent with the RFC Series mission	sought and that the changes are consistent with the RFC Series mission
	and this overall framework.	and this overall framework.
	</t>	</t>

	<t>	<t pn="section-5.1-2">
	The RFC Editor is expected to publish all documents passed to it	The RFC Editor is expected to publish all documents passed to it
	after appropriate review and approval in one of the identified	after appropriate review and approval in one of the identified
	streams.	streams.
	</t>	</t>

		<section anchor="ietf-approval" numbered="true" toc="include" removeInRF
	<section anchor="ietf-approval" title="IETF Document Stream">	C="false" pn="section-5.1.1">
	<t>	<name slugifiedName="name-ietf-document-stream">IETF Document Stream</
		name>
		<t pn="section-5.1.1-1">
	The IETF document stream includes IETF WG documents as well as	The IETF document stream includes IETF WG documents as well as
	"individual submissions" sponsored by an IESG area director. Any	"individual submissions" sponsored by an IESG area director. Any
	document being published as part of the IETF standards process	document being published as part of the IETF standards process
	must follow this stream -- no other stream can approve	must follow this stream -- no other stream can approve
	Standards-Track RFCs or Best Current Practice (BCP) RFCs.	Standards-Track RFCs or Best Current Practice (BCP) RFCs.
	</t>	</t>

	<t>	<t pn="section-5.1.1-2">
	Approval of documents in the IETF stream is defined by	Approval of documents in the IETF stream is defined by
	</t>	</t>

	<t><list style="symbols">	<ul spacing="normal" bare="false" empty="false" pn="section-5.1.1-3">
	<t>	<li pn="section-5.1.1-3.1">
	the IETF standards process	the IETF standards process

	<xref target="RFC2026"/> (and its successors).	<xref target="RFC2026" format="default" sectionFormat="of" derivedContent="R
	</t>	FC2026"/> (and its successors).
	<t>	</li>
		<li pn="section-5.1.1-3.2">
	the IESG process for sponsoring individual submissions	the IESG process for sponsoring individual submissions

	<xref target="SPONSOR"/>.	<xref target="SPONSOR" format="default" sectionFormat="of" derivedContent="S
	</t>	PONSOR"/>.
	</list></t>	</li>
	<t>	</ul>
		<t pn="section-5.1.1-4">
	Changes to the approval process for this stream are made by	Changes to the approval process for this stream are made by
	updating the IETF standards process documents.	updating the IETF standards process documents.
	</t>	</t>

	</section>	</section>
		<section anchor="iab-approval" numbered="true" toc="include" removeInRFC
	<section anchor="iab-approval" title="IAB Document Stream">	="false" pn="section-5.1.2">
	<t>	<name slugifiedName="name-iab-document-stream">IAB Document Stream</na
		me>
		<t pn="section-5.1.2-1">
	The IAB defines the processes by which it approves documents in its	The IAB defines the processes by which it approves documents in its
	stream. Consistent with the above, any documents that the IAB wishes to	stream. Consistent with the above, any documents that the IAB wishes to
	publish as part of the IETF Standards Track (Standards or BCPs) are	publish as part of the IETF Standards Track (Standards or BCPs) are

	subject to the approval processes referred to in <xref	subject to the approval processes referred to in <xref target="ietf-approval" fo
	target="ietf-approval"/>.	rmat="default" sectionFormat="of" derivedContent="Section 5.1.1"/>.
	</t>	</t>

	<t>	<t pn="section-5.1.2-2">
	The review and approval process for documents in the IAB	The review and approval process for documents in the IAB
	stream is described in	stream is described in
	</t>	</t>

	<t><list style="symbols">	<ul spacing="normal" bare="false" empty="false" pn="section-5.1.2-3">
	<t>	<li pn="section-5.1.2-3.1">
	the IAB process for review and approval of its documents	the IAB process for review and approval of its documents

	<xref target="RFC4845"/>.	<xref target="RFC4845" format="default" sectionFormat="of" derivedContent="R
	</t>	FC4845"/>.
	</list></t>	</li>
	</section>	</ul>
		</section>
	<section anchor="irtf-approval" title="IRTF Document Stream">	<section anchor="irtf-approval" numbered="true" toc="include" removeInRF
	<t>	C="false" pn="section-5.1.3">
		<name slugifiedName="name-irtf-document-stream">IRTF Document Stream</
		name>
		<t pn="section-5.1.3-1">
	The IRTF is chartered as an activity of the IAB. With the approval	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	of the IAB, the IRTF may publish and update a process for
	publication of its own, non-IETF Standards-Track, documents.	publication of its own, non-IETF Standards-Track, documents.
	</t>	</t>

	<t>	<t pn="section-5.1.3-2">
	The review and approval process for documents in the IRTF stream	The review and approval process for documents in the IRTF stream
	is described in	is described in
	</t>	</t>

	<t><list style="symbols">	<ul spacing="normal" bare="false" empty="false" pn="section-5.1.3-3">
	<t>	<li pn="section-5.1.3-3.1">
	IRTF Research Group RFCs	IRTF Research Group RFCs

	<xref target="RFC5743"/>.	<xref target="RFC5743" format="default" sectionFormat="of" derivedContent="R
	</t>	FC5743"/>.
	</list></t>	</li>
	</section>	</ul>
		</section>
	<section anchor="independent-approval" title="Independent Submission Stream">	<section anchor="independent-approval" numbered="true" toc="include" rem
	<t>	oveInRFC="false" pn="section-5.1.4">
		<name slugifiedName="name-independent-submission-stre">Independent Sub
		mission Stream</name>
		<t pn="section-5.1.4-1">
	The RFC Series has always served a broader Internet technical	The RFC Series has always served a broader Internet technical
	community than the IETF. The "Independent Submission" stream is	community than the IETF. The "Independent Submission" stream is
	defined to provide review and (possible) approval of documents	defined to provide review and (possible) approval of documents
	that are outside the scope of the streams identified above.	that are outside the scope of the streams identified above.
	</t>	</t>

	<t>	<t pn="section-5.1.4-2">
	Generally speaking, approval of documents in this stream falls	Generally speaking, approval of documents in this stream falls
	under the purview of the RFC Editor, and the RFC Editor seeks	under the purview of the RFC Editor, and the RFC Editor seeks
	input to its review from the IESG.	input to its review from the IESG.
	</t>	</t>

	<t>	<t pn="section-5.1.4-3">
	The process for reviewing and approving documents in the Independent	The process for reviewing and approving documents in the Independent
	Submission stream is defined by	Submission stream is defined by
	</t>	</t>

	<t><list style="symbols">	<ul spacing="normal" bare="false" empty="false" pn="section-5.1.4-4">
	<t>	<li pn="section-5.1.4-4.1">
	Procedures for Rights Handling in the RFC Independent Submission Stream	Procedures for Rights Handling in the RFC Independent Submission Stream

	<xref target="RFC5744"/>,	<xref target="RFC5744" format="default" sectionFormat="of" derivedContent="R
	</t>	FC5744"/>,
	<t>	</li>
		<li pn="section-5.1.4-4.2">
	Independent Submission Editor Model	Independent Submission Editor Model

	<xref target="I-D.ietf-iasa2-rfc6548bis"/>,	<xref target="RFC8730" format="default" sectionFormat="of" derivedContent="R
	</t>	FC8730"/>,
	<t>	</li>
		<li pn="section-5.1.4-4.3">
	Independent Submissions to the RFC Editor	Independent Submissions to the RFC Editor

	<xref target="RFC4846"/>,	<xref target="RFC4846" format="default" sectionFormat="of" derivedContent="R
	</t>	FC4846"/>,
	<t>	</li>
		<li pn="section-5.1.4-4.4">
	The IESG and RFC Editor Documents: Procedures	The IESG and RFC Editor Documents: Procedures

	<xref target="RFC3932"/>.	<xref target="RFC5742" format="default" sectionFormat="of" derivedContent="R
	</t>	FC5742"/>.
	</list></t>	</li>
	</section>	</ul>
	</section>	</section>
		</section>
	<section anchor="reqs" title="RFC Technical Publication Requirements">	<section anchor="reqs" numbered="true" toc="include" removeInRFC="false" p
	<t>	n="section-5.2">
		<name slugifiedName="name-rfc-technical-publication-r">RFC Technical Pub
		lication Requirements</name>
		<t pn="section-5.2-1">
	The Internet engineering and research community has not only grown,	The Internet engineering and research community has not only grown,
	it has become more diverse, and sometimes more demanding. The IETF,	it has become more diverse, and sometimes more demanding. The IETF,
	as a standards-developing organization, has publication requirements	as a standards-developing organization, has publication requirements
	that extend beyond those of an academic journal. The IAB does not	that extend beyond those of an academic journal. The IAB does not
	have the same interdependence with IANA assignments as the IETF	have the same interdependence with IANA assignments as the IETF
	stream does. Therefore, there is the need to both codify the	stream does. Therefore, there is the need to both codify the
	publishing requirements of each stream, and endeavor to harmonize	publishing requirements of each stream, and endeavor to harmonize
	them to the extent that is reasonable.	them to the extent that is reasonable.
	</t>	</t>

	<t>	<t pn="section-5.2-2">
	Therefore, it is expected that the community of effort behind	Therefore, it is expected that the community of effort behind
	each document stream will outline their technical publication	each document stream will outline their technical publication
	requirements.	requirements.
	</t>	</t>

	<t>	<t pn="section-5.2-3">
	As part of the RFC Editor oversight, the IAB must agree that the	As part of the RFC Editor oversight, the IAB must agree that the
	requirements are consistent with and implementable as part of the	requirements are consistent with and implementable as part of the
	RFC Editor activity.	RFC Editor activity.
	</t>	</t>

		<section anchor="ietf-req" numbered="true" toc="include" removeInRFC="fa
	<section anchor="ietf-req" title="IETF Documents">	lse" pn="section-5.2.1">
	<t>	<name slugifiedName="name-ietf-documents">IETF Documents</name>
	The requirements for this stream are defined in <xref target="RFC4714"/>.	<t pn="section-5.2.1-1">
		The requirements for this stream are defined in <xref target="RFC4714" format="
		default" sectionFormat="of" derivedContent="RFC4714"/>.
	</t>	</t>

	</section>	</section>
		<section anchor="iab-req" numbered="true" toc="include" removeInRFC="fal
	<section anchor="iab-req" title="IAB Documents">	se" pn="section-5.2.2">
	<t>	<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	Although they were developed for the IETF standards process, the IAB has

	identified applicable requirements in <xref target="RFC4714"/> for its	identified applicable requirements in <xref target="RFC4714" format="default" se ctionFormat="of" derivedContent="RFC4714"/> for its
	stream. In addition, procedures related to IPR for the IAB stream are	stream. In addition, procedures related to IPR for the IAB stream are

	captured in <xref target="RFC5745"/>.	captured in <xref target="RFC5745" format="default" sectionFormat="of" derivedCo ntent="RFC5745"/>.
	</t>	</t>

	<t>	<t pn="section-5.2.2-2">
	If the IAB elects to define other requirements, they should deviate	If the IAB elects to define other requirements, they should deviate
	minimally from those (in an effort to keep the collective technical	minimally from those (in an effort to keep the collective technical
	publication requirements reasonably managed by one technical publisher).	publication requirements reasonably managed by one technical publisher).
	</t>	</t>

	</section>	</section>
		<section anchor="irtf-req" numbered="true" toc="include" removeInRFC="fa
	<section anchor="irtf-req" title="IRTF Documents">	lse" pn="section-5.2.3">
	<t>	<name slugifiedName="name-irtf-documents">IRTF Documents</name>
	The IRTF has identified applicable requirements in <xref target="RFC5743"/>	<t pn="section-5.2.3-1">
		The IRTF has identified applicable requirements in <xref target="RFC5743" format
		="default" sectionFormat="of" derivedContent="RFC5743"/>
	for its stream.	for its stream.
	</t>	</t>

	<t>	<t pn="section-5.2.3-2">
	If the IRTF elects to define other requirements, they should deviate	If the IRTF elects to define other requirements, they should deviate
	minimally from those (in an effort to keep the collective technical	minimally from those (in an effort to keep the collective technical
	publication requirements reasonably managed by one technical publisher).	publication requirements reasonably managed by one technical publisher).
	</t>	</t>

	</section>	</section>
		<section anchor="independent-req" numbered="true" toc="include" removeIn
	<section anchor="independent-req" title="Independent Submissions">	RFC="false" pn="section-5.2.4">
	<t>	<name slugifiedName="name-independent-submissions">Independent Submiss
		ions</name>
		<t pn="section-5.2.4-1">
	Procedures and processes for the Independent Stream are described in	Procedures and processes for the Independent Stream are described in

	<xref target="RFC4846"/> and <xref target="I-D.ietf-iasa2-rfc6548bis"/>.	<xref target="RFC4846" format="default" sectionFormat="of" derivedContent="RFC48 46"/> and <xref target="RFC8730" format="default" sectionFormat="of" derivedCont ent="RFC8730"/>.
	</t>	</t>

	<t>	<t pn="section-5.2.4-2">
	Although they were developed for the IETF standards process, the RFC	Although they were developed for the IETF standards process, the RFC

	Editor has identified applicable requirements in <xref target="RFC4714"/>	Editor has identified applicable requirements in <xref target="RFC4714" format="
	for the independent submissions stream. In addition, procedures related	default" sectionFormat="of" derivedContent="RFC4714"/>
		for the Independent Submissions stream. In addition, procedures related
	to IPR for the independent submissions stream are captured in	to IPR for the independent submissions stream are captured in

	<xref target="RFC5744"/>.	<xref target="RFC5744" format="default" sectionFormat="of" derivedContent="RFC57 44"/>.
	</t>	</t>

	<t>	<t pn="section-5.2.4-3">
	If the RFC Editor elects to define other requirements, they should deviate	If the RFC Editor elects to define other requirements, they should deviate
	minimally from those (in an effort to keep the collective technical	minimally from those (in an effort to keep the collective technical
	publication requirements reasonably managed by one technical publisher).	publication requirements reasonably managed by one technical publisher).
	</t>	</t>

	</section>	</section>
	</section>	</section>
	</section>	</section>
		<section anchor="security" numbered="true" toc="include" removeInRFC="false"
	<section anchor="security" title="Security Considerations">	pn="section-6">
	<t>	<name slugifiedName="name-security-considerations">Security Considerations
		</name>
		<t pn="section-6-1">
	The processes for the publication of documents must prevent the	The processes for the publication of documents must prevent the
	introduction of unapproved changes. Since the RFC Editor maintains the	introduction of unapproved changes. Since the RFC Editor maintains the
	index of publications, sufficient security must be in place to prevent	index of publications, sufficient security must be in place to prevent
	these published documents from being changed by external parties. The	these published documents from being changed by external parties. The
	archive of RFC documents, any source documents needed to recreate the RFC	archive of RFC documents, any source documents needed to recreate the RFC
	documents, and any associated original documents (such as lists of	documents, and any associated original documents (such as lists of
	errata, tools, and, for some early items, non-machine readable originals)	errata, tools, and, for some early items, non-machine readable originals)
	need to be secured against failure of the storage medium and other	need to be secured against failure of the storage medium and other
	similar disasters.	similar disasters.
	</t>	</t>

	</section>	</section>
		<section anchor="changes" numbered="true" toc="include" removeInRFC="false"
	<section anchor="changes" title="Changes Since RFC4844">	pn="section-7">
	<t>	<name slugifiedName="name-changes-since-rfc-4844">Changes Since RFC 4844</
	Sections 3.3, 3.4, and 4 have been updated to align with the restructuring of th	name>
	e	<t pn="section-7-1">
		Sections <xref target="ops" format="counter" sectionFormat="of" derivedContent="
		3.3"/>, <xref target="policyoversight" format="counter" sectionFormat="of" deriv
		edContent="3.4"/>,
		and <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 Administrative Support Activity (IASA). Under the new structure, the
	IETF LLC performs the tasks related to IASA that were previously assigned to	IETF LLC performs the tasks related to IASA that were previously assigned to
	the IETF Administrative Director and to the Internet Society.	the IETF Administrative Director and to the Internet Society.
	</t>	</t>

	<t>	<t pn="section-7-2">
	Many references were updated to point to the most recent documents.	Many references were updated to point to the most recent documents.
	</t>	</t>

	<t>	<t pn="section-7-3">
	Minor editorial changes were made to reflect 10 years of using the framework	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	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	a revised framework ...", and it is now more appropriate to say, "... this
	document sets out the framework ...".	document sets out the framework ...".
	</t>	</t>

	</section>	</section>
	<!--	</middle>
	<section title="Acknowledgements">	<back>
	<t>	<references pn="section-8">
	</t>	<name slugifiedName="name-informative-references">Informative References</
	</section>	name>
	</middle>	<reference anchor="RFC1358" target="https://www.rfc-editor.org/info/rfc135
		8" quoteTitle="true" derivedAnchor="RFC1358">
	<back>	<front>
	<references title="Informative References">	<title>Charter of the Internet Architecture Board (IAB)</title>
	&IASA2;	<author initials="L." surname="Chapin" fullname="L. Chapin">
	&INDSUB;	<organization showOnFrontPage="true"/>
	&MODEL;	</author>
	&RFC1358;	<date year="1992" month="August"/>
	&RFC1601;	<abstract>
	&RFC2026;	<t>The Internet Architecture Board (IAB) shall be constituted and sh
	&RFC2555;	all operate as a technical advisory group of the Internet Society. This memo pr
	&RFC2850;	ovides information for the Internet community. It does not specify an Internet
	&RFC3932;	standard.</t>
	&RFC3967;	</abstract>
	&RFC4714;	</front>
	&RFC4845;	<seriesInfo name="RFC" value="1358"/>
	&RFC4846;	<seriesInfo name="DOI" value="10.17487/RFC1358"/>
	&RFC4897;	</reference>
	&RFC5378;	<reference anchor="RFC1601" target="https://www.rfc-editor.org/info/rfc160
	&RFC5743;	1" quoteTitle="true" derivedAnchor="RFC1601">
	&RFC5744;	<front>
	&RFC5745;	<title>Charter of the Internet Architecture Board (IAB)</title>
	&RFC7223;	<author initials="C." surname="Huitema" fullname="C. Huitema">
	&RFC7997;	<organization showOnFrontPage="true"/>
		</author>
	<reference anchor="SPONSOR" target="http://www.ietf.org/iesg/statement/ad-sp	<date year="1994" month="March"/>
	onsoring-docs.html">	<abstract>
	<front>	<t>This memo documents the composition, selection, roles, and organi
	<title>Guidance on Area Director Sponsoring of Documents</title>	zation of the Internet Architecture Board and its subsidiary organizations. This
	<author><organization>IESG</organization></author>	memo provides information for the Internet community. This memo does not speci
	<date month="March" year="2007"/>	fy an Internet standard of any kind.</t>
	</front>	</abstract>
	<seriesInfo name="IESG Statement" value=""/>	</front>
	</reference>	<seriesInfo name="RFC" value="1601"/>
	</references>	<seriesInfo name="DOI" value="10.17487/RFC1601"/>
		</reference>
	<section anchor="iabcharterhistory" title="A Retrospective of IAB Charters and R	<reference anchor="RFC2026" target="https://www.rfc-editor.org/info/rfc202
	FC Editor">	6" quoteTitle="true" derivedAnchor="RFC2026">
	<t>	<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 fo
		r 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 discuss
		ion 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/rfc255
		5" 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 pione
		ers: 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 R
		FC 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/rfc285
		0" quoteTitle="true" derivedAnchor="RFC2850">
		<front>
		<title>Charter of the Internet Architecture Board (IAB)</title>
		<author>
		<organization showOnFrontPage="true">Internet Architecture Board</or
		ganization>
		</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 organi
		zation of the Internet Architecture Board. It replaces RFC 1601. This document
		specifies an Internet Best Current Practices for the Internet Community, and re
		quests 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/rfc396
		7" 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 ma
		turity level or to a non standards track specification (other than specification
		s from other standards bodies). For example, a standards track document may not
		have a normative reference to an informational RFC. Exceptions to this rule ar
		e sometimes needed as the IETF uses informational RFCs to describe non-IETF stan
		dards 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 disc
		ussion 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/rfc471
		4" 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 tech
		nical 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 proce
		ss. 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/rfc484
		5" quoteTitle="true" derivedAnchor="RFC4845">
		<front>
		<title>Process for Publication of IAB RFCs</title>
		<author initials="L." surname="Daigle" fullname="L. Daigle" role="edit
		or">
		<organization showOnFrontPage="true"/>
		</author>
		<author>
		<organization showOnFrontPage="true">Internet Architecture Board</or
		ganization>
		</author>
		<date year="2007" month="July"/>
		<abstract>
		<t>From time to time, the Internet Architecture Board (IAB) publishe
		s 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/rfc484
		6" quoteTitle="true" derivedAnchor="RFC4846">
		<front>
		<title>Independent Submissions to the RFC Editor</title>
		<author initials="J." surname="Klensin" fullname="J. Klensin" role="ed
		itor">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="D." surname="Thaler" fullname="D. Thaler" role="edit
		or">
		<organization showOnFrontPage="true"/>
		</author>
		<date year="2007" month="July"/>
		<abstract>
		<t>There is a long-standing tradition in the Internet community, pre
		dating the Internet Engineering Task Force (IETF) by many years, of use of the R
		FC 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 docu
		ment discusses the Independent Submission model and some reasons why it is impor
		tant. It then describes editorial and processing norms that can be used for Ind
		ependent Submissions as the community goes forward into new relationships betwee
		n the IETF community and its primary technical publisher. This memo provides in
		formation 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/rfc489
		7" quoteTitle="true" derivedAnchor="RFC4897">
		<front>
		<title>Handling Normative References to Standards-Track Documents</tit
		le>
		<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 Commen
		ts (RFC) Editor have a long-standing rule that a document at a given maturity le
		vel cannot be published until all of the documents that it references as normati
		ve are at that maturity level or higher. This rule has sometimes resulted in ve
		ry long publication delays for documents and some claims that it was a major obs
		truction 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) document
		s, namely "note and move on". The procedure in RFC 3967 still applies for downw
		ard 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 fo
		r 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/rfc537
		8" quoteTitle="true" derivedAnchor="RFC5378">
		<front>
		<title>Rights Contributors Provide to the IETF Trust</title>
		<author initials="S." surname="Bradner" fullname="S. Bradner" role="ed
		itor">
		<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 d
		esigned 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 po
		ssible. This memo details the IETF policies on rights in Contributions to the I
		ETF. 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 S
		ection 10 of RFC 2026. This document specifies an Internet Best Current Practi
		ces for the Internet Community, and requests discussion and suggestions for impr
		ovements.</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/rfc574
		2" quoteTitle="true" derivedAnchor="RFC5742">
		<front>
		<title>IESG Procedures for Handling of Independent and IRTF Stream Sub
		missions</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 handl
		ing documents submitted for RFC publication from the Independent Submission and
		IRTF streams. </t>
		<t>This document updates procedures described in RFC 2026 and RFC 37
		10. 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/rfc574
		3" quoteTitle="true" derivedAnchor="RFC5743">
		<front>
		<title>Definition of an Internet Research Task Force (IRTF) Document S
		tream</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 Intern
		et Research Task Force. Most documents undergoing this process will come from I
		RTF Research Groups, and it is expected that they will be published as Informati
		onal 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/rfc574
		4" quoteTitle="true" derivedAnchor="RFC5744">
		<front>
		<title>Procedures for Rights Handling in the RFC Independent Submissio
		n 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 In
		dependent Submission documents grant the community "incoming" rights for copying
		and using the text. It also specifies the "outgoing" rights the community gran
		ts 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 informatio
		n 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/rfc574
		5" 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 IA
		B stream documents grant the community "incoming" rights for copying and using t
		he text. It also specifies the "outgoing" rights the community grants to reader
		s and users of those documents, and it requests that the IETF Trust manage the o
		utgoing rights to effect this result. This memo provides information for the In
		ternet 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/rfc732
		2" 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 conventi
		ons 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 str
		ucture of an RFC. Additional guidance is captured on a website that reflects th
		e experimental nature of that guidance and prepares it for future inclusion in t
		he RFC Style Guide. This document obsoletes RFC 2223, "Instructions to RFC Auth
		ors".</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/rfc799
		7" 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 m
		ore 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 broade
		r range of characters than typically used in the English language. This documen
		t 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/rfc806
		7" quoteTitle="true" derivedAnchor="RFC8067">
		<front>
		<title>Updating When Standards Track Documents May Refer Normatively t
		o 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/rfc871
		1" 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/rfc872
		8" quoteTitle="true" derivedAnchor="RFC8728">
		<front>
		<title>RFC Editor Model (Version 2)</title>
		<author initials="O" surname="Kolkman" fullname="Olaf Kolkman" role="e
		ditor">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="J" surname="Halpern" fullname="Joel Halpern" role="e
		ditor">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="R" surname="Hinden" fullname="Robert Hinden" role="e
		ditor">
		<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/rfc873
		0" 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="e
		ditor">
		<organization showOnFrontPage="true"/>
		</author>
		<date month="February" year="2020"/>
		</front>
		<seriesInfo 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" numbered="true" toc="include" removeInRF
		C="false" pn="section-appendix.a">
		<name slugifiedName="name-a-retrospective-of-iab-char">A Retrospective of
		IAB Charters and RFC Editor</name>
		<t pn="section-appendix.a-1">
	With this document, the IAB's role with respect to the RFC Series	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	and the RFC Editor is being adjusted to work more directly with the
	RFC Editor and provide oversight to ensure the RFC Series mission	RFC Editor and provide oversight to ensure the RFC Series mission
	principles and communities' input are addressed appropriately.	principles and communities' input are addressed appropriately.
	</t>	</t>

	<t>	<t pn="section-appendix.a-2">
	This section provides an overview of the role of the IAB with respect	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	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	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	historically been substantive -- whether it is supposed to be directly
	responsible for the RFC Series' editorial management	responsible for the RFC Series' editorial management

	(circa 1992, <xref target="circa1992"/>), or appointment of	(circa 1992, <xref target="circa1992" format="default" sectionFormat="of" derive dContent="Appendix A.1"/>), or appointment of
	the RFC Editor organization and approval of general policy	the RFC Editor organization and approval of general policy

	(circa 2000, <xref target="circa2000"/>).	(circa 2000, <xref target="circa2000" format="default" sectionFormat="of" derive
	</t>	dContent="Appendix A.3"/>).

	<section anchor="circa1992" title="1992">
	<t>
	<xref target="RFC1358"/> says:
	</t>	</t>

	<figure><artwork>	<section anchor="circa1992" numbered="true" toc="include" removeInRFC="fal
		se" pn="section-a.1">
		<name slugifiedName="name-1992">1992</name>
		<t pn="section-a.1-1">
		<xref target="RFC1358" format="default" sectionFormat="of" derivedContent="RFC13
		58"/> 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:	[The IAB's] responsibilities shall include:
	[...]	[...]

	(2) The editorial management and publication of the Request for	(2) The editorial management and publication of the Request
	Comments (RFC) document series, which constitutes the	for Comments (RFC) document series, which constitutes the
	archival publication series for Internet Standards and	archival publication series for Internet Standards and
	related contributions by the Internet research and	related contributions by the Internet research and
	engineering community.	engineering community.

	</artwork></figure>	</artwork>
	</section>	</blockquote>
		</section>
	<section anchor="circa1994" title="1994">	<section anchor="circa1994" numbered="true" toc="include" removeInRFC="fal
	<t>	se" pn="section-a.2">
	<xref target="RFC1601"/> says:	<name slugifiedName="name-1994">1994</name>
	</t>	<t pn="section-a.2-1">
	<figure><artwork>	<xref target="RFC1601" format="default" sectionFormat="of" derivedContent="RFC16
		01"/> 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:	[The IAB's] responsibilities under this charter include:

	(d) RFC Series and IANA	(d) RFC Series and IANA


	The IAB is responsible for editorial management and publication of	The IAB is responsible for editorial management and publication
	the Request for Comments (RFC) document series, and for	of the Request for Comments (RFC) document series, and for
	administration of the various Internet assigned numbers.	administration of the various Internet assigned numbers.

		</artwork>
	which it elaborates as	</blockquote>
		<t pn="section-a.2-3">
		Which it elaborates as:
		</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	2.4 RFC Series and Assigned Numbers


	The RFC Series constitutes the archival publication channel for	The RFC Series constitutes the archival publication channel
	Internet Standards and for other contributions by the Internet	for Internet Standards and for other contributions by the
	research and engineering community. The IAB shall select an RFC	Internet research and engineering community. The IAB
	Editor, who shall be responsible for the editorial management and	shall select an RFC Editor, who shall be responsible for
	publication of the RFC Series.	the editorial management and publication of the RFC Series.
	</artwork></figure>	</artwork>
	</section>	</blockquote>
		</section>
	<section anchor="circa2000" title="2000">	<section anchor="circa2000" numbered="true" toc="include" removeInRFC="fal
	<t>	se" pn="section-a.3">
	The most recent IAB Charter <xref target="RFC2850"/> says:	<name slugifiedName="name-2000">2000</name>
		<t pn="section-a.3-1">
		The most recent IAB Charter <xref target="RFC2850" format="default" sectionForma
		t="of" derivedContent="RFC2850"/> says:
	</t>	</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	(d) RFC Series and IANA


	The RFC Editor executes editorial management and publication of the	The RFC Editor executes editorial management and publication of
	IETF "Request for Comment" (RFC) document series, which is the	the IETF "Request for Comment" (RFC) document series, which is
	permanent document repository of the IETF. The RFC Series	the permanent document repository of the IETF. The RFC Series
	constitutes the archival publication channel for Internet Standards	constitutes the archival publication channel for Internet
	and for other contributions by the Internet research and engineering	Standards and for other contributions by the Internet research
	community. RFCs are available free of charge to anyone via the	and engineering community. RFCs are available free of charge to
	Internet. The IAB must approve the appointment of an organization to	anyone via the Internet. The IAB must approve the appointment
	act as RFC Editor and the general policy followed by the RFC Editor.	of an organization to act as RFC Editor and the general policy
	</artwork></figure>	followed by the RFC Editor.</artwork>
	</section>	</blockquote>
	</section>	</section>
		</section>
	<section title="IAB Members at the Time of Approval">	<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
	<t>	ndix.b">
	{{ RFC Editor: Fill in the current membership. }}	<name slugifiedName="name-iab-members-at-the-time-of-">IAB Members at the
		Time of Approval</name>
		<t pn="section-appendix.b-1">
		The IAB members at the time of approval of RFC 4844 were:
	</t>	</t>

	</section>	<ul empty="true" spacing="compact" bare="false" pn="section-appendix.b-2">
		<li pn="section-appendix.b-2.1">
	</back>	<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 the 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="edit
		or">
		<organization showOnFrontPage="true"/>
		<address>
		<email>housley@vigilsec.com</email>
		</address>
		</author>
		<author fullname="Leslie L. Daigle" initials="L." surname="Daigle" role="e
		ditor">
		<organization showOnFrontPage="true"/>
		<address>
		<email>ldaigle@thinkingcat.com</email>
		</address>
		</author>
		</section>
		</back>
	</rfc>	</rfc>

End of changes. 145 change blocks.
	502 lines changed or deleted	1498 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/