idnits 2.17.1 draft-iesg-iana-considerations-03.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-19) 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. 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 (March 13, 1998) is 9534 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 194, but not defined == Unused Reference: 'DHCP-OPTIONS' is defined on line 368, but no explicit reference was found in the text == Unused Reference: 'MIME-LANG' is defined on line 386, 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. == Outdated reference: A later version (-05) exists of draft-iesg-iana-considerations-03 ** 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: 12 errors (**), 0 flaws (~~), 7 warnings (==), 3 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 March 13, 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 learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net (US East Coast), nic.nordu.net 26 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 27 Rim). 29 Distribution of this memo is unlimited. 31 This Internet Draft expires September 13, 1998. 33 Abstract 35 Many protocols make use of identifiers consisting of constants and 36 other well-known values. Even after a protocol has been defined and 37 deployment has begun, new values may need to be assigned (e.g., for a 38 new option type in DHCP, or a new authentication algorithm). To 39 insure that such quantities have unique values, their assignment must 40 be administered by a central authority. In the Internet, that role is 41 provided by the Internet Assigned Numbers Authority (IANA). 43 In order for the IANA to manage a given numbering space prudently, it 44 needs guidelines describing the conditions under which new values can 45 be assigned. If the IANA is expected to play a role in the management 46 of a numbering space, the IANA must be given clear and concise 47 instructions describing that role. This document discusses issues 48 that should be considered in formulating an identifier assignment 49 policy and provides guidelines to document authors on the specific 50 text that must be included in documents that place demands on the 51 IANA. 53 Contents 55 Status of this Memo.......................................... 1 57 1. Introduction............................................. 3 59 2. Issues To Consider....................................... 4 61 3. Designated Experts....................................... 6 63 4. Registration maintenance................................. 7 65 5. What To Put In Documents................................. 7 67 6. Applicability to Past and Future RFCs.................... 8 69 7. Security Considerations.................................. 8 71 8. Acknowledgements......................................... 9 73 9. References............................................... 9 75 10. Authors' Addresses...................................... 10 77 1. Introduction 79 Many protocols make use of fields that contain constants and other 80 well-known values (e.g., the Protocol field in the IP header [IP] or 81 MIME types in mail messages [MIME-REG]). Even after a protocol has 82 been defined and deployment has begun, new values may need to be 83 assigned (e.g., a new option type in DHCP [DHCP] or a new 84 authentication algorithm for IPSec [IPSEC]). To insure that such 85 fields have unique values, their assignment must be administered by a 86 central authority. In the Internet, that role is provided by the 87 Internet Assigned Numbers Authority (IANA). 89 In order for the IANA to manage a given numbering space prudently, it 90 needs guidelines describing the conditions under which new values 91 should be assigned. This document provides guidelines to authors on 92 what sort of text should be added to their documents, and reviews 93 issues that should be considered in formulating an appropriate policy 94 for assigning identifiers. 96 Not all name spaces require centralized administration. In some 97 cases, it is possible to delegate a name space in such a way that 98 further assignments can be made independently and with no further 99 (central) coordination. In the Domain Name System, for example, the 100 IANA only deals with assignments at the higher-levels, while 101 subdomains are administered by the organization to which the space 102 has been delegated. As another example, Object Identifiers (OIDs) as 103 defined by the ITU are also delegated [ASSIGNED]. When a name space 104 can be delegated, the IANA only deals with assignments at the top 105 level. 107 This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their 108 negatives, in the way described in RFC 2119 [KEYWORDS]. In this case, 109 "the specification" as used by RFC 2119 refers to the processing of 110 protocols being submitted to the IETF standards process. 112 2. Issues To Consider 114 The primary issue to consider in managing a numbering space is its 115 size. If the space is small and limited in size, assignments must be 116 made carefully to insure that the space doesn't become exhausted. If 117 the space is essentially unlimited, on the other hand, it may be 118 perfectly reasonable to hand out new values to anyone that wants one. 119 Even when the space is essentially unlimited, however, it is usually 120 desirable to have a minimal review to prevent hoarding of the space. 121 For example, if the space consists of text strings, it may be 122 desirable to prevent organizations from obtaining large sets of 123 strings that correspond to the "best" names (e.g., existing company 124 names). 126 A second consideration is whether it makes sense to delegate the name 127 space in some manner. This route should be pursued when appropriate, 128 as it lessens the burden on the IANA for dealing with assignments. 130 In most cases, some review of prospective allocations is appropriate, 131 and the first question to consider is who should perform the review. 132 In some cases, reviewing requests is straightforward and requires no 133 subjective decision making. On those cases, it is reasonable for the 134 IANA to review prospective assignments, provided that the IANA is 135 given specific guidelines on what types of requests it should grant, 136 and what information must be provided before a request of an assigned 137 number will be considered. Note that the IANA will not define an 138 assignment policy; it should be given a set of guidelines that allow 139 it to make allocation decisions with little subjectivity. The 140 following are example policies, some of which are in use today: 142 Local Use - For local use only, with the type and purpose defined 143 by the local site. No attempt is made to prevent multiple 144 sites from using the same value in different (and 145 incompatible) ways. There is no need for IANA to review 146 such assignments and assignments are not generally useful 147 for interoperability. 149 Examples: Site-specific options in DHCP [DHCP] have 150 significance only within a single site. XXX X-foo header 151 lines in email message (and mime types?) 153 Hierarchical allocation - Delegated managers can assign 154 identifiers provided they have been given control over that 155 part of the identifier space. IANA controls the higher 156 levels of the namespace according to one of the other 157 policies. 159 Examples: DNS names, Object Identifiers 161 First Come First Served - Anyone can obtain an identifier, so long 162 as they provide a point of contact and a brief description 163 of what the identifier would be used for. For numbers, the 164 exact value is generally assigned by the IANA, with names, 165 specific names are usually requested. 167 Examples: vnd. MIME types [MIME-REG], TCP and UDP port 168 numbers. 170 Specification Required - Values and their meaning must be 171 documented in an RFC or other permanent and readily 172 available reference, in sufficient detail so that 173 interoperability between independent implementations is 174 possible. 176 Examples: SCSP [SCSP] 178 IETF Consensus - New values are assigned through the IETF 179 consensus process. Specifically, new assignments are made 180 via RFCs approved by the IESG. Typically, the IESG will 181 seek input on prospective assignments from appropriate 182 persons (e.g., a relevant Working Group if one exists). 184 Examples: SMTP extensions [SMTP-EXT], BGP Subsequent 185 Address Family Identifiers [BGP4-EXT]. 187 Standards Action - Identifiers are assigned only for Standards 188 Track RFCs approved by the IESG. 190 Examples: MIME top level types [MIME-REG] 192 It should be noted that it often makes sense to partition a number 193 space into several categories, with assignments out of each category 194 handled differently. For example, the DHCP option space [DHCP] is 195 split into two parts. Option numbers in the range of 1-127 are 196 globally unique and assigned according to the Specification Required 197 policy described above, while options number 128-254 are "site 198 specific", i.e., Local Use. Dividing the number space up makes it 199 possible to allow some assignments to be made with minimal review, 200 while simultaneously reserving some part of the space for future use 201 via a more stringent review process. 203 3. Designated Experts 205 In many cases, it is be appropriate for the IANA to serve as a 206 point-of-contact for publishing information about numbers that have 207 been assigned, without actually having it evaluate and grant 208 requests. For example, it may be useful (and sometimes necessary) to 209 discuss proposed additions on a mailing list dedicated to the purpose 210 (e.g., the ietf-types@iana.org for media types) or on a more general 211 mailing list (e.g., that of a current or former IETF Working Group). 212 Such a mailing list provides a way for new registrations to be 213 publically reviewed prior to getting assigned, or to give advice for 214 persons who want help in understanding what a proper registration 215 should contain. 217 Since the IANA cannot participate in all of these mailing lists and 218 cannot determine if or when such discussion reaches a consensus, the 219 IANA in all cases relies on a "designated expert" to advise it in 220 assignment matters. That is, the IANA forwards the requests it 221 receives to a specific point-of-contact (one or a small number of 222 individuals) and acts upon the returned recommendation from the 223 designated expert. In all cases, it is the designated expert that the 224 IANA relies on for an authoritative response. In those cases where 225 wide review of a request is needed, it is the responsibility of the 226 designated expert to initiate such a review (e.g., by engaging the 227 relevant mailing lists). In no cases will the IANA allow general 228 mailing lists (e.g., that of a former or existing IETF Working Group) 229 to fill the role of the designated subject matter expert. 231 Designated experts serve at the pleasure of the IESG (e.g,, they are 232 appointed by the relevant Area Director) and are typically named at 233 the time a document that creates a new numbering space is published 234 as an RFC. Any decisions made by the designated expert can be 235 appealed using the normal IETF appeals process as outlined in Section 236 6.5 of [IETF-PROCESS]. 238 4. Registration maintenance 240 Registrations sometimes contain information that needs to be 241 maintained; in particular, point of contact information may need to 242 be changed, claims of freedom from security problems may need to be 243 modified, or new versions of a registration may need to be published. 245 A document must clearly state who is responsible for such 246 maintenance. It is appropriate to: 248 - Let the author update the registration, subject to the same 249 constraints and review as with new registrations 251 - Allow some mechanism to attach comments to the registration, for 252 cases where others have significant objections to claims in a 253 registration, but the author does not agree to change the 254 registration. 256 - Designate the IESG or another authority as having the right to 257 reassign ownership of a registration. This is mainly to get 258 around the problem when some registration owner cannot be 259 reached in order to make necessary updates. 261 In the absense of specific instructions, the designated expert will 262 assume such responsibilities. 264 5. What To Put In Documents 266 The previous sections presented some issues that should be considered 267 in formulating a policy for assigning well-known numbers and other 268 protocol constants. It is the Working Group and/or document author's 269 job to formulate an appropriate policy and specify it in the 270 appropriate document. In some cases, having an "IANA Considerations" 271 section may be appropriate. Specifically, documents that create an 272 identifier space (or modify the definition of an existing space) and 273 that expect the IANA to play a role in maintaining that space (e.g., 274 serving as a repository for registered values) MUST document the 275 process through which future assignments are made. Such a section 276 should state clearly: 278 - whether or not an application for an assigned number should 279 first be reviewed by a designated expert. When a designated 280 expert is used, documents MUST NOT name the designated expert in 281 the document itself; instead, the name should be relayed to the 282 appropriate IESG Area Director at the time the document is sent 283 to the IESG for approval. 285 - If the request should also be reviewed by a specific public 286 mailing list (such as the ietf-types@iana.org for media types), 287 that mailing address should be specified. Note, however, that a 288 designated subject matter expert must also be specified. 290 - if the IANA is expected to review requests itself, sufficient 291 guidance must be provided so that the requests can be evaluated 292 with minimal subjectivity. 294 Authors SHOULD attempt to provide guidelines that allow the IANA to 295 assign new values directly without requiring review by a designated 296 expert. This can be done easily in many cases by designating a range 297 of values for direct assignment by the IANA while simultaneously 298 reserving some of the identifier space for future use by requiring 299 that assignments from that space be made only after a more stringent 300 review. 302 Finally, it is quite acceptable to pick one of the example policies 303 cited above and refer to it by name. For example, a document could 304 say something like: 306 numbers in the range 0-127 are allocated as First Come First 307 Served as defined in [IANA-CONSIDERATIONS], numbers between 308 128-255 must be approved by the designated expert. 310 For examples of documents that provide good and detailed guidance to 311 the IANA on the issue of assigning identifiers, consult [MIME-REG, 312 MIME-LANG]. 314 6. Applicability to Past and Future RFCs 316 All existing RFCs that either explicitely or implicitly rely on the 317 IANA to evaluate assignments without specifying a precise evaluation 318 policy, will have assignments evaluated by a designated expert, as 319 outlined in Section 3. 321 All future RFCs that either explicitely or implicitly rely on the 322 IANA to register or otherwise manage assignments MUST provide 323 guidelines for managing the identifier space. 325 7. Security Considerations 327 Information that creates or updates a registration needs to be 328 authenticated. 330 Information concerning possible security vulnerabilities of a 331 protocol may change over time. Consequently, claims as to the 332 security properties of a registered protocol may change as well. As 333 new vulnerabilities are discovered, information about such 334 vulnerabilities may need to be attached to existing registrations, so 335 that users are not mislead as to the true security properties of a 336 registered protocol. 338 An analysis of security issues is required for all types registered 339 in the IETF Tree [MIME-REG]. A similar analysis for media types 340 registered in the vendor or personal trees is encouraged but not 341 required. However, regardless of what security analysis has or has 342 not been done, all descriptions of security issues must be as 343 accurate as possible regardless of registration tree. In particular, 344 a statement that there are "no security issues associated with this 345 type" must not be confused with "the security issues associated with 346 this type have not been assessed". 348 Delegations of a name space should only be assigned to someone with 349 adequate security. 351 8. Acknowledgements 353 Jon Postel and Joyce Reynolds provided a detailed explanation on what 354 the IANA needs in order to manage assignments efficiently. Brian 355 Carpenter provided helpful comments on earlier versions of the 356 document. One paragraph in the Security Considerations section was 357 borrowed from [MIME-REG]. 359 9. References 361 [ASSIGNED] Reynolds, J., Postel, J., "Assigned Numbers", October 362 1994k, RFC 1700. 364 [BGP4-EXT] Bates. T., Chandra, R., Katz, D., Rekhter, Y., 365 Multiprotocol Extensions for BGP-4, draft-ietf-idr-bgp4- 366 multiprotocol-02.txt, January, 1998 368 [DHCP-OPTIONS] S. Alexander, R. Droms, DHCP Options and BOOTP 369 Vendor Extensions, RFC 2132, March 1997. 371 [IANA-CONSIDERATIONS] Alvestrand, H., Narten, T., "Guidelines for 372 Writing an IANA Considerations Section in RFCs", draft- 373 iesg-iana-considerations-03.txt. 375 [IETF-PROCESS] Bradner, S., "The Internet Standards Process -- 376 Revision 3", RFC 2026, October 1996. 378 [IP] J. Postel, Internet Protocol, RFC 791, September 1, 1981. 380 [IPSEC] Atkinson, R., Security Architecture for the Internet 381 Protocol, RFC 1825, August 1995. 383 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 384 Requirement Levels", RFC 2119, March 1997. 386 [MIME-LANG] Freed, N., Moore, K., "MIME Parameter Value and Encoded 387 Word Extensions: Character Sets, Languages, and 388 Continuations", RFC 2184, August, 1997. 390 [MIME-REG] N. Freed, J. Klensin & J. Postel, Multipurpose Internet 391 Mail Extension (MIME) Part Four: Registration Procedures. 392 RFC 2048, November, 1996. 394 [SCSP] Luciani, J., Armitage, G, Halpern, J., "Server Cache 395 Synchronization Protocol (SCSP)" draft-ietf-ion-scsp- 396 02.txt. 398 [SMTP-EXT] Klensin, J., Freed, N., Rose, M., Stefferud, E., 399 Crocker, D.. "SMTP Service Extensions", RFC 1869, November 400 1995. 402 10. Authors' Addresses 404 Thomas Narten 405 IBM Corporation 406 3039 Cornwallis Ave. 407 PO Box 12195 - BRQA/502 408 Research Triangle Park, NC 27709-2195 410 Phone: 919-254-7798 411 EMail: narten@raleigh.ibm.com 413 Harald Tveit Alvestrand 414 Maxware 415 Pirsenteret 416 N-7005 Trondheim 417 Norway 419 Phone: +47 73 54 57 97 420 Email: Harald@Alvestrand.no