rfc8726xml2.original.xml		rfc8726.xml
	<?xml version="1.0" encoding="US-ASCII"?>		<?xml version='1.0' encoding='utf-8'?>
	<?rfc toc="yes"?>
	<?rfc tocompact="yes"?>
	<?rfc tocdepth="3"?>
	<?rfc tocindent="yes"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes"?>
	<?rfc comments="yes"?>
	<?rfc inline="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [		<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<!ENTITY RFC4846 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.4846.xml">
	<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8126.xml">
	]>
	<rfc category="info" docName="draft-ise-iana-policy-03" ipr="trust200902">		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info"
	<front>		docName="draft-ise-iana-policy-04" number="8726" ipr="trust200902"
	<title abbrev="IANA and the Independent Stream">How Requests for IANA Action		obsoletes="" updates="" submissionType="independent" xml:lang="en"
	Will be Handled on the Independent Stream</title>		tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
			<front>
			<title abbrev="IANA and the Independent Stream">How Requests for IANA Action
			Will Be Handled on the Independent Stream</title>
			<seriesInfo name="RFC" value="8726"/>
	<author fullname="Adrian Farrel" initials="A." surname="Farrel">		<author fullname="Adrian Farrel" initials="A." surname="Farrel">
	<organization>Independent Submissions Editor</organization>		<organization>Independent Submissions Editor</organization>
	<address>		<address>
	<email>rfc-ise@rfc-editor.org</email>		<email>rfc-ise@rfc-editor.org</email>
	</address>		</address>
	</author>		</author>
			<date month="November" year="2020"/>
	<date month="" year="2019"/>		<area/>
			<workgroup/>
	<area></area>
	<workgroup></workgroup>
	<keyword>IANA</keyword>		<keyword>IANA</keyword>
	<keyword>Independent Submissions Stream</keyword>		<keyword>Independent Submission Stream</keyword>
	<keyword>ISE</keyword>		<keyword>ISE</keyword>
	<abstract>		<abstract>
			<t>The Internet Assigned Numbers Authority (IANA) maintains registries
	<t>The Internet Assigned Numbers Authority (IANA) maintains registries to		to track code points used
	track codepoints used
	by protocols such as those defined by the IETF and documented in RFCs d eveloped on the IETF		by protocols such as those defined by the IETF and documented in RFCs d eveloped on the IETF
	Stream.</t>		Stream.</t>
			<t>The Independent Submission Stream is another source of documents that c
	<t>The Independent Submissions Stream is another source of documents that		an be published as
	can be published as
	RFCs. This stream is under the care of the Independent Submissions Edi tor (ISE).</t>		RFCs. This stream is under the care of the Independent Submissions Edi tor (ISE).</t>
	<t>This document complements RFC 4846 by providing a description of how th e ISE currently		<t>This document complements RFC 4846 by providing a description of how th e ISE currently
	handles documents in the Independent Submissions Stream that request ac tions from the IANA.		handles documents in the Independent Submission Stream that request act ions from IANA.
	Nothing in this document changes existing IANA registries or their allo cation policies, nor		Nothing in this document changes existing IANA registries or their allo cation policies, nor
	does it change any previously documented processes.</t>		does it change any previously documented processes.</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section title="Introduction">		<section numbered="true" toc="default">
			<name>Introduction</name>
	<t>The Internet Assigned Numbers Authority (IANA) maintains registries to		<t>The Internet Assigned Numbers Authority (IANA) maintains registries
	track codepoints used		to track code points used
	by protocols such as those defined by the IETF and documented in RFCs d eveloped on the IETF Stream.		by protocols such as those defined by the IETF and documented in RFCs d eveloped on the IETF Stream.
	A full list of registries and code points can be found at		A full list of registries and code points can be found at
	<eref target="https://www.iana.org/protocols" />.</t>		<eref target="https://www.iana.org/protocols"/>.</t>
	<t>Requests may be made to IANA for actions to create registries or to all ocate code points from		<t>Requests may be made to IANA for actions to create registries or to all ocate code points from
	existing registries. Procedures for these operations are described in		existing registries. Procedures for these operations are described in
	<xref target="RFC8126" />.</t>		<xref target="RFC8126" format="default"/>.</t>
	<t>Many requests for IANA action are included in documents that are progre ssed for publication as RFCs.		<t>Many requests for IANA action are included in documents that are progre ssed for publication as RFCs.
	RFCs may be sourced from within the IETF (on the IETF Stream), but may		RFCs may be sourced from within the IETF (on the IETF Stream) but may a
	also be sourced from other		lso be sourced from other
	streams including the Independent Submissions Stream (the Independent S		streams, including the Independent Submission Stream (the Independent S
	tream) as described in		tream), as described in
	<xref target="RFC4846" />. The Independent Stream is under the care of		<xref target="RFC4846" format="default"/>. The Independent Stream is u
	the Independent Submissions Editor		nder the care of the Independent Submissions Editor
	(ISE).</t>		(ISE).</t>
			<t>This document complements <xref target="RFC4846" format="default"/> by
	<t>This document complements <xref target="RFC4846" /> by providing a desc		providing a description of how the ISE
	ription of how the ISE		currently handles documents in the Independent Stream that request acti
	currently handles documents in the Independent Stream that request acti		ons from IANA. Nothing
	ons from the IANA. Nothing
	in this document changes existing IANA registries or their allocation p olicies, nor does it change		in this document changes existing IANA registries or their allocation p olicies, nor does it change
	any previously documented processes.</t>		any previously documented processes.</t>
			<t>If a case arises that is not precisely covered by this document, the IS
	<t>In the event that a case arises that is not precisely covered by this d		E may discuss
	ocument, the ISE may discuss
	a solution with the interested parties, including IANA, the IESG, the s tream managers for other streams,		a solution with the interested parties, including IANA, the IESG, the s tream managers for other streams,
	and the authors of an Independent Submission that requests IANA action. </t>		and the authors of an Independent Submission that requests IANA action. </t>
	</section>		</section>
			<section anchor="exist" numbered="true" toc="default">
	<section anchor="exist" title="Allocations from Existing Registries">		<name>Allocations from Existing Registries</name>
			<t>Each IANA registry is governed by an allocation policy -- the rules tha
	<t>Each IANA registry is governed by an allocation policy: the rules that		t IANA applies to determine
	IANA applies to determine
	which code points can be allocated and under what circumstances. These policies are described in		which code points can be allocated and under what circumstances. These policies are described in
	<xref target="RFC8126" />.</t>		<xref target="RFC8126" format="default"/>.</t>
	<t>Documents proceeding from the Independent Stream will always follow the assignment policies defined		<t>Documents proceeding from the Independent Stream will always follow the assignment policies defined
	for the registries from which they request allocations. Similarly, all code point assignments are		for the registries from which they request allocations. Similarly, all code point assignments are
	subject to the oversight of any Designated Expert (DE) appointed for th		subject to the oversight of any designated expert (DE) appointed for th
	e registry.</t>		e registry.</t>
	<t>It should be noted that documents on the Independent Stream can never r esult in Standards Track		<t>It should be noted that documents on the Independent Stream can never r esult in Standards Track
	RFCs and Independent Stream documents are never subject to IETF review.		RFCs and Independent Stream documents are never subject to IETF review.
	Thus a registry whose		Thus, a registry whose
	policy is "IETF Review" or "Standards Action" [RFC8126] is not availabl		policy is "IETF Review" or "Standards Action" <xref target="RFC8126" fo
	e to Independent Stream		rmat="default"/> is not available to Independent Stream
	documents.</t>		documents.</t>
	</section>		</section>
			<section anchor="change" numbered="true" toc="default">
	<section anchor="change" title="Changing Policies of Existing Registries">		<name>Changing Policies of Existing Registries</name>
			<t>From time to time, a decision is made to change the allocation policy f
	<t>From time to time a decision is made to change the allocation policy f		or a registry. Such changes
	or a registry. Such changes		are normally only made using the allocation policy of the registry its
	are normally only made using allocation policy of the registry itself,		elf and usually require documentation
	and usually require documentation		from the same stream that created the registry.</t>
	from the same stream as created the registry.</t>		<t>Independent Stream RFCs will not seek to change the allocation policies
			of any registries except
	<t>Independent Stream RFCs will not seek to change the allocation policie		those created by documents from the Independent Stream. The list of s
	s of any registries except		uch registries is itself
	those created by documents from the Independent Stream. The list of s		very limited (see <xref target="new" format="default"/>).</t>
	uch registries is, itself,
	very limited (see <xref target="new" />).</t>
	</section>		</section>
			<section anchor="new" numbered="true" toc="default">
			<name>Creating New IANA Registries</name>
			<t>Sometimes registries are needed to track a new set of code points for a new p
			rotocol or an extension to an existing protocol.</t>
			<t>In general, documents on the Independent Stream cannot request the
			creation of a new IANA registry.</t>
	<section anchor="new" title="Creating New IANA Registries">		<t>The only exception to this rule is when a document to be published in
			the Independent Submission Stream requests the allocation of a code
			point from an existing registry with the allocation policy Specification
			Required, Expert Review, RFC Required, or First Come First Served.
			Then the document to be published may also need to create a registry
			that is tied to that specific code point and is used for
			interpreting a sub-code.</t>
	<t>Sometimes new registries are needed to track a new set of codepoints f		<t>Consider, for example, the "Uniform Resource Identifier (URI)
	or a new protocol or an		Schemes" registry <xref target="URL-URIschemes"/>. From time to time, a URI
	extension to an existing protocol. In general, documents on the Indep		scheme
	endent Stream cannot		may need a registry of associated parameters; for example, consider
	request the creation of a new registry.</t>		the tel URI scheme that has a register of parameters called the "tel
			URI Parameters" <xref target="URL-telURI"/>.</t>
	<t>The only exception to this rule is the creation of a sub-registry that		<t>Such examples are rare and only exist to support the allocation from
	is specifically tied to		the base registry. In such cases, where there is an appointed DE for
	a code point allocated for the same document from an existing registry		the existing base registry, the assignment of the individual code
	where the allocation		point from the existing base registry and the creation of the new
	policy for that document is Specification Required, Expert Review, RFC		registry can only happen if the DE approves both actions.</t>
	Required, or First Come
	First Served. Furthermore, where there is an appointed DE for the par
	ent registry, that DE must
	approve the creation of the sub-registry. Additionally, the allocatio
	n policy for the new
	sub-registry may only be First Come First Served, RFC Required, Experi
	mental, or Private Use.
	In particular, no sub-registry may be created that would require IETF
	action to achieve a future
	codepoint allocation. See <xref target="de" /> for an explanation of
	why the application of
	Specification Required and Expert Review are not acceptable policies f
	or any sub-registry created
	from a document in the Independent Stream.</t>
			<t>There are several further constraints on the new registry:</t>
			<ul>
			<li>The allocation policy for the new registry may only be First Come
			First Served, RFC Required, Experimental, or Private Use. In
			particular, no registry may be created that would require IETF
			action to achieve a future code point allocation. See <xref
			target="de"/> for an explanation of why the application of Specification
			Required and Expert Review are not acceptable policies for any
			registry created from a document in the Independent Stream.</li>
			<li>If the allocation policy for the new registry is First Come First Served,
			the document must contain a brief statement and explanation of the expected arri
			val rate of new registrations over time.</li>
			<li>The new registry must contain a clear statement of the escalation
			process for any issues that arise with the registry. A model for
			this statement is as follows:</li></ul>
			<blockquote>
			This registry was created by [RFCXXXX], which was published on
			the Independent Submission Stream. Any issues that arise with
			the management of this registry will be resolved by IANA in
			consultation with the Independent Submissions Editor.</blockquote>
			<ul>
			<li>The IESG will be invited to provide its opinions about the
			advisability of the creation of any new registries during its
			conflict review of the document <xref target="RFC5742"/>, and the ISE will
			give
			full consideration to such opinions.</li></ul>
			<t>
			Authors of Independent Submission Stream documents should consider
			the most appropriate venue to host such registries, taking into
			account where the expertise for managing and reviewing registry
			assignments may be found. In some cases, this may mean that
			registries are hosted by organizations other than IANA.</t>
	</section>		</section>
			<section anchor="de" numbered="true" toc="default">
	<section anchor="de" title="Assigning Designated Experts">		<name>Assigning Designated Experts</name>
			<t>Some IANA allocation policies (specifically, Specification Required and
	<t>Some IANA allocation policies (specifically, Specification Required an		Expert Review) utilize
	d Expert Review) utilize
	the review of a DE. The procedures applicable to the appointment and actions of a DE are		the review of a DE. The procedures applicable to the appointment and actions of a DE are
	described in section 5 of <xref target="RFC8126" />.</t>		described in <xref target="RFC8126" sectionFormat="of" section="5"/>.<
			/t>
	<t>When a DE is appointed, the position must be maintained and supported		<t>When a DE is appointed, the position must be maintained and supported b
	by whoever designated the		y whoever designated the
	DE in the first place. That is, someone must appoint replacement DEs if necessary, and someone		DE in the first place. That is, someone must appoint replacement DEs if necessary, and someone
	must provide a backstop in case the appointed DEs are unresponsive.</t >		must provide a backstop in case the appointed DEs are unresponsive.</t >
			<t>The ISE will not appoint a DE. That means that no subregistry created
	<t>The ISE will not appoint a DE. That means that no sub-registry create		for Independent Stream
	d for Independent Stream		documents will require the review of a DE. That means that no new sub
	documents will require the review of a DE. That means that no new sub		registry can be
	-registry can be
	created that uses the Specification Required or Expert Review policies .</t>		created that uses the Specification Required or Expert Review policies .</t>
	</section>		</section>
			<section anchor="tx" numbered="true" toc="default">
	<section anchor="tx" title="Transfer of Control">		<name>Transfer of Control</name>
			<t>Very rarely, it may be desirable to transfer "ownership" of an IANA reg
	<t>Very rarely, it may be desirable to transfer "ownership" of an IANA re		istry from the Independent
	gistry from the Independent
	Stream to the IETF Stream. This might happen, for example, if a proto col was originally		Stream to the IETF Stream. This might happen, for example, if a proto col was originally
	documented in the Independent Stream, but has been adopted for work an d standardization		documented in the Independent Stream but has been adopted for work and standardization
	in the IETF. Such a transfer may require an IETF Stream RFC to act as the base reference for the		in the IETF. Such a transfer may require an IETF Stream RFC to act as the base reference for the
	registry, and will require discussion and agreement with the ISE.</t>		registry and will require discussion and agreement with the ISE.</t>
			<t>Ownership of a registry will not be transferred from the IETF Stream to
	<t>Ownership of a registry will not be transferred from the IETF Stream t		the Independent Stream.</t>
	o the Independent Stream.</t>
	</section>		</section>
			<section anchor="IANA" numbered="true" toc="default">
	<section anchor="IANA" title="IANA Considerations">		<name>IANA Considerations</name>
			<t>This document is all about IANA actions but makes no request for IANA a
	<t>This document is all about IANA actions, but makes no request for IANA		ction.</t>
	action.</t>
	</section>		</section>
			<section anchor="Security" numbered="true" toc="default">
	<section anchor="Security" title="Security Considerations">		<name>Security Considerations</name>
	<t>There are no direct security considerations arising from this document. It may be noted that some IANA		<t>There are no direct security considerations arising from this document. It may be noted that some IANA
	registries relate to security protocols, and the stability and proper m anagement of those registries		registries relate to security protocols, and the stability and proper m anagement of those registries
	contributes to the stability of the protocols themselves. That is a be nefit for the security of the		contribute to the stability of the protocols themselves. That is a ben efit for the security of the
	Internet and the users of the Internet.</t>		Internet and the users of the Internet.</t>
	</section>
	<section anchor="Acknowledgements" title="Acknowledgements">
	<t>Thanks to Brian Carpenter, Subramanian Moonesamy, Craig Partridge, Mich
	elle Cotton, Andrew Malis,
	Warren Kumari, Ned Freed, Rich Salz, Michael Richardson, Colin Perkins,
	Brian Carpenter, Stephen Farrell,
	Barry Leiba, and Benjamin Kaduk for suggestions and advice.</t>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
			<references>
			<name>References</name>
			<references>
			<name>Normative References</name>
			<xi:include
			href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4846.xml
			"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.5742.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.8126.xml"/>
			</references>
			<references>
			<name>Informative References</name>
			<reference anchor="URL-URIschemes" target="https://www.iana.org/assignments/ur
			i-schemes">
			<front>
			<title>Uniform Resource Identifier (URI) Schemes</title>
			<author>
			<organization></organization>
			</author>
			<date />
			</front>
			</reference>
	<references title="Normative References">		<reference anchor="URL-telURI"
	&RFC4846;		target="https://www.iana.org/assignments/tel-uri-parameters">
	&RFC8126;		<front>
			<title>tel URI Parameters</title>
			<author>
			<organization></organization>
			</author>
			<date />
			</front>
			</reference>
			</references>
	</references>		</references>
			<section anchor="Acknowledgements" numbered="false" toc="default">
			<name>Acknowledgements</name>
			<t>Thanks to <contact fullname="Brian Carpenter" />, <contact
			fullname="Subramanian Moonesamy" />, <contact fullname="Craig Partridge"
			/>, <contact fullname="Michelle Cotton" />, <contact fullname="Andrew
			Malis" />, <contact fullname="Warren Kumari" />, <contact fullname="Ned
			Freed" />, <contact fullname="Rich Salz" />, <contact fullname="Michael
			Richardson" />, <contact fullname="Colin Perkins" />, <contact fullname="S
			tephen Farrell" />,
			<contact fullname="Barry Leiba" />, and <contact fullname="Benjamin
			Kaduk" /> for suggestions and advice.</t>
			</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 48 change blocks.
	172 lines changed or deleted		191 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/