< draft-ogud-iana-protocol-maintenance-words-02.txt		draft-ogud-iana-protocol-maintenance-words-03.txt >
	General Area O. Gudmundsson		General Area O. Gudmundsson
	Internet-Draft Shinkuro Inc.		Internet-Draft Shinkuro Inc.
	Intended status: Standards Track S. Rose		Updates: 5226 (if approved) S. Rose
	Expires: May 20, 2010 NIST		Intended status: Standards Track NIST
	November 16, 2009		Expires: July 31, 2010 January 27, 2010
	Definitions for expressing standards requirements in IANA registries.		Definitions for expressing standards requirements in IANA registries.
	draft-ogud-iana-protocol-maintenance-words-02		draft-ogud-iana-protocol-maintenance-words-03
			Abstract
			RFC 2119 defines words that are used in IETF standards documents to
			indicate standards compliance. These words are fine for defining new
			protocols, but there are certain deficiencies in using them when it
			comes to protocol maintainability. Protocols are maintained by
			either updating the core specifications or via changes in protocol
			registries.
			For example, security functionality in protocols often relies upon
			cryptographic algorithms that are defined in external documents.
			Cryptographic algorithms have a limited life span, and new algorithms
			regularly phased in to replace older algorithms.
			This document proposes standard terms to use in protocol registries
			and possibly in standards track and informational documents to
			indicate the life cycle support of protocol features and operations.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 33 ¶		skipping to change at page 2, line 5 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on May 20, 2010.		This Internet-Draft will expire on July 31, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 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 in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	RFC 2119 defines words that are used in IETF standards documents to		described in the BSD License.
	indicate standards compliance. These words are fine for defining new
	protocols, but there are certain deficiencies in using them when it
	comes to protocol maintainability. Protocols are maintained by
	either updating the core specifications or via changes in protocol
	registries.
	For example, protocols often use external algorithms to to provide
	security functionality such as cryptography. Cryptographic
	algorithms frequently have limited life cycles as new algorithms are
	phased in to replace older algorithms.
	This document proposes standard terms to use in protocol registries
	and possibly in standards track documents to indicate the life cycle
	support of protocol features and operations.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Implementation vs. Operations requirements . . . . . . . . 3		1.1. Implementation vs. Operations requirements . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Proposed requirement words for IANA protocol registries . . . . 4		3. Proposed requirement words for IANA protocol registries . . . . 5
	3.1. MANDATORY . . . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. MANDATORY . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.2. OPTIONAL . . . . . . . . . . . . . . . . . . . . . . . . . 4		3.2. DISCRETIONARY . . . . . . . . . . . . . . . . . . . . . . . 5
	3.3. OBSOLETE . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.3. OBSOLETE . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.4. ENCOURAGED . . . . . . . . . . . . . . . . . . . . . . . . 5		3.4. ENCOURAGED . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.5. DISCOURAGED . . . . . . . . . . . . . . . . . . . . . . . . 5		3.5. DISCOURAGED . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.6. RESERVED . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.6. RESERVED . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.7. AVAILABLE . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.7. AVAILABLE . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4. Protocol Registry Maintenance . . . . . . . . . . . . . . . . . 6		4. Protocol Registry Maintenance . . . . . . . . . . . . . . . . . 7
	5. Example registry . . . . . . . . . . . . . . . . . . . . . . . 7		5. Example registry . . . . . . . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
	7. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 8		7. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 9
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 8		8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	8.2. Informative References . . . . . . . . . . . . . . . . . . 8		8.2. Informative References . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	The RFC series have been the main way to define Internet protocols		The RFC series have been the main way to define Internet protocols
	and publish lists of related protocol parameters. RFC 3232 [RFC3232]		and publish lists of related protocol parameters. RFC 3232 [RFC3232]
	replaced the original document centered process with on-line protocol		replaced the original document centered process with on-line protocol
	registries maintained by IANA. In many cases these registries are		registries maintained by IANA. In many cases these registries are
	"write-once" i.e. new things are added; in other cases the		"write-once" i.e. new things are added; in other cases the
	requirements of a protocol implementation changes over time. This		requirements of a protocol implementation changes over time. This
	document is aimed at the second case.		document is aimed at the second case.
	skipping to change at page 3, line 29 ¶		skipping to change at page 4, line 29 ¶
	registry was for HMAC-MD5. The DNSEXT working group decided to try		registry was for HMAC-MD5. The DNSEXT working group decided to try
	to decrease the number of algorithms listed in the registry and add a		to decrease the number of algorithms listed in the registry and add a
	column to the registry listing the requirements level for each one.		column to the registry listing the requirements level for each one.
	Upon reading that HMAC-MD5 was tagged as "OBSOLETE" a firestorm		Upon reading that HMAC-MD5 was tagged as "OBSOLETE" a firestorm
	started. It was interpreted as the DNS community making a statement		started. It was interpreted as the DNS community making a statement
	on the status of HMAC-MD5 for all uses. While the document was		on the status of HMAC-MD5 for all uses. While the document was
	definitely overreaching in its specification, the point remained		definitely overreaching in its specification, the point remained
	there was no standard way to tag different requirements levels in		there was no standard way to tag different requirements levels in
	protocol registries.		protocol registries.
	In the crypto community there has been some attempts to indicate		In the security community there has been some attempts to indicate
	emerging and retiring algorithms by adding + or - to RFC 2119 words		emerging and retiring algorithms by adding + or - to RFC 2119 words
	RFC 4835 [RFC4835], SHOULD+ is to be interpreted as "SHOULD for now,		RFC 4835 [RFC4835], SHOULD+ is to be interpreted as "SHOULD for now,
	expected to be MUST soon". MUST- indicates that the currently		expected to be MUST soon". MUST- indicates that the currently
	required algorithm or feature might be retired sometime in the near		required algorithm or feature might be retired sometime in the near
	future. This has traditionally been accomplished by adding a		future. This has traditionally been accomplished by adding a
	terminology section to each document. A now expired draft		terminology section to each document. A now expired draft
	(draft-hoffman-additional-key-words) attempted to establish these		(draft-hoffman-additional-key-words) attempted to establish these
	additions as new keywords but was never fully adopted. This document		additions as new keywords but was never fully adopted. This document
	attempts to revive this effort. This document adds to and updates		attempts to revive this effort. This document adds to and updates
	the labels defined in RFC 5226 [RFC5226] as well.		the labels defined in RFC 5226 [RFC5226] as well.
	skipping to change at page 4, line 28 ¶		skipping to change at page 5, line 28 ¶
	provide for each functionality.		provide for each functionality.
	3.1. MANDATORY		3.1. MANDATORY
	This is the strongest requirement and for an implementation to ignore		This is the strongest requirement and for an implementation to ignore
	it there MUST be a valid and serious reason.		it there MUST be a valid and serious reason.
	Implementations: To be considered compliant, all implementations		Implementations: To be considered compliant, all implementations
	MUST support this registry entry.		MUST support this registry entry.
	Operations: To be considered compliant, operations MUST use at least		Operations: To be considered compliant, operations MUST use at least
	one of the mandatory entries and SHOULD be able to use all of the		one of the mandatory entries.
	MANDATORY entries.
	Note 1: There can be more than one MANDATORY requirement.		Note 1: There can be more than one MANDATORY requirement.
	Note 2: The requirement applies only to new or future		Note 2: The requirement applies only to new or future
	implementations on the day the requirement is released. In many		implementations on the day the requirement is released. In many
	cases existing implementations can become compliant via software		cases existing implementations can become compliant via software
	upgrade or point release.		upgrade or point release.
	3.2. OPTIONAL		3.2. DISCRETIONARY
	Implementations: Any implementation MAY or MAY NOT support this		Implementations: Any implementation MAY or MAY NOT support this
	entry in the protocol registry. The presence or omission of this		entry in the protocol registry. The presence or omission of this
	MUST NOT be used to judge implementations on standards compliance.		MUST NOT be used to judge implementations on standards compliance.
	Operations: Any use of this registry entry in operation is		Operations: Any use of this registry entry in operation is
	supported, ignoring or rejecting requests using this protocol		supported, ignoring or rejecting requests using this protocol
	component MUST NOT be used as bases for asserting lack of		component MUST NOT be used as bases for asserting lack of
	compliance.		compliance.
	Note 1: Optional is taken to mean that the given functionality MAY		Note 1: Discretionary is taken to mean that the given functionality
	or MAY NOT be supported by an implementation or a given operation		MAY or MAY NOT be supported by an implementation or a given
	MAY or MAY NOT be used.		operation MAY or MAY NOT be used.
	3.3. OBSOLETE		3.3. OBSOLETE
	Implementations: New implementations SHOULD NOT support this		Implementations: New implementations SHOULD NOT support this
	functionality.		functionality.
	Operations: Any use of this functionality in operation MUST be		Operations: Any use of this functionality in operation MUST be
	phased out.		phased out.
	Note: This is the most dangerous term of the requirements words as		Note: This is the most dangerous term of the requirements words as
	it is easy to read too much into this term. The intent is to		it is easy to read too much into this term. The intent is to
	express the following:		express the following:
	* This functionality is not needed/desired anymore by the given		* This functionality is not needed/desired anymore by the given
	protocol. This is not to say that this particular		protocol. This is not to say that this particular
	functionality should be obsoleted by other protocols that use		functionality should be obsoleted by other protocols that use
	the same (or similar) functionality.		the same (or similar) functionality.
	3.4. ENCOURAGED		3.4. ENCOURAGED
	This word is added to the registry entry when new functionality is		This word is added to the registry entry when new functionality is
	added and before it is safe to rely solely on it. Protocols that		added and before it is safe to rely solely on it. Protocols that
	have the ability to negotiate capabilities MAY NOT need this state.		have the ability to negotiate capabilities MAY NOT need this state.
			This is similar in spirit to the use of SHOULD+ as defined in certain
			RFC's (such as RFC 4835 [RFC4835])
	Implementations: This functionality SHOULD be supported by		Implementations: This functionality SHOULD be supported by
	implementations.		implementations.
	Operations: This functionality SHOULD NOT be immediately deployed as		Operations: This functionality SHOULD NOT be immediately deployed as
	part of normal operations. This functionality SHOULD be tested in		part of normal operations. This functionality SHOULD be tested in
	a controlled environment to measure the quality and readiness of		a controlled environment to measure the quality and readiness of
	the functionality and gain operationally experience. Operators		the functionality and gain operational experience. Operators can
	can expect functionality marked ENCOURAGED to become MANDATORY at		expect functionality marked ENCOURAGED to become MANDATORY at some
	some point in the future unless a significant problem is		point in the future unless a significant problem is encountered
	encountered during early deployments.		during early deployments.
	Note1: In broadcast protocols like BGP and DNS there is no way for		Note1: In broadcast protocols like BGP and DNS there is no way for
	an originator of a message to know the capabilities of all		an originator of a message to know the capabilities of all
	recipients. In these cases the requirement for support ought to		recipients. In these cases the requirement for support ought to
	be placed on implementations before the functionality is used in		be placed on implementations before the functionality is used in
	operations to guarantee maximum acceptance of the messages.		operations to guarantee maximum acceptance of the messages.
	Note2: In some cases this requires having both "new" and "old"		Note2: In some cases this requires having both "new" and "old"
	algorithms in use at the same time. In this case the new		algorithms in use at the same time. In this case the new
	functionality can be used before a high percentage of deployment		functionality can be used before a high percentage of deployment
	of the new functionality has taken place.		of the new functionality has taken place.
	Note3: In protocols that negotiate which functionality to use, there		Note3: In protocols that negotiate which functionality to use, there
	is no reason to place different requirement on operations other		is no reason to place different requirement on operations other
	than list of accepted functionality SHOULD contain at least one		than list of accepted functionality SHOULD contain at least one
	MANDATORY functionality.		MANDATORY functionality.
	3.5. DISCOURAGED		3.5. DISCOURAGED
	This requirement is placed on an existing function that is being		This requirement is placed on an existing function that is being
	phased out.		phased out. This is similar in spirit to both MUST- and SHOULD- as
			defined and used in certain RFC's such as RFC 4835 [RFC4835]
	Implementations: Implementations MUST support this functionality,		Implementations: Implementations SHOULD support this functionality,
	and SHOULD provide features to migrate to a MANDATORY		and SHOULD provide features to migrate to a MANDATORY
	functionality. The use of this functionality SHOULD NOT be used		functionality. The use of this functionality SHOULD NOT be used
	as default behavior.		as default behavior.
	Operations: Operations SHOULD phase out any use of this		Operations: Operations SHOULD phase out any use of this
	functionality.		functionality.
	Note: This is the strongest signal to the community that this		Note: This is the strongest signal to the community that this
	functionality is no longer considered best practice. Some time		functionality is no longer considered best practice. Some time
	after the functionality enters this state, it will migrate to		after the functionality enters this state, it will migrate to
	OBSOLETE.		OBSOLETE.
	skipping to change at page 7, line 16 ¶		skipping to change at page 8, line 16 ¶
	value is to become "MANDATORY".		value is to become "MANDATORY".
	or Value X in registry Y is "DISCOURAGED". On June 1st 2020 this		or Value X in registry Y is "DISCOURAGED". On June 1st 2020 this
	value is to become "OBSOLETE".		value is to become "OBSOLETE".
	or Value X in registry Y is "RESERVED" until June 1st 2020 when this		or Value X in registry Y is "RESERVED" until June 1st 2020 when this
	value becomes "AVAILABLE".		value becomes "AVAILABLE".
	5. Example registry		5. Example registry
	This is an example registry for protocol FOO that uses encrypted		This is an example registry for an example protocol FOO that uses an
	channel for messages. The algorithms listed here are only for		encrypted channel for messages. The algorithms listed here are only
	illustration uses.		for illustration uses.
	FOO		FOO
	+--------+--------------------+-----------------+-------------------+		+--------+-------------+-------------------------+------------------+
	| Value | Algorithm name | Requirment | References |		| Value | Algorithm | Requirement | References |
	+--------+--------------------+-----------------+-------------------+		| | name | | |
	| 0 | | Reserved | RFCfoo |		+--------+-------------+-------------------------+------------------+
	| 1 | Rotating 13 chars | OBSOLETE | RFCfoo, RFCrot13 |		| 0 | | RESERVED | RFCFOO |
	| | cypher | | |		| 1 | ROT-13 | OBSOLETE | RFCFOO, RFCrot13 |
	| 2 | Data Encryption | DISCOURAGED | RFCfoo, RFCdes |		| 2 | DES | DISCOURAGED | RFCFOO, RFCdes |
	| | Standard | | |		| 3 | BlowFish | MANDATORY | RFCblowfish, |
	| 3 | BlowFish | MANDATORY | RFCblowfish, |		| | | | RFCrot13 |
	| | | | RFCrot13 |		| 4 | | RESERVED until 2022 | RFCrot13 |
	| 4 | | RESERVED until | RFCrot13 |		| 5 | AES | Encouraged | RFCFOOaes |
	| | | 2022 | |		| 6 | Enigma | DISCOURAGED, OBSOLETE | RFCFOO, |
	| 5 | AES | Encouraged | RFCfooaes |		| | | in Jan 2012 | RFC-Enigma |
	| 6 - | | Available | RFCfoo |		| 7 - | | Available | RFCFOO |
	| 255 | | | |		| 255 | | | |
	+--------+--------------------+-----------------+-------------------+		+--------+-------------+-------------------------+------------------+
	Allocation policy any RFC published on April 1'st.		Allocation policy for FOO: any RFC published on April 1'st.
	Table 1		Table 1
	6. Security Considerations		6. Security Considerations
	This document specifies a set of terms to indicate the status of		This document specifies a set of terms to indicate the status of
	features in protocol implementations and operations. It is not meant		features in protocol implementations and operations. It is not meant
	to be a discussion on feature or operation superiority or provide a		to be a discussion on feature or operation superiority or provide a
	means to measure the usefulness of a feature. It is hoped that by		means to measure the usefulness of a feature. It is hoped that by
	extending the RFC 2119 words to be more applicable for protocol		extending the RFC 2119 words to be more applicable for protocol
	maintenance, the overall security of the Internet is improved.		maintenance, the overall security of the Internet is improved.
	7. IANA considerations		7. IANA considerations
	This document does not require any IANA actions.
	This document does set rules for registrations of compliance		This document does set rules for registrations of compliance
	requirements in IANA registries.		requirements in IANA registries.
			This document places requirement that IANA be able to update
			registires on specific dates. As none of these action is time
			critical, IANA can perform the actions within a 2 week window of the
			action specified. Any action saying "Month year" should be
			interpreded to be applicable on the 15'th of the month, similarly any
			action say only the year is applicable on June 30'th that year.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4835] Manral, V., "Cryptographic Algorithm Implementation		[RFC4835] Manral, V., "Cryptographic Algorithm Implementation
	Requirements for Encapsulating Security Payload (ESP) and		Requirements for Encapsulating Security Payload (ESP) and
	Authentication Header (AH)", RFC 4835, April 2007.		Authentication Header (AH)", RFC 4835, April 2007.
End of changes. 19 change blocks.
	83 lines changed or deleted		93 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/