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">		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info"
	<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC		docName="draft-ise-iana-policy-03" number="8726" ipr="trust200902"
	.8126.xml">		obsoletes="" updates="" submissionType="independent" xml:lang="en"
	]>		tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
			<!-- xml2rfc v2v3 conversion 2.35.0 -->
	<rfc category="info" docName="draft-ise-iana-policy-03" ipr="trust200902">
	<front>		<front>
	<title abbrev="IANA and the Independent Stream">How Requests for IANA Action Will be Handled on the Independent Stream</title>		<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="February" 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 Submissions 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 Submissions Stream is another source of documents that can be published as		<t>The Independent Submissions Stream is another source of documents that 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 Submissions Stream that request ac tions 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 Submissions Stream (the Independent
	tream) as described in		Stream), 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">
	<section anchor="new" title="Creating New IANA Registries">		<name>Creating New IANA Registries</name>
			<t>Sometimes, new registries are needed to track a new set of code points
	<t>Sometimes new registries are needed to track a new set of codepoints f		for a new protocol or an
	or a new protocol or an
	extension to an existing protocol. In general, documents on the Indep endent Stream cannot		extension to an existing protocol. In general, documents on the Indep endent Stream cannot
	request the creation of a new registry.</t>		request the creation of a new registry.</t>
			<t>The only exception to this rule is the creation of a subregistry that i
	<t>The only exception to this rule is the creation of a sub-registry that		s specifically tied to
	is specifically tied to
	a code point allocated for the same document from an existing registry where the allocation		a code point allocated for the same document from an existing registry where the allocation
	policy for that document is Specification Required, Expert Review, RFC Required, or First Come		policy for that document is Specification Required, Expert Review, RFC Required, or First Come
	First Served. Furthermore, where there is an appointed DE for the par ent registry, that DE must		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		approve the creation of the subregistry. Additionally, the allocation
	n policy for the new		policy for the new
	sub-registry may only be First Come First Served, RFC Required, Experi		subregistry may only be First Come First Served, RFC Required, Experim
	mental, or Private Use.		ental, or Private Use.
	In particular, no sub-registry may be created that would require IETF		In particular, no subregistry may be created that would require IETF a
	action to achieve a future		ction to achieve a future
	codepoint allocation. See <xref target="de" /> for an explanation of		code point allocation. See <xref target="de" format="default"/> for a
	why the application of		n explanation of why the application of
	Specification Required and Expert Review are not acceptable policies f		Specification Required and Expert Review are not acceptable policies f
	or any sub-registry created		or any subregistry created
	from a document in the Independent Stream.</t>		from a document in the Independent Stream.</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>
	<references title="Normative References">		<name>Normative References</name>
	&RFC4846;		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	&RFC8126;		.4846.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
			.8126.xml"/>
	</references>		</references>
			<!-- [rfced] "Brian Carpenter" appeared twice in the Acknowledgements
			section. We have removed one.
			Original:
			Thanks to Brian Carpenter, Subramanian Moonesamy, Craig Partridge, Michelle
			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.
			-->
			<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. 46 change blocks.
	162 lines changed or deleted		127 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/