idnits 2.17.1 draft-iesg-iana-considerations-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 130 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (May 21, 1998) is 9471 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) == Missing Reference: 'DHCP' is mentioned on line 255, but not defined == Unused Reference: 'DHCP-OPTIONS' is defined on line 394, but no explicit reference was found in the text == Unused Reference: 'MIME-LANG' is defined on line 412, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (ref. 'ASSIGNED') (Obsoleted by RFC 3232) -- Unexpected draft version: The latest known version of draft-ietf-idr-bgp4-multiprotocol is -01, but you're referring to -02. -- No information found for - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IANA-CONSIDERATIONS' ** Obsolete normative reference: RFC 1825 (ref. 'IPSEC') (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 2184 (ref. 'MIME-LANG') (Obsoleted by RFC 2231) ** Obsolete normative reference: RFC 2048 (ref. 'MIME-REG') (Obsoleted by RFC 4288, RFC 4289) == Outdated reference: A later version (-04) exists of draft-ietf-ion-scsp-02 ** Obsolete normative reference: RFC 1869 (ref. 'SMTP-EXT') (Obsoleted by RFC 2821) Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Thomas Narten 2 IBM 3 Harald Tveit Alvestrand 4 UNINETT 5 May 21, 1998 7 Guidelines for Writing an IANA Considerations Section in RFCs | 9 | 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 Distribution of this memo is unlimited. 32 This Internet Draft expires November, 1998. | 34 Abstract 36 Many protocols make use of identifiers consisting of constants and 37 other well-known values. Even after a protocol has been defined and 38 deployment has begun, new values may need to be assigned (e.g., for a | 39 new option type in DHCP, or a new encryption or authentication | 40 algorithm for IPSec). To insure that such quantities have consistent | 41 values and interpretations in different implementations, their | 42 assignment must be administered by a central authority. For IETF | 43 protocols, that role is provided by the Internet Assigned Numbers | 44 Authority (IANA). 46 In order for the IANA to manage a given numbering space prudently, it 47 needs guidelines describing the conditions under which new values can 48 be assigned. If the IANA is expected to play a role in the management 49 of a numbering space, the IANA must be given clear and concise 50 instructions describing that role. This document discusses issues 51 that should be considered in formulating an identifier assignment 52 policy and provides guidelines to document authors on the specific 53 text that must be included in documents that place demands on the 54 IANA. 56 Contents 58 Status of this Memo.......................................... 1 | 60 1. Introduction............................................. 3 | 62 2. Issues To Consider....................................... 4 | 64 3. Registration maintenance................................. 7 | 66 4. What To Put In Documents................................. 8 | 68 5. Applicability to Past and Future RFCs.................... 9 | 70 6. Security Considerations.................................. 9 | 72 7. Acknowledgements......................................... 9 | 74 8. References............................................... 10 | 76 9. Authors' Addresses....................................... 11 | 78 1. Introduction 80 Many protocols make use of fields that contain constants and other 81 well-known values (e.g., the Protocol field in the IP header [IP] or | 82 MIME types in mail messages [MIME-REG]). Even after a protocol has | 83 been defined and deployment has begun, new values may need to be | 84 assigned (e.g., a new option type in DHCP [DHCP] or a new encryption | 85 or authentication algorithm for IPSec [IPSEC]). To insure that such | 86 fields have consistent values and interpretations in different | 87 implementations, their assignment must be administered by a central | 88 authority. For IETF protocols, that role is provided by the Internet | 89 Assigned Numbers Authority (IANA). 91 In order for the IANA to manage a given numbering space prudently, it 92 needs guidelines describing the conditions under which new values 93 should be assigned. This document provides guidelines to authors on 94 what sort of text should be added to their documents, and reviews 95 issues that should be considered in formulating an appropriate policy 96 for assigning identifiers. 98 Not all name spaces require centralized administration. In some 99 cases, it is possible to delegate a name space in such a way that 100 further assignments can be made independently and with no further 101 (central) coordination. In the Domain Name System, for example, the 102 IANA only deals with assignments at the higher-levels, while 103 subdomains are administered by the organization to which the space 104 has been delegated. As another example, Object Identifiers (OIDs) as 105 defined by the ITU are also delegated [ASSIGNED]. When a name space 106 can be delegated, the IANA only deals with assignments at the top 107 level. 109 This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their 110 negatives, in the way described in RFC 2119 [KEYWORDS]. In this case, 111 "the specification" as used by RFC 2119 refers to the processing of 112 protocols being submitted to the IETF standards process. 114 2. Issues To Consider 116 The primary issue to consider in managing a numbering space is its 117 size. If the space is small and limited in size, assignments must be 118 made carefully to insure that the space doesn't become exhausted. If 119 the space is essentially unlimited, on the other hand, it may be 120 perfectly reasonable to hand out new values to anyone that wants one. 121 Even when the space is essentially unlimited, however, it is usually 122 desirable to have a minimal review to prevent hoarding of the space. 123 For example, if the space consists of text strings, it may be 124 desirable to prevent organizations from obtaining large sets of 125 strings that correspond to the "best" names (e.g., existing company 126 names). 128 A second consideration is whether it makes sense to delegate the name 129 space in some manner. This route should be pursued when appropriate, 130 as it lessens the burden on the IANA for dealing with assignments. 132 In some cases, the name space is essentially unlimited, and | 133 identifiers can safely be given out to anyone. When no subjective | 134 review is needed, the IANA can make assignments directly, provided | 135 that the IANA is given specific instructions on what types of | 136 requests it should grant, and what information must be provided | 137 before a request for an assigned number will be considered. Note that | 138 the IANA will not define an assignment policy; it should be given a | 139 set of guidelines that allow it to make allocation decisions with | 140 little subjectivity. | 142 In most cases, some review of prospective allocations is appropriate, | 143 and the question becomes who should perform the review and how | 144 rigorous the review needs to be. In many cases, one might think that | 145 an IETF Working Group (WG) familiar with the identifier space at hand | 146 should be consulted. In practice, however, WGs eventually disband, so | 147 they cannot be considered a permanent evaluator. It is also possible | 148 for identifier spaces to be created through individual submission | 149 documents, for which no WG is ever formed. | 151 The standard way to insure community review of prospective | 152 assignments is to have the requestor submit a document for | 153 publication as an RFC. Such an action insures that the IESG and | 154 relevant WGs review the assignment. This is the prefered way of | 155 insuring review, and is particularly important if any potential | 156 interoperability issues can arise. For example, many assignments are | 157 not just assignments, but also involve an element of protocol | 158 specification. A new option may define fields that need to be parsed | 159 and acted on, which (if specified poorly) may not fit cleanly with | 160 the architecture of other options or the base protocols on which they | 161 are built. | 163 In some cases, however, the burden of publishing an RFC in order to | 164 get an assignment is excessive. However, it is generally still useful | 165 (and sometimes necessary) to discuss proposed additions on a mailing | 166 list dedicated to the purpose (e.g., the ietf-types@iana.org for | 167 media types) or on a more general mailing list (e.g., that of a | 168 current or former IETF WG). Such a mailing list provides a way for | 169 new registrations to be publically reviewed prior to getting | 170 assigned, or to give advice for persons who want help in | 171 understanding what a proper registration should contain. | 173 Since the IANA cannot participate in all of these mailing lists and | 174 cannot determine if or when discussions on such lists reach a | 175 consensus, the IANA can make use of "Designated Expert" to advise it | 176 in assignment matters. That is, the IANA forwards the requests it | 177 receives to a specific point-of-contact (one or a small number of | 178 individuals) and acts upon the returned recommendation from the | 179 Designated Expert. In all cases, it is the Designated Expert that the | 180 IANA relies on for an authoritative response. In those cases where | 181 wide review of a request is needed, it is the responsibility of the | 182 Designated Expert to initiate such a review (e.g., by engaging the | 183 relevant mailing lists). In no cases will the IANA allow general | 184 mailing lists (e.g., that of a former or existing IETF Working Group) | 185 to fill the role of the Designated Expert. | 187 Designated Experts serve at the pleasure of the IESG (i.e., they are | 188 appointed by the relevant Area Director) and are typically named at | 189 the time a document that creates a new numbering space is published | 190 as an RFC. Any decisions made by the Designated Expert can be | 191 appealed using the normal IETF appeals process as outlined in Section | 192 6.5 of [IETF-PROCESS]. | 194 The following are example policies, some of which are in use today: 196 Private Use - For private or local use only, with the type and | 197 purpose defined by the local site. No attempt is made to | 198 prevent multiple sites from using the same value in | 199 different (and incompatible) ways. There is no need for | 200 IANA to review such assignments and assignments are not | 201 generally useful for interoperability. 203 Examples: Site-specific options in DHCP [DHCP] have 204 significance only within a single site. XXX X-foo header | 205 lines in email messages. 207 Hierarchical allocation - Delegated managers can assign 208 identifiers provided they have been given control over that 209 part of the identifier space. IANA controls the higher 210 levels of the namespace according to one of the other 211 policies. 213 Examples: DNS names, Object Identifiers 215 First Come First Served - Anyone can obtain an identifier, so long 216 as they provide a point of contact and a brief description 217 of what the identifier would be used for. For numbers, the 218 exact value is generally assigned by the IANA, with names, 219 specific names are usually requested. 221 Examples: vnd. MIME types [MIME-REG], TCP and UDP port 222 numbers. 224 Expert Review - approval by a Designated Expert is required. | 226 Specification Required - Values and their meaning must be 227 documented in an RFC or other permanent and readily 228 available reference, in sufficient detail so that 229 interoperability between independent implementations is 230 possible. 232 Examples: SCSP [SCSP] 234 IESG Approval - New assignments must be approved by the IESG, but | 235 there is no requirement that the request be documented in | 236 an RFC (though the IESG has discretion to request documents | 237 or other supporting materials on a case-by-case basis). | 239 IETF Consensus - New values are assigned through the IETF 240 consensus process. Specifically, new assignments are made 241 via RFCs approved by the IESG. Typically, the IESG will 242 seek input on prospective assignments from appropriate 243 persons (e.g., a relevant Working Group if one exists). 245 Examples: SMTP extensions [SMTP-EXT], BGP Subsequent 246 Address Family Identifiers [BGP4-EXT]. 248 Standards Action - Identifiers are assigned only for Standards 249 Track RFCs approved by the IESG. 251 Examples: MIME top level types [MIME-REG] 253 It should be noted that it often makes sense to partition a number 254 space into several categories, with assignments out of each category 255 handled differently. For example, the DHCP option space [DHCP] is 256 split into two parts. Option numbers in the range of 1-127 are 257 globally unique and assigned according to the Specification Required 258 policy described above, while options number 128-254 are "site 259 specific", i.e., Local Use. Dividing the number space up makes it 260 possible to allow some assignments to be made with minimal review, 261 while simultaneously reserving some part of the space for future use 262 via a more stringent review process. 264 3. Registration maintenance * 266 Registrations sometimes contain information that needs to be 267 maintained; in particular, point of contact information may need to 268 be changed, claims of freedom from security problems may need to be 269 modified, or new versions of a registration may need to be published. 271 A document must clearly state who is responsible for such 272 maintenance. It is appropriate to: 274 - Let the author update the registration, subject to the same 275 constraints and review as with new registrations 277 - Allow some mechanism to attach comments to the registration, for 278 cases where others have significant objections to claims in a 279 registration, but the author does not agree to change the 280 registration. 282 - Designate the IESG or another authority as having the right to 283 reassign ownership of a registration. This is mainly to get 284 around the problem when some registration owner cannot be 285 reached in order to make necessary updates. 287 4. What To Put In Documents * 289 The previous sections presented some issues that should be considered 290 in formulating a policy for assigning well-known numbers and other 291 protocol constants. It is the Working Group and/or document author's 292 job to formulate an appropriate policy and specify it in the 293 appropriate document. In some cases, having an "IANA Considerations" 294 section may be appropriate. Specifically, documents that create an 295 identifier space (or modify the definition of an existing space) and 296 that expect the IANA to play a role in maintaining that space (e.g., 297 serving as a repository for registered values) MUST document the 298 process through which future assignments are made. Such a section | 299 MUST state clearly: 301 - whether or not an application for an assigned number needs to be | 302 reviewed. If review is necessary, the review mechanism MUST be | 303 specified. When a Designated Expert is used, documents MUST NOT | 304 name the Designated Expert in the document itself; instead, the | 305 name should be relayed to the appropriate IESG Area Director at | 306 the time the document is sent to the IESG for approval. 308 - If the request should also be reviewed on a specific public | 309 mailing list (such as the ietf-types@iana.org for media types), 310 that mailing address should be specified. Note, however, that | 311 use of a Designated Expert must also be specified. 313 - if the IANA is expected to make assignments without requiring an | 314 outside review, sufficient guidance MUST be provided so that the | 315 requests can be evaluated with minimal subjectivity. 317 Authors SHOULD attempt to provide guidelines that allow the IANA to | 318 assign new values directly without requiring review by a Designated | 319 Expert. This can be done easily in many cases by designating a range 320 of values for direct assignment by the IANA while simultaneously | 321 reserving sufficient identifier space for future use by requiring 322 that assignments from that space be made only after a more stringent 323 review. 325 Finally, it is quite acceptable to pick one of the example policies 326 cited above and refer to it by name. For example, a document could 327 say something like: 329 Following the policies outlined in [IANA-CONSIDERATIONS], | 330 numbers in the range 0-63 are allocated as First Come First | 331 Served, numbers between 64-240 are allocated through an IETF | 332 Consensus action and values in the range 241-255 are reserved | 333 for Private Use. 335 For examples of documents that provide good and detailed guidance to 336 the IANA on the issue of assigning identifiers, consult [MIME-REG, 337 MIME-LANG]. 339 5. Applicability to Past and Future RFCs 341 For all existing RFCs that either explicitely or implicitly rely on | 342 the IANA to evaluate assignments without specifying a precise | 343 evaluation policy, the IANA will continue to decide what policy is | 344 appropriate. The default policy has typically been first come, first | 345 served. Changes to existing policies can always be initiated through | 346 the normal IETF consensus process. 348 All future RFCs that either explicitely or implicitly rely on the 349 IANA to register or otherwise manage assignments MUST provide 350 guidelines for managing the identifier space. 352 6. Security Considerations 354 Information that creates or updates a registration needs to be 355 authenticated. 357 Information concerning possible security vulnerabilities of a 358 protocol may change over time. Consequently, claims as to the 359 security properties of a registered protocol may change as well. As 360 new vulnerabilities are discovered, information about such 361 vulnerabilities may need to be attached to existing registrations, so 362 that users are not mislead as to the true security properties of a 363 registered protocol. 365 An analysis of security issues is required for all parameters (data | 366 types, operation codes, keywords, etc.) used in IETF protocols or | 367 registered by the IANA. All descriptions of security issues must be | 368 as accurate as possible regardless of level of registration. In | 369 particular, a statement that there are "no security issues associated | 370 with this type" must not be confused with "the security issues | 371 associated with this type have not been assessed". 373 Delegations of a name space should only be assigned to someone with 374 adequate security. 376 7. Acknowledgements 378 Jon Postel and Joyce Reynolds provided a detailed explanation on what | 379 the IANA needs in order to manage assignments efficiently, and | 380 patiently provided comments on multiple versions of this document. | 381 Brian Carpenter provided helpful comments on earlier versions of the | 382 document. One paragraph in the Security Considerations section was | 383 borrowed from [MIME-REG]. 385 8. References 387 [ASSIGNED] Reynolds, J., Postel, J., "Assigned Numbers", October 388 1994k, RFC 1700. 390 [BGP4-EXT] Bates. T., Chandra, R., Katz, D., Rekhter, Y., 391 Multiprotocol Extensions for BGP-4, draft-ietf-idr-bgp4- 392 multiprotocol-02.txt, January, 1998 394 [DHCP-OPTIONS] S. Alexander, R. Droms, DHCP Options and BOOTP 395 Vendor Extensions, RFC 2132, March 1997. 397 [IANA-CONSIDERATIONS] Alvestrand, H., Narten, T., "Guidelines for 398 Writing an IANA Considerations Section in RFCs", draft- | 399 iesg-iana-considerations-04.txt. 401 [IETF-PROCESS] Bradner, S., "The Internet Standards Process -- 402 Revision 3", RFC 2026, October 1996. 404 [IP] J. Postel, Internet Protocol, RFC 791, September 1, 1981. 406 [IPSEC] Atkinson, R., Security Architecture for the Internet 407 Protocol, RFC 1825, August 1995. 409 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 410 Requirement Levels", RFC 2119, March 1997. 412 [MIME-LANG] Freed, N., Moore, K., "MIME Parameter Value and Encoded 413 Word Extensions: Character Sets, Languages, and 414 Continuations", RFC 2184, August, 1997. 416 [MIME-REG] N. Freed, J. Klensin & J. Postel, Multipurpose Internet 417 Mail Extension (MIME) Part Four: Registration Procedures. 418 RFC 2048, November, 1996. 420 [SCSP] Luciani, J., Armitage, G, Halpern, J., "Server Cache 421 Synchronization Protocol (SCSP)" draft-ietf-ion-scsp- 422 02.txt. 424 [SMTP-EXT] Klensin, J., Freed, N., Rose, M., Stefferud, E., 425 Crocker, D.. "SMTP Service Extensions", RFC 1869, November 426 1995. 428 9. Authors' Addresses 430 Thomas Narten 431 IBM Corporation 432 3039 Cornwallis Ave. 433 PO Box 12195 - BRQA/502 434 Research Triangle Park, NC 27709-2195 436 Phone: 919-254-7798 437 EMail: narten@raleigh.ibm.com 439 Harald Tveit Alvestrand 440 Maxware 441 Pirsenteret 442 N-7005 Trondheim 443 Norway 445 Phone: +47 73 54 57 97 446 Email: Harald@Alvestrand.no