rfc8726v1.txt		rfc8726.txt
	Independent Submission A. Farrel		Independent Submission A. Farrel
	Request for Comments: 8726 Independent Submissions Editor		Request for Comments: 8726 Independent Submissions Editor
	Category: Informational February 2020		Category: Informational October 2020
	ISSN: 2070-1721		ISSN: 2070-1721
	How Requests for IANA Action Will be Handled on the Independent Stream		How Requests for IANA Action Will Be Handled on the Independent Stream
	Abstract		Abstract
	The Internet Assigned Numbers Authority (IANA) maintains registries		The Internet Assigned Numbers Authority (IANA) maintains registries
	to track code points used by protocols such as those defined by the		to track code points used by protocols such as those defined by the
	IETF and documented in RFCs developed on the IETF Stream.		IETF and documented in RFCs developed on the IETF Stream.
	The Independent Submissions Stream is another source of documents		The Independent Submissions Stream is another source of documents
	that can be published as RFCs. This stream is under the care of the		that can be published as RFCs. This stream is under the care of the
	Independent Submissions Editor (ISE).		Independent Submissions Editor (ISE).
	skipping to change at line 63 ¶		skipping to change at line 63 ¶
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	2. Allocations from Existing Registries		2. Allocations from Existing Registries
	3. Changing Policies of Existing Registries		3. Changing Policies of Existing Registries
	4. Creating New IANA Registries		4. Creating New IANA Registries
	5. Assigning Designated Experts		5. Assigning Designated Experts
	6. Transfer of Control		6. Transfer of Control
	7. IANA Considerations		7. IANA Considerations
	8. Security Considerations		8. Security Considerations
	9. Normative References		9. References
			9.1. Normative References
			9.2. URL References
	Acknowledgements		Acknowledgements
	Author's Address		Author's Address
	1. Introduction		1. Introduction
	The Internet Assigned Numbers Authority (IANA) maintains registries		The Internet Assigned Numbers Authority (IANA) maintains registries
	to track code points used by protocols such as those defined by the		to track code points used by protocols such as those defined by the
	IETF and documented in RFCs developed on the IETF Stream. A full		IETF and documented in RFCs developed on the IETF Stream. A full
	list of registries and code points can be found at		list of registries and code points can be found at
	https://www.iana.org/protocols.		https://www.iana.org/protocols.
	skipping to change at line 129 ¶		skipping to change at line 131 ¶
	allocation policy of the registry itself and usually require		allocation policy of the registry itself and usually require
	documentation from the same stream that created the registry.		documentation from the same stream that created the registry.
	Independent Stream RFCs will not seek to change the allocation		Independent Stream RFCs will not seek to change the allocation
	policies of any registries except those created by documents from the		policies of any registries except those created by documents from the
	Independent Stream. The list of such registries is itself very		Independent Stream. The list of such registries is itself very
	limited (see Section 4).		limited (see Section 4).
	4. Creating New IANA Registries		4. Creating New IANA Registries
	Sometimes, new registries are needed to track a new set of code		Sometimes registries are needed to track a new set of codepoints for
	points for a new protocol or an extension to an existing protocol.		a new protocol or an extension to an existing protocol.
	In general, documents on the Independent Stream cannot request the		In general, documents on the Independent Stream cannot request the
	creation of a new registry.		creation of a new IANA registry.
	The only exception to this rule is the creation of a subregistry that		The only exception to this rule is when a document to be published in
	is specifically tied to a code point allocated for the same document		the Independent Submission Stream requests the allocation of a code
	from an existing registry where the allocation policy for that		point from an existing registry with allocation policy Specification
	document is Specification Required, Expert Review, RFC Required, or		Required, Expert Review, RFC Required, or First Come First Served.
	First Come First Served. Furthermore, where there is an appointed DE		Then the document to be published may also need to create a registry
	for the parent registry, that DE must approve the creation of the		that is tied to that specific code point and is used for
	subregistry. Additionally, the allocation policy for the new		interpretting a sub-code.
	subregistry may only be First Come First Served, RFC Required,
	Experimental, or Private Use. In particular, no subregistry may be		Consider, for example, the "Uniform Resource Identifier (URI)
	created that would require IETF action to achieve a future code point		Schemes" registry [URL-URIschemes]. From time to time, a URI scheme
	allocation. See Section 5 for an explanation of why the application		may need a registry of associated parameters: for example, consider
	of Specification Required and Expert Review are not acceptable		the tel URI scheme that has a register of parameteds called the "tel
	policies for any subregistry created from a document in the		URI Parameters" [URL-telURI].
	Independent Stream.
			Such examples are rare, and only exist to support the allocation from
			the base registry. In such cases, where there is an appointed DE for
			the existing base registry, the assignment of the individual code
			point from the existing base registry and the creation of the new
			registry can only happen if the DE approves both actions.
			There are several further constraints on the new registry:
			* 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 codepoint allocation. See Section 5
			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.
			* 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 arrival rate of new registrations over
			time.
			* 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:
			| This registry was created by [RFCabcd] which was published on the
			| Independent Submissions Stream. Any issues that arise with the
			| management of this registry will be resolved by IANA in
			| consultation with the Independent Submissions Editor.
			* The IESG will be invited to provide their opinions about the
			advisability of creation of any new registries during their
			conflict review of the document [RFC5742] and the ISE will give
			full consideration to such opinions.
			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.
	5. Assigning Designated Experts		5. Assigning Designated Experts
	Some IANA allocation policies (specifically, Specification Required		Some IANA allocation policies (specifically, Specification Required
	and Expert Review) utilize the review of a DE. The procedures		and Expert Review) utilize the review of a DE. The procedures
	applicable to the appointment and actions of a DE are described in		applicable to the appointment and actions of a DE are described in
	Section 5 of [RFC8126].		Section 5 of [RFC8126].
	When a DE is appointed, the position must be maintained and supported		When a DE is appointed, the position must be maintained and supported
	by whoever designated the DE in the first place. That is, someone		by whoever designated the DE in the first place. That is, someone
	skipping to change at line 193 ¶		skipping to change at line 236 ¶
	8. Security Considerations		8. Security Considerations
	There are no direct security considerations arising from this		There are no direct security considerations arising from this
	document. It may be noted that some IANA registries relate to		document. It may be noted that some IANA registries relate to
	security protocols, and the stability and proper management of those		security protocols, and the stability and proper management of those
	registries contribute to the stability of the protocols themselves.		registries contribute to the stability of the protocols themselves.
	That is a benefit for the security of the Internet and the users of		That is a benefit for the security of the Internet and the users of
	the Internet.		the Internet.
	9. Normative References		9. References
			9.1. Normative References
	[RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent		[RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent
	Submissions to the RFC Editor", RFC 4846,		Submissions to the RFC Editor", RFC 4846,
	DOI 10.17487/RFC4846, July 2007,		DOI 10.17487/RFC4846, July 2007,
	<https://www.rfc-editor.org/info/rfc4846>.		<https://www.rfc-editor.org/info/rfc4846>.
			[RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for
			Handling of Independent and IRTF Stream Submissions",
			BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009,
			<https://www.rfc-editor.org/info/rfc5742>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
			9.2. URL References
			[URL-telURI]
			"tel URI Parameters", <https://www.iana.org/assignments/t\
			el-uri-parameters/tel-uri-parameters.xhtml>.
			[URL-URIschemes]
			"Uniform Resource Identifier (URI) Schemes",
			<https://www.iana.org/assignmen\ ts/uri-schemes/uri-
			schemes.xhtml>.
	Acknowledgements		Acknowledgements
	Thanks to Brian Carpenter, Subramanian Moonesamy, Craig Partridge,		Thanks to Brian Carpenter, Subramanian Moonesamy, Craig Partridge,
	Michelle Cotton, Andrew Malis, Warren Kumari, Ned Freed, Rich Salz,		Michelle Cotton, Andrew Malis, Warren Kumari, Ned Freed, Rich Salz,
	Michael Richardson, Colin Perkins, Stephen Farrell, Barry Leiba, and		Michael Richardson, Colin Perkins, Stephen Farrell, Barry Leiba, and
	Benjamin Kaduk for suggestions and advice.		Benjamin Kaduk for suggestions and advice.
	Author's Address		Author's Address
	Adrian Farrel		Adrian Farrel
End of changes. 9 change blocks.
	21 lines changed or deleted		82 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/