Definitions for Expressing Standards Requirements in IANA Registries

The Internet Engineering Steering Group (IESG) has received a requestto consider the specification "Definitions for Expressing StandardsRequirements in IANA Registries" as a Best Current Practice RFC (BCP).The IESG plans to make a decision in the next few weeks, and solicitsfinal comments on this action; please send substantive comments to theIETF mailing lists by 2010-04-14.
Abstract: "RFC 2119 defines words that are used in IETF standardsdocuments to indicate standards compliance. These words are fine fordefining new protocols, but there are certain deficiencies in usingthem when it comes to protocol maintainability. Protocols are maintainedby either updating the core specifications or via changes in protocolregistries. For example, security functionality in protocols oftenrelies upon cryptographic algorithms that are defined in externaldocuments. Cryptographic algorithms have a limited life span, and newalgorithms regularly phased in to replace older algorithms. This documentproposes standard terms to use in protocol registries and possibly instandards track and informational documents to indicate the life cyclesupport of protocol features and operations.
The proposed requirement words for IANA protocol registries include thefollowing. (1) MANDATORY This is the strongest requirement and for animplementation to ignore it there MUST be a valid and serious reason.(2) DISCRETIONARY, for Implementations: Any implementation MAY or MAYNOT support this entry in the protocol registry. The presence oromission of this MUST NOT be used to judge implementations on standardscompliance (and for) Operations: Any use of this registry entry inoperation is supported, ignoring or rejecting requests using this protocolcomponent MUST NOT be used as bases for asserting lack of compliance.(3) OBSOLETE for Implementations means new implementations SHOULD NOTsupport this functionality, and for Operations, means any use of thisfunctionality in operation MUST be phased out. (4) ENCOURAGED: Thisword is added to the registry entry when new functionality is added andbefore it is safe to rely solely on it. Protocols that have the abilityto negotiate capabilities MAY NOT need this state. (5) DISCOURAGED meansthis requirement is placed on an existing function that is being phasedout. This is similar in spirit to both MUST- and SHOULD- as defined andused in certain RFC's such as RFC 4835. (6) RESERVED: Sometimes thereis a need to reserve certain values to avoid problems such as valuesthat have been used in implementations but were never formally registered.In other cases reserved values are magic numbers that may be used inthe future as escape valves if the number space becomes too small. (7)AVAILABLE is a value that can be allocated by IANA at any time..."
This document is motivated by the experiences of the editors in tryingto maintain registries for DNS and DNSSEC. For example, DNS defines aregistry for hash algorithms used for a message authentication schemecalled TSIG, the first entry in that registry was for HMAC-MD5. TheDNSEXT working group decided to try to decrease the number of algorithmslisted in the registry and add a column to the registry listing therequirements level for each one. Upon reading that HMAC-MD5 was taggedas 'OBSOLETE' a firestorm started. It was interpreted as the DNScommunity making a statement on the status of HMAC-MD5 for all uses.
http://xml.coverpages.org/draft-ogud-iana-protocol-maintenance-words-03.txtSee also 'Using MUST and SHOULD and MAY': http://www.ietf.org/tao.html#anchor42