< draft-leiba-cotton-iana-5226bis-13.txt		draft-leiba-cotton-iana-5226bis-14.txt >
	Network Working Group M. Cotton		Network Working Group M. Cotton
	Internet-Draft ICANN		Internet-Draft ICANN
	BCP: 26 B. Leiba		BCP: 26 B. Leiba
	Obsoletes: 5226 (if approved) Huawei Technologies		Obsoletes: 5226 (if approved) Huawei Technologies
	Intended status: Best Current Practice T. Narten		Intended status: Best Current Practice T. Narten
	Expires: November 24, 2016 IBM Corporation		Expires: November 29, 2016 IBM Corporation
	May 25, 2016		May 30, 2016
	Guidelines for Writing an IANA Considerations Section in RFCs		Guidelines for Writing an IANA Considerations Section in RFCs
	draft-leiba-cotton-iana-5226bis-13		draft-leiba-cotton-iana-5226bis-14
	Abstract		Abstract
	Many protocols make use of points of extensibility that use constants		Many protocols make use of points of extensibility that use constants
	to identify various protocol parameters. To ensure that the values		to identify various protocol parameters. To ensure that the values
	used in these fields do not have conflicting uses, and to promote		used in these fields do not have conflicting uses, and to promote
	interoperability, their allocation is often coordinated by a central		interoperability, their allocation is often coordinated by a central
	record keeper. For IETF protocols, that role is filled by the		record keeper. For IETF protocols, that role is filled by the
	Internet Assigned Numbers Authority (IANA).		Internet Assigned Numbers Authority (IANA).
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 48 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 24, 2016.		This Internet-Draft will expire on November 29, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (http://trustee.ietf.org/		Provisions Relating to IETF Documents (http://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 38 ¶		skipping to change at page 2, line 38 ¶
	3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 12		3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 12
	4. Choosing a Registration Policy, and Well-Known Policies . . . 13		4. Choosing a Registration Policy, and Well-Known Policies . . . 13
	4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 15		4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 15
	4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . . 15		4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . . 15
	4.3. Hierarchical Allocation . . . . . . . . . . . . . . . . . 16		4.3. Hierarchical Allocation . . . . . . . . . . . . . . . . . 16
	4.4. First Come First Served . . . . . . . . . . . . . . . . . 16		4.4. First Come First Served . . . . . . . . . . . . . . . . . 16
	4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 17		4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 17
	4.6. Specification Required . . . . . . . . . . . . . . . . . . 18		4.6. Specification Required . . . . . . . . . . . . . . . . . . 18
	4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . . 19		4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . . 19
	4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 19		4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 19
	4.9. Standards Action . . . . . . . . . . . . . . . . . . . . . 19		4.9. Standards Action . . . . . . . . . . . . . . . . . . . . . 20
	4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 20		4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 20
	4.11. Using the Well-Known Registration Policies . . . . . . . . 20		4.11. Using the Well-Known Registration Policies . . . . . . . . 21
	4.12. Using Multiple Policies in Combination . . . . . . . . . . 21		4.12. Using Multiple Policies in Combination . . . . . . . . . . 22
	5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 22		5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 23
	5.1. The Motivation for Designated Experts . . . . . . . . . . 22		5.1. The Motivation for Designated Experts . . . . . . . . . . 23
	5.2. The Role of the Designated Expert . . . . . . . . . . . . 22		5.2. The Role of the Designated Expert . . . . . . . . . . . . 23
	5.2.1. Managing Designated Experts in the IETF . . . . . . . 23		5.2.1. Managing Designated Experts in the IETF . . . . . . . 24
	5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 24		5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 25
	5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 25		5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 26
	6. Well-Known Registration Status Terminology . . . . . . . . . . 26		6. Well-Known Registration Status Terminology . . . . . . . . . . 27
	7. Documentation References in IANA Registries . . . . . . . . . 27		7. Documentation References in IANA Registries . . . . . . . . . 27
	8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 27		8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 28
	9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 28		9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 29
	9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 28		9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 29
	9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 29		9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 30
	9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 29		9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 30
	9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 29		9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 30
	9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 30		9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 31
	9.6. Closing or Obsoleting a Registry/Registrations . . . . . . 31		9.6. Closing or Obsoleting a Registry/Registrations . . . . . . 32
	10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 31		10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 31		11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 32
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 31		12. Security Considerations . . . . . . . . . . . . . . . . . . . 32
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
	14. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 32		14. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 33
	14.1. 2016: Changes in This Document Relative to RFC 5226 . . . 32		14.1. 2016: Changes in This Document Relative to RFC 5226 . . . 33
	14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 33		14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 34
	15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34		15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
	15.1. Acknowledgments for This Document (2016) . . . . . . . . 34		15.1. Acknowledgments for This Document (2016) . . . . . . . . 35
	15.2. Acknowledgments from the second edition (2008) . . . . . 34		15.2. Acknowledgments from the second edition (2008) . . . . . 35
	15.3. Acknowledgments from the first edition (1998) . . . . . . 34		15.3. Acknowledgments from the first edition (1998) . . . . . . 35
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35		16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	16.1. Normative References . . . . . . . . . . . . . . . . . . 35		16.1. Normative References . . . . . . . . . . . . . . . . . . 36
	16.2. Informative References . . . . . . . . . . . . . . . . . 35		16.2. Informative References . . . . . . . . . . . . . . . . . 36
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
	1. Introduction		1. Introduction
	Many protocols make use of points of extensibility that use constants		Many protocols make use of points of extensibility that use constants
	to identify various protocol parameters. To ensure that the values		to identify various protocol parameters. To ensure that the values
	used in these fields do not have conflicting uses, and to promote		used in these fields do not have conflicting uses, and to promote
	interoperability, their allocation is often coordinated by a central		interoperability, their allocation is often coordinated by a central
	record keeper. For IETF protocols, that role is filled by the		record keeper. For IETF protocols, that role is filled by the
	Internet Assigned Numbers Authority (IANA) [RFC2860].		Internet Assigned Numbers Authority (IANA) [RFC2860].
	skipping to change at page 15, line 55 ¶		skipping to change at page 16, line 5 ¶
	Experimental Use is similar to Private Use, but with the purpose		Experimental Use is similar to Private Use, but with the purpose
	being to facilitate experimentation. See [RFC3692] for details.		being to facilitate experimentation. See [RFC3692] for details.
	IANA does not record assignments from registries or ranges with this		IANA does not record assignments from registries or ranges with this
	policy (and therefore there is no need for IANA to review them) and		policy (and therefore there is no need for IANA to review them) and
	assignments are not generally useful for broad interoperability.		assignments are not generally useful for broad interoperability.
	Unless the registry explicitly allows it, it is not appropriate for		Unless the registry explicitly allows it, it is not appropriate for
	documents to select explicit values from registries or ranges with		documents to select explicit values from registries or ranges with
	this policy. Specific experiments will select a value to use during		this policy. Specific experiments will select a value to use during
	the experiment.		the experiment.
			When code points are set aside for experimental use, it's important
			to make clear any expected restrictions on experimental scope. For
			example, say whether it's acceptable to run experiments using those
			code points over the open Internet, or whether such experiments
			should be confined to more closed environments. See [RFC6994] for an
			example of such considerations.
	Example:		Example:
	Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP		Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP
	Headers [RFC4727]		Headers [RFC4727]
	4.3. Hierarchical Allocation		4.3. Hierarchical Allocation
	With Hierarchical Allocation, delegated administrators are given		With Hierarchical Allocation, delegated administrators are given
	control over part of the namespace, and can assign values in that		control over part of the namespace, and can assign values in that
	part of the namespace. IANA makes allocations in the higher levels		part of the namespace. IANA makes allocations in the higher levels
	skipping to change at page 16, line 39 ¶		skipping to change at page 17, line 4 ¶
	* IANA, which hands out OIDs the "Private Enterprises" branch,		* IANA, which hands out OIDs the "Private Enterprises" branch,
	* ANSI, which hands out OIDs under the "US Organizations" branch,		* ANSI, which hands out OIDs under the "US Organizations" branch,
	and		and
	* BSI, which hands out OIDs under the "UK Organizations" branch.		* BSI, which hands out OIDs under the "UK Organizations" branch.
	- URN namespaces. IANA registers URN Namespace IDs (NIDs [RFC3406]),		- URN namespaces. IANA registers URN Namespace IDs (NIDs [RFC3406]),
	and the organization registering an NID is responsible for		and the organization registering an NID is responsible for
	allocations of URNs within that namespace.		allocations of URNs within that namespace.
	4.4. First Come First Served		4.4. First Come First Served
	For the First Come First Served policy, assignments are made to		For the First Come First Served policy, assignments are made to
	anyone on a first come, first served basis. There is no substantive		anyone on a first come, first served basis. There is no substantive
	review of the request, other than to ensure that it is well-formed		review of the request, other than to ensure that it is well-formed
	and doesn't duplicate an existing assignment. However, requests must		and doesn't duplicate an existing assignment. However, requests must
	include a minimal amount of clerical information, such as a point of		include a minimal amount of clerical information, such as a point of
	contact (including an email address, and sometimes a postal address)		contact (including an email address, and sometimes a postal address)
	and a brief description of how the value will be used. Additional		and a brief description of how the value will be used. Additional
	information specific to the type of value requested may also need to		information specific to the type of value requested may also need to
	be provided, as defined by the namespace. For numbers, the exact		be provided, as defined by the namespace. For numbers, IANA
	value is generally assigned by IANA; with names, specific text		generally assigns the next in-sequence unallocated value, but other
	strings can usually be requested.		values may be requested and assigned if an extenuating circumstance
			exists. With names, specific text strings can usually be requested.
	When creating a new registry with First Come First Served as the		When creating a new registry with First Come First Served as the
	registration policy, in addition to the contact person field or		registration policy, in addition to the contact person field or
	reference, the registry should contain a field for change controller.		reference, the registry should contain a field for change controller.
	Having a change controller for each entry for these types of		Having a change controller for each entry for these types of
	registrations makes authorization of future modifications more clear.		registrations makes authorization of future modifications more clear.
	See Section 2.3. It is important that changes to the registration of		See Section 2.3.
	a First Come First Served code point retain compatibility with the
	current usage of that code point, and so changes need to be made with
	care.
	It is also important to understand that First Come First Served		It is important that changes to the registration of a First Come
	really has no filtering. Essentially, any well formed request is		First Served code point retain compatibility with the current usage
	accepted.		of that code point, and so changes need to be made with care. The
			change controller should not, in most cases, be requesting
			incompatible changes nor repurposing a registered code point. See
			also Section 9.4 and Section 9.5.
	A working group or any other entity that is developing a protocol		A working group or any other entity that is developing a protocol
	based on a First Come First Served code point has to be extremely		based on a First Come First Served code point has to be extremely
	careful that the protocol retains wire compatibility with current use		careful that the protocol retains wire compatibility with current use
	of the code point. Once that is no longer true, the new work needs		of the code point. Once that is no longer true, the new work needs
	to change to a different code point (and register that use at the		to change to a different code point (and register that use at the
	appropriate time).		appropriate time).
			It is also important to understand that First Come First Served
			really has no filtering. Essentially, any well formed request is
			accepted.
	Examples:		Examples:
	SASL mechanism names [RFC4422]		SASL mechanism names [RFC4422]
	LDAP Protocol Mechanisms and LDAP Syntax [RFC4520]		LDAP Protocol Mechanisms and LDAP Syntax [RFC4520]
	4.5. Expert Review		4.5. Expert Review
	(Also called "Designated Expert" in earlier editions of this		(Also called "Designated Expert" in earlier editions of this
	document.) For the Expert Review policy, review and approval by a		document.) For the Expert Review policy, review and approval by a
	designated expert (see Section 5) is required.		designated expert (see Section 5) is required.
	skipping to change at page 21, line 16 ¶		skipping to change at page 21, line 48 ¶
	interoperability.		interoperability.
	7. RFC Required		7. RFC Required
	Any RFC publication, IETF or a non-IETF Stream.		Any RFC publication, IETF or a non-IETF Stream.
	8. IETF Review		8. IETF Review
	RFC publication, IETF Stream only, but need not be Standards		RFC publication, IETF Stream only, but need not be Standards
	Track.		Track.
	9. Standards Action		9. Standards Action
	RFC publication, IETF Stream, Standards Track only.		RFC publication, IETF Stream, Standards Track or BCP only.
	Examples of situations that might merit IETF Review or Standards		Examples of situations that might merit IETF Review or Standards
	Action include the following:		Action include the following:
	o When a resource is limited, such as bits in a byte (or in two		o When a resource is limited, such as bits in a byte (or in two
	bytes, or four), or numbers in a limited range. In these cases,		bytes, or four), or numbers in a limited range. In these cases,
	allowing registrations that haven't been carefully reviewed and		allowing registrations that haven't been carefully reviewed and
	agreed by community consensus could too quickly deplete the		agreed by community consensus could too quickly deplete the
	allowable values.		allowable values.
	o When thorough community review is necessary to avoid extending or		o When thorough community review is necessary to avoid extending or
	modifying the protocol in ways that could be damaging. One		modifying the protocol in ways that could be damaging. One
	example is in defining new command codes, as opposed to options		example is in defining new command codes, as opposed to options
	that use existing command codes: the former might require a strict		that use existing command codes: the former might require a strict
	policy, where a more relaxed policy could be adequate for the		policy, where a more relaxed policy could be adequate for the
	latter. Another example is in defining protocol elements that		latter. Another example is in defining protocol elements that
	change the semantics of existing operations.		change the semantics of existing operations.
			o When there are security implications with respect to the resource,
			and thorough review is needed to ensure that the new usage is
			sound. Examples of this include lists of acceptable hashing and
			cryptographic algorithms, and assignment of transport ports in the
			system range.
	When reviewing a document that asks IANA to create a new registry or		When reviewing a document that asks IANA to create a new registry or
	change a registration policy to any policy more stringent than Expert		change a registration policy to any policy more stringent than Expert
	Review or Specification Required, the IESG should ask for		Review or Specification Required, the IESG should ask for
	justification to ensure that more relaxed policies have been		justification to ensure that more relaxed policies have been
	considered and that the strict policy is the right one.		considered and that the strict policy is the right one.
	Accordingly, document developers need to anticipate this and document		Accordingly, document developers need to anticipate this and document
	their considerations for selecting the specified policy (ideally, in		their considerations for selecting the specified policy (ideally, in
	the document itself; failing that, in the shepherd writeup).		the document itself; failing that, in the shepherd writeup).
	Likewise, the document shepherd should ensure that the selected		Likewise, the document shepherd should ensure that the selected
	skipping to change at page 27, line 6 ¶		skipping to change at page 27, line 46 ¶
	namespace when it becomes exhausted. "Reserved" is also		namespace when it becomes exhausted. "Reserved" is also
	sometimes used to designate values that had been assigned		sometimes used to designate values that had been assigned
	but are no longer in use, keeping them set aside as long as		but are no longer in use, keeping them set aside as long as
	other unassigned values are available. Note that this is		other unassigned values are available. Note that this is
	distinctly different from "Unassigned".		distinctly different from "Unassigned".
	Reserved values can be released for assignment by the change		Reserved values can be released for assignment by the change
	controller for the registry (this is often the IESG, for		controller for the registry (this is often the IESG, for
	registries created by RFCs in the IETF stream).		registries created by RFCs in the IETF stream).
	7. Documentation References in IANA Registries		Known Unregistered Use: It's known that the assignment or range is
			in use without having been defined in accordance with
			reasonable practice. Documentation for use of the
			assignment or range may be unavailable, inadequate, or
			conflicting. This is a warning against use, as well as an
			alert to network operators, who might see these values in
			use on their networks.
			7. Documentation References in IANA Registries
	Usually, registries and registry entries include references to		Usually, registries and registry entries include references to
	documentation (RFCs or other documents). The purpose of these		documentation (RFCs or other documents). The purpose of these
	references is to provide pointers for implementors to find details		references is to provide pointers for implementors to find details
	necessary for implementation, NOT to simply note what document		necessary for implementation, NOT to simply note what document
	created the registry or entry. Therefore:		created the registry or entry. Therefore:
	o If a document registers an item that is defined and explained		o If a document registers an item that is defined and explained
	elsewhere, the registered reference should be to the document		elsewhere, the registered reference should be to the document
	containing the definition, not to the document that is merely		containing the definition, not to the document that is merely
	performing the registration.		performing the registration.
	skipping to change at page 29, line 41 ¶		skipping to change at page 30, line 34 ¶
	All future RFCs that either explicitly or implicitly rely on IANA to		All future RFCs that either explicitly or implicitly rely on IANA to
	register or otherwise administer namespace assignments must provide		register or otherwise administer namespace assignments must provide
	guidelines for administration of the namespace.		guidelines for administration of the namespace.
	9.3. After-the-Fact Registrations		9.3. After-the-Fact Registrations
	Occasionally, the IETF becomes aware that an unassigned value from a		Occasionally, the IETF becomes aware that an unassigned value from a
	namespace is in use on the Internet or that an assigned value is		namespace is in use on the Internet or that an assigned value is
	being used for a different purpose than it was registered for. The		being used for a different purpose than it was registered for. The
	IETF does not condone such misuse; procedures of the type described		IETF does not condone such misuse; procedures of the type described
	in this document need to be applied to such cases. In the absence of		in this document need to be applied to such cases, and it might not
	specifications to the contrary, values may only be reassigned for a		always be possible to formally assign the desired value. In the
	different purpose with the consent of the original assignee (when		absence of specifications to the contrary, values may only be
	possible) and with due consideration of the impact of such a		reassigned for a different purpose with the consent of the original
	reassignment. In cases of likely controversy, consultation with the		assignee (when possible) and with due consideration of the impact of
	IESG is advised.		such a reassignment. In cases of likely controversy, consultation
			with the IESG is advised.
			This is part of the reason for the advice in Section 3.1 about using
			placeholder values, such as "TBD1", during document development: open
			use of unregistered values after results from well-meant, early
			implementations, where the implementations retained the use of
			developmental code points that never proceeded to a final IANA
			assignment.
	9.4. Reclaiming Assigned Values		9.4. Reclaiming Assigned Values
	Reclaiming previously assigned values for reuse is tricky, because		Reclaiming previously assigned values for reuse is tricky, because
	doing so can lead to interoperability problems with deployed systems		doing so can lead to interoperability problems with deployed systems
	still using the assigned values. Moreover, it can be extremely		still using the assigned values. Moreover, it can be extremely
	difficult to determine the extent of deployment of systems making use		difficult to determine the extent of deployment of systems making use
	of a particular value. However, in cases where the namespace is		of a particular value. However, in cases where the namespace is
	running out of unassigned values and additional ones are needed, it		running out of unassigned values and additional ones are needed, it
	may be desirable to attempt to reclaim unused values. When		may be desirable to attempt to reclaim unused values. When
	reclaiming unused values, the following (at a minimum) should be		reclaiming unused values, the following (at a minimum) should be
	skipping to change at page 30, line 33 ¶		skipping to change at page 31, line 33 ¶
	is not widely used, and the need to reclaim the value outweighs		is not widely used, and the need to reclaim the value outweighs
	the cost of a hostile reclamation. In any case, IESG Approval is		the cost of a hostile reclamation. In any case, IESG Approval is
	needed in this case.		needed in this case.
	o It may be appropriate to write up the proposed action and solicit		o It may be appropriate to write up the proposed action and solicit
	comments from relevant user communities. In some cases, it may be		comments from relevant user communities. In some cases, it may be
	appropriate to write an RFC that goes through a formal IETF		appropriate to write an RFC that goes through a formal IETF
	process (including IETF Last Call) as was done when DHCP reclaimed		process (including IETF Last Call) as was done when DHCP reclaimed
	some of its "Private Use" options [RFC3942].		some of its "Private Use" options [RFC3942].
			o It may be useful to differentiate between revocation, release, and
			transfer. Revocation occurs when IANA removes an assignment,
			release occurs when the assignee initiates that removal, and
			transfer occurs when either revocation or release is coupled with
			immediate reassignment. It may be useful to specify procedures
			for each of these, or to explicitly prohibit combinations that are
			not desired.
	9.5. Contact Person vs Assignee or Owner		9.5. Contact Person vs Assignee or Owner
	Many registries include designation of a technical or administrative		Many registries include designation of a technical or administrative
	contact associated with each entry. Often, this is recorded as		contact associated with each entry. Often, this is recorded as
	contact information for an individual. It is unclear, though, what		contact information for an individual. It is unclear, though, what
	role the individual has with respect to the registration: is this		role the individual has with respect to the registration: is this
	item registered on behalf of the individual, the company the		item registered on behalf of the individual, the company the
	individual worked for, or perhaps another organization the individual		individual worked for, or perhaps another organization the individual
	was acting for?		was acting for?
	This matters because some time later, when the individual has changed		This matters because some time later, when the individual has changed
	jobs or roles, and perhaps can no longer be contacted, someone might		jobs or roles, and perhaps can no longer be contacted, someone might
	want to update the registration. IANA has no way to know what		want to update the registration. IANA has no way to know what
	company, organization, or individual should be allowed to take the		company, organization, or individual should be allowed to take the
	registration over. For registrations rooted in RFCs, the stream		registration over. For registrations rooted in RFCs, the stream
	owner (such as the IESG or the IAB) can make an overriding decision.		owner (such as the IESG or the IAB) can make an overriding decision.
	But in other cases, there is no recourse.		But in other cases, there is no recourse.
	Registries can include, in addition to a "Contact" field, an		Registries can include, in addition to a "Contact" field, an
	"Assignee" or "Owner" field that can be used to address this		"Assignee" or "Owner" field (also referred to as "Change Controller")
	situation, giving IANA clear guidance as to the actual owner of the		that can be used to address this situation, giving IANA clear
	registration. This is strongly advised especially for registries		guidance as to the actual owner of the registration. This is
	that do not require RFCs to manage their information (registries with		strongly advised especially for registries that do not require RFCs
	policies such as First Come First Served Section 4.4, Expert Review		to manage their information (registries with policies such as First
	Section 4.5, and Specification Required Section 4.6). Alternatively,		Come First Served Section 4.4, Expert Review Section 4.5, and
	organizations can put an organizational role into the "Contact" field		Specification Required Section 4.6). Alternatively, organizations
	in order to make their ownership clear.		can put an organizational role into the "Contact" field in order to
			make their ownership clear.
	9.6. Closing or Obsoleting a Registry/Registrations		9.6. Closing or Obsoleting a Registry/Registrations
	Sometimes there is a request to "close" a registry to further		Sometimes there is a request to "close" a registry to further
	registrations. When a registry is closed, no further registrations		registrations. When a registry is closed, no further registrations
	will be accepted. The information in the registry will still be		will be accepted. The information in the registry will still be
	valid and registrations already in the registry can still be updated.		valid and registrations already in the registry can still be updated.
	A closed registry can also be marked as "obsolete", as an indication		A closed registry can also be marked as "obsolete", as an indication
	that the information in the registry is no longer in current use.		that the information in the registry is no longer in current use.
	skipping to change at page 37, line 43 ¶		skipping to change at page 38, line 43 ¶
	[RFC6195] Eastlake, D., "Domain Name System (DNS) IANA		[RFC6195] Eastlake, D., "Domain Name System (DNS) IANA
	Considerations", BCP 42, RFC 6195, March 2011.		Considerations", BCP 42, RFC 6195, March 2011.
	[RFC6275] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support		[RFC6275] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support
	in IPv6", RFC 6275, July 2011.		in IPv6", RFC 6275, July 2011.
	[RFC6709] Carpenter, B., Aboba, B. and S. Cheshire, "Design		[RFC6709] Carpenter, B., Aboba, B. and S. Cheshire, "Design
	Considerations for Protocol Extensions", RFC 6709,		Considerations for Protocol Extensions", RFC 6709,
	September 2012.		September 2012.
			[RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC
			6994, DOI 10.17487/RFC6994, August 2013, <http://www.rfc-
			editor.org/info/rfc6994>.
	[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code		[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
	Points", BCP 100, RFC 7120, January 2014.		Points", BCP 100, RFC 7120, January 2014.
	[RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework:		[RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
	Preparation, Enforcement, and Comparison of		Preparation, Enforcement, and Comparison of
	Internationalized Strings in Application Protocols", RFC		Internationalized Strings in Application Protocols", RFC
	7564, DOI 10.17487/RFC7564, May 2015, <http://www.rfc-		7564, DOI 10.17487/RFC7564, May 2015, <http://www.rfc-
	editor.org/info/rfc7564>.		editor.org/info/rfc7564>.
	[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A. and		[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A. and
End of changes. 22 change blocks.
	65 lines changed or deleted		109 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/