idnits 2.17.1 draft-ogud-iana-protocol-maintenance-words-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5226, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Implementations: Any implementation MAY or MAY NOT support this entry in the protocol registry. The presence or omission of this MUST NOT be used to judge implementations on standards compliance. Operations: Any use of this registry entry in operation is supported, ignoring or rejecting requests using this protocol component MUST NOT be used as bases for asserting lack of compliance. Note 1: Discretionary is taken to mean that the given functionality MAY or MAY NOT be supported by an implementation or a given operation MAY or MAY NOT be used. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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 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. Operations: This functionality SHOULD NOT be immediately deployed as part of normal operations. This functionality SHOULD be tested in a controlled environment to measure the quality and readiness of the functionality and gain operational experience. Operators can expect functionality marked ENCOURAGED to become MANDATORY at some point in the future unless a significant problem is encountered during early deployments. Note1: In broadcast protocols like BGP and DNS there is no way for an originator of a message to know the capabilities of all recipients. In these cases the requirement for support ought to be placed on implementations before the functionality is used in operations to guarantee maximum acceptance of the messages. Note2: In some cases this requires having both "new" and "old" algorithms in use at the same time. In this case the new functionality can be used before a high percentage of deployment of the new functionality has taken place. Note3: In protocols that negotiate which functionality to use, there is no reason to place different requirement on operations other than list of accepted functionality SHOULD contain at least one MANDATORY functionality. (Using the creation date from RFC5226, updated by this document, for RFC5378 checks: 2004-08-09) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 27, 2010) is 5203 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4835 (Obsoleted by RFC 7321) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 General Area O. Gudmundsson 3 Internet-Draft Shinkuro Inc. 4 Updates: 5226 (if approved) S. Rose 5 Intended status: Standards Track NIST 6 Expires: July 31, 2010 January 27, 2010 8 Definitions for expressing standards requirements in IANA registries. 9 draft-ogud-iana-protocol-maintenance-words-03 11 Abstract 13 RFC 2119 defines words that are used in IETF standards documents to 14 indicate standards compliance. These words are fine for defining new 15 protocols, but there are certain deficiencies in using them when it 16 comes to protocol maintainability. Protocols are maintained by 17 either updating the core specifications or via changes in protocol 18 registries. 20 For example, security functionality in protocols often relies upon 21 cryptographic algorithms that are defined in external documents. 22 Cryptographic algorithms have a limited life span, and new algorithms 23 regularly phased in to replace older algorithms. 25 This document proposes standard terms to use in protocol registries 26 and possibly in standards track and informational documents to 27 indicate the life cycle support of protocol features and operations. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on July 31, 2010. 52 Copyright Notice 54 Copyright (c) 2010 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.1. Implementation vs. Operations requirements . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3. Proposed requirement words for IANA protocol registries . . . . 5 73 3.1. MANDATORY . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.2. DISCRETIONARY . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.3. OBSOLETE . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 3.4. ENCOURAGED . . . . . . . . . . . . . . . . . . . . . . . . 6 77 3.5. DISCOURAGED . . . . . . . . . . . . . . . . . . . . . . . . 6 78 3.6. RESERVED . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 3.7. AVAILABLE . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 4. Protocol Registry Maintenance . . . . . . . . . . . . . . . . . 7 81 5. Example registry . . . . . . . . . . . . . . . . . . . . . . . 8 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 83 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 9 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 86 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 89 1. Introduction 91 The RFC series have been the main way to define Internet protocols 92 and publish lists of related protocol parameters. RFC 3232 [RFC3232] 93 replaced the original document centered process with on-line protocol 94 registries maintained by IANA. In many cases these registries are 95 "write-once" i.e. new things are added; in other cases the 96 requirements of a protocol implementation changes over time. This 97 document is aimed at the second case. 99 This document is motivated by the experiences of the editors in 100 trying to maintain registries for DNS and DNSSEC. For example, DNS 101 defines a registry for hash algorithms used for a message 102 authentication scheme called TSIG [RFC2845], the first entry in that 103 registry was for HMAC-MD5. The DNSEXT working group decided to try 104 to decrease the number of algorithms listed in the registry and add a 105 column to the registry listing the requirements level for each one. 106 Upon reading that HMAC-MD5 was tagged as "OBSOLETE" a firestorm 107 started. It was interpreted as the DNS community making a statement 108 on the status of HMAC-MD5 for all uses. While the document was 109 definitely overreaching in its specification, the point remained 110 there was no standard way to tag different requirements levels in 111 protocol registries. 113 In the security community there has been some attempts to indicate 114 emerging and retiring algorithms by adding + or - to RFC 2119 words 115 RFC 4835 [RFC4835], SHOULD+ is to be interpreted as "SHOULD for now, 116 expected to be MUST soon". MUST- indicates that the currently 117 required algorithm or feature might be retired sometime in the near 118 future. This has traditionally been accomplished by adding a 119 terminology section to each document. A now expired draft 120 (draft-hoffman-additional-key-words) attempted to establish these 121 additions as new keywords but was never fully adopted. This document 122 attempts to revive this effort. This document adds to and updates 123 the labels defined in RFC 5226 [RFC5226] as well. 125 In this document when we say "registry" we mean both "IANA registry" 126 and RFC's specifying (or updating) a protocol and its parameters. 128 1.1. Implementation vs. Operations requirements 130 It is common that before a new technology is considered "useful" it 131 has to gain widespread deployment. Thus it makes sense to have 132 different levels of RFC 2119 words requirement on implementations 133 than on operations. 135 In a world of protocol maintenance when something is being 'retired' 136 it is nice if operations can easily migrate to a newer functionality. 138 This document includes certain extra requirements on implementations 139 during the phase-out of a functionality. 141 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are 145 to be interpreted as described in RFC 2119 [RFC2119]. 147 3. Proposed requirement words for IANA protocol registries 149 The words below are expected to be in a separate column in the 150 Registries indicating what support implementations are expected to 151 provide for each functionality. 153 3.1. MANDATORY 155 This is the strongest requirement and for an implementation to ignore 156 it there MUST be a valid and serious reason. 158 Implementations: To be considered compliant, all implementations 159 MUST support this registry entry. 160 Operations: To be considered compliant, operations MUST use at least 161 one of the mandatory entries. 162 Note 1: There can be more than one MANDATORY requirement. 163 Note 2: The requirement applies only to new or future 164 implementations on the day the requirement is released. In many 165 cases existing implementations can become compliant via software 166 upgrade or point release. 168 3.2. DISCRETIONARY 170 Implementations: Any implementation MAY or MAY NOT support this 171 entry in the protocol registry. The presence or omission of this 172 MUST NOT be used to judge implementations on standards compliance. 173 Operations: Any use of this registry entry in operation is 174 supported, ignoring or rejecting requests using this protocol 175 component MUST NOT be used as bases for asserting lack of 176 compliance. 177 Note 1: Discretionary is taken to mean that the given functionality 178 MAY or MAY NOT be supported by an implementation or a given 179 operation MAY or MAY NOT be used. 181 3.3. OBSOLETE 183 Implementations: New implementations SHOULD NOT support this 184 functionality. 185 Operations: Any use of this functionality in operation MUST be 186 phased out. 187 Note: This is the most dangerous term of the requirements words as 188 it is easy to read too much into this term. The intent is to 189 express the following: 190 * This functionality is not needed/desired anymore by the given 191 protocol. This is not to say that this particular 192 functionality should be obsoleted by other protocols that use 193 the same (or similar) functionality. 195 3.4. ENCOURAGED 197 This word is added to the registry entry when new functionality is 198 added and before it is safe to rely solely on it. Protocols that 199 have the ability to negotiate capabilities MAY NOT need this state. 200 This is similar in spirit to the use of SHOULD+ as defined in certain 201 RFC's (such as RFC 4835 [RFC4835]) 202 Implementations: This functionality SHOULD be supported by 203 implementations. 204 Operations: This functionality SHOULD NOT be immediately deployed as 205 part of normal operations. This functionality SHOULD be tested in 206 a controlled environment to measure the quality and readiness of 207 the functionality and gain operational experience. Operators can 208 expect functionality marked ENCOURAGED to become MANDATORY at some 209 point in the future unless a significant problem is encountered 210 during early deployments. 211 Note1: In broadcast protocols like BGP and DNS there is no way for 212 an originator of a message to know the capabilities of all 213 recipients. In these cases the requirement for support ought to 214 be placed on implementations before the functionality is used in 215 operations to guarantee maximum acceptance of the messages. 216 Note2: In some cases this requires having both "new" and "old" 217 algorithms in use at the same time. In this case the new 218 functionality can be used before a high percentage of deployment 219 of the new functionality has taken place. 220 Note3: In protocols that negotiate which functionality to use, there 221 is no reason to place different requirement on operations other 222 than list of accepted functionality SHOULD contain at least one 223 MANDATORY functionality. 225 3.5. DISCOURAGED 227 This requirement is placed on an existing function that is being 228 phased out. This is similar in spirit to both MUST- and SHOULD- as 229 defined and used in certain RFC's such as RFC 4835 [RFC4835] 231 Implementations: Implementations SHOULD support this functionality, 232 and SHOULD provide features to migrate to a MANDATORY 233 functionality. The use of this functionality SHOULD NOT be used 234 as default behavior. 235 Operations: Operations SHOULD phase out any use of this 236 functionality. 237 Note: This is the strongest signal to the community that this 238 functionality is no longer considered best practice. Some time 239 after the functionality enters this state, it will migrate to 240 OBSOLETE. 242 3.6. RESERVED 244 Sometimes there is a need to reserve certain values to avoid problems 245 such as values that have been used in implementations but were never 246 formally registered. In other cases reserved values are magic 247 numbers that may be used in the future as escape valves if the number 248 space becomes too small. 249 Implementations: Implementations MUST NOT use any RESERVED values 250 for implementation specific processing. 251 Operations: MUST NOT be used, any implementation in use that uses 252 this code SHOULD be upgraded/retired. 254 3.7. AVAILABLE 256 This is a value that can be allocated by IANA at any time. 257 Implementations: Implementations SHOULD NOT use these values for 258 implementation specific processing. 259 Operations: Any implementation claiming to know the meaning of this 260 unallocated code MUST NOT be used. 262 4. Protocol Registry Maintenance 264 In theory the process to change the status of a protocol field should 265 be the same as reserving a new field. In practice this is going to 266 be burdensome, as there is a chance the IESG will have to process 267 many documents that are simply saying "Value X in Registry Y is now 268 Mandatory" (or similar). 270 For this reason we propose that it be possible to make reservations 271 and have a change in that reservation to take place at a defined date 272 in the future. This is a change to the static labels defined in 273 Section 4 of [RFC5226] to include a defined lifetime for certain 274 registry entries. For example, a document could say: 276 Value X in registry Y is "ENCOURAGED". On June 1st 2020 this 277 value is to become "MANDATORY". 279 or Value X in registry Y is "DISCOURAGED". On June 1st 2020 this 280 value is to become "OBSOLETE". 282 or Value X in registry Y is "RESERVED" until June 1st 2020 when this 283 value becomes "AVAILABLE". 285 5. Example registry 287 This is an example registry for an example protocol FOO that uses an 288 encrypted channel for messages. The algorithms listed here are only 289 for illustration uses. 291 FOO 293 +--------+-------------+-------------------------+------------------+ 294 | Value | Algorithm | Requirement | References | 295 | | name | | | 296 +--------+-------------+-------------------------+------------------+ 297 | 0 | | RESERVED | RFCFOO | 298 | 1 | ROT-13 | OBSOLETE | RFCFOO, RFCrot13 | 299 | 2 | DES | DISCOURAGED | RFCFOO, RFCdes | 300 | 3 | BlowFish | MANDATORY | RFCblowfish, | 301 | | | | RFCrot13 | 302 | 4 | | RESERVED until 2022 | RFCrot13 | 303 | 5 | AES | Encouraged | RFCFOOaes | 304 | 6 | Enigma | DISCOURAGED, OBSOLETE | RFCFOO, | 305 | | | in Jan 2012 | RFC-Enigma | 306 | 7 - | | Available | RFCFOO | 307 | 255 | | | | 308 +--------+-------------+-------------------------+------------------+ 310 Allocation policy for FOO: any RFC published on April 1'st. 312 Table 1 314 6. Security Considerations 316 This document specifies a set of terms to indicate the status of 317 features in protocol implementations and operations. It is not meant 318 to be a discussion on feature or operation superiority or provide a 319 means to measure the usefulness of a feature. It is hoped that by 320 extending the RFC 2119 words to be more applicable for protocol 321 maintenance, the overall security of the Internet is improved. 323 7. IANA considerations 325 This document does set rules for registrations of compliance 326 requirements in IANA registries. 328 This document places requirement that IANA be able to update 329 registires on specific dates. As none of these action is time 330 critical, IANA can perform the actions within a 2 week window of the 331 action specified. Any action saying "Month year" should be 332 interpreded to be applicable on the 15'th of the month, similarly any 333 action say only the year is applicable on June 30'th that year. 335 8. References 337 8.1. Normative References 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, March 1997. 342 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 343 Requirements for Encapsulating Security Payload (ESP) and 344 Authentication Header (AH)", RFC 4835, April 2007. 346 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 347 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 348 May 2008. 350 8.2. Informative References 352 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 353 Wellington, "Secret Key Transaction Authentication for DNS 354 (TSIG)", RFC 2845, May 2000. 356 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 357 an On-line Database", RFC 3232, January 2002. 359 Authors' Addresses 361 Olafur Gudmundsson 362 Shinkuro Inc. 363 4922 Fairmont Avenue, Suite 250 364 Bethesda, MD 20814 365 USA 367 Email: ogud@ogud.com 368 Scott Rose 369 NIST 370 100 Bureau Dr. 371 Gaithersburg, MD 20899 372 USA 374 Phone: +1-301-975-8439 375 Email: scottr.nist@gmail.com