idnits 2.17.1 draft-iesg-iana-considerations-02.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-03-29) 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 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 30, 1997) is 9920 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 212, but not defined == Unused Reference: 'DHCP-OPTIONS' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'MIME-LANG' is defined on line 347, 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-02 ** 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 (~~), 6 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 January 30, 1997 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 July 30, 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. Registration maintenance................................. 6 63 4. What To Put In Documents................................. 7 65 5. Security Considerations.................................. 8 67 6. Acknowledgements......................................... 8 69 7. References............................................... 8 71 8. Authors' Addresses....................................... 9 73 1. Introduction 75 Many protocols make use of fields that contain constants and other 76 well-known values (e.g., the Protocol field in the IP header [IP] or 77 MIME types in mail messages [MIME-REG]). Even after a protocol has 78 been defined and deployment has begun, new values may need to be 79 assigned (e.g., a new option type in DHCP [DHCP] or a new 80 authentication algorithm for IPSec [IPSEC]). To insure that such 81 fields have unique values, their assignment must be administered by a 82 central authority. In the Internet, that role is provided by the 83 Internet Assigned Numbers Authority (IANA). 85 In order for the IANA to manage a given numbering space prudently, it 86 needs guidelines describing the conditions under which new values 87 should be assigned. This document provides guidelines to authors on 88 what sort of text should be added to their documents, and reviews 89 issues that should be considered in formulating an appropriate policy 90 for assigning identifiers. 92 Not all name spaces require centralized administration. In some 93 cases, it is possible to delegate a name space in such a way that 94 further assignments can be made independently and with no further 95 (central) coordination. In the Domain Name System, for example, the 96 IANA only deals with assignments at the higher-levels, while 97 subdomains are administered by the organization to which the space 98 has been delegated. As another example, Object Identifiers (OIDs) as 99 defined by the ITU are also delegated [ASSIGNED]. When a name space 100 can be delegated, the IANA only deals with assignments at the top 101 level. 103 2. Issues To Consider 105 The primary issue to consider in managing a numbering space is its 106 size. If the space is small and limited in size, assignments must be 107 made carefully to insure that the space doesn't become exhausted. If 108 the space is essentially unlimited, on the other hand, it may be 109 perfectly reasonable to hand out new values to anyone that wants one. 110 Even when the space is essentially unlimited, however, it is usually 111 desirable to have a minimal review to prevent hoarding of the space. 112 For example, if the space consists of text strings, it may be 113 desirable to prevent organizations from obtaining large sets of 114 strings that correspond to the "best" names (e.g., existing company 115 names). 117 A second consideration is whether it makes sense to delegate the name 118 space in some manner. This route should be pursued when appropriate, 119 as it lessens the burden on the IANA for dealing with assignments. 121 In most cases, some review of prospective allocations is appropriate, 122 and the first question to consider is who should perform the review. 123 In some cases, reviewing requests is straightforward and requires no 124 subject subjective decision making. On those cases, it is reasonable 125 for the IANA to review prospective assignments, provided that the 126 IANA is given specific guidelines on what types of requests it should 127 grant, and what information must be provided before a request of an 128 assigned number will be considered. Note that the IANA will not 129 define an assignment policy; it should be given a set of guidelines 130 that allow it to make allocation decisions with little subjectivity. 131 The following are example policies, some of which are in use today: 133 Local Use - For local use only, with the type and purpose defined 134 by the local site. No attempt is made to prevent multiple 135 sites from using the same value in different (and 136 incompatible) ways. There is no need for IANA to review 137 such assignments and assignments are not generally useful 138 for interoperability. 140 Examples: Site-specific options in DHCP [DHCP] have 141 significance only within a single site. 143 Hierarchical allocation - Delegated managers can assign 144 identifiers provided they have been given control over that 145 part of the identifier space. IANA controls the higher 146 levels of the namespace according to one of the other 147 policies. 149 Examples: DNS names, Object Identifiers 151 First Come First Served - Anyone can obtain an identifier, so long 152 as they provide a point of contact and a brief description 153 of what the identifier would be used for. For numbers, the 154 exact value is generally assigned by the IANA, with names, 155 specific names are usually requested. 157 Examples: vnd. MIME types [MIME-REG], TCP and UDP port 158 numbers. 160 Specification Required - Values and their meaning must be 161 documented in an RFC or other permanent and readily 162 available reference, in sufficient detail so that 163 interoperability between independent implementations is 164 possible. 166 Examples: SCSP [SCSP] 168 IETF Consensus - New values are assigned through the IETF 169 consensus process. Specifically, new assignments must be 170 approved by the IESG. Typically, the IESG will seek input 171 on prospective assignments from appropriate persons (e.g., 172 a relevant Working Group if one exists). 174 Examples: SMTP extensions [SMTP-EXT], BGP Subsequent 175 Address Family Identifiers [BGP4-EXT]. 177 Standards Action - Identifiers are assigned only for Standards 178 Track RFCs approved by the IESG. 180 Examples: MIME top level types [MIME-REG] 182 In some cases, it may be appropriate for the IANA to serve as a 183 point-of-contact for publishing information about numbers that have 184 been assigned, without actually having it evaluate and grant 185 requests. For example, it is useful (and sometimes necessary) to 186 discuss proposed additions on a mailing list dedicated to the purpose 187 (e.g., the ietf-types@iana.org for media types) or on a more general 188 mailing list on which (e.g., that of a current or former IETF Working 189 Group). Such a mailing list may serve to give new registrations a 190 public review before getting registered, or give advice for persons 191 who want help in understanding what a proper registration should 192 contain. 194 Since the IANA cannot participate in all of these mailing lists and 195 cannot determine if or when such discussion reaches a consensus, the 196 IANA in all cases relies on a designated subject matter expert to 197 advise it in these matters. That is, the IANA must be directed to 198 forward the requests it receives to a specific point-of-contact (one 199 or a small number of individuals) and act upon the returned 200 recommendation from the designated subject matter expert. In all 201 cases, it is the designated subject matter expert that the IANA 202 relies on for an authoritative response. In those cases where wide 203 review of a request is needed, it is the responsibility of the 204 designated subject matter expert to initiate such a review (e.g., by 205 engaging the relevant mailing lists). In no cases will the IANA allow 206 general mailing lists (e.g., that of a former or existing IETF 207 Working Group) to fill the role of the designated subject matter 208 expert. 210 In some cases, it makes sense to partition the number space into 211 several categories, with assignments out of each category handled 212 differently. For example, the DHCP option space [DHCP] is split into 213 two parts. Option numbers in the range of 1-127 are globally unique 214 and assigned according to the Specification Required policy described 215 earlier, while options number 128-254 are "site specific", i.e., 216 Local Use. 218 3. Registration maintenance 220 Registrations sometimes contain information that needs to be 221 maintained; in particular, point of contact information may need to 222 be changed, claims of freedom from security problems may need to be 223 modified, or new versions of a registration may need to be published. 225 A document must clearly state who is responsible for such 226 maintenance. It is appropriate to: 228 - Let the author update the registration, subject to the same 229 constraints and review as with new registrations 231 - Allow some mechanism to attach comments to the registration, for 232 cases where others have significant objections to claims in a 233 registration, but the author does not agree to change the 234 registration. 236 - Designate the IESG or another authority as having the right to 237 reassign ownership of a registration. This is mainly to get 238 around the problem when some registration owner cannot be 239 reached in order to make necessary updates. 241 4. What To Put In Documents 243 The previous section presented some issues that should be considered 244 in formulating a policy for assigning well-known numbers and other 245 protocol constants. It is the Working Group and/or document author's 246 job to formulate an appropriate policy and specify it in the 247 appropriate document. In some cases, having an "IANA Considerations" 248 section may be appropriate. Such a section should state clearly: 250 - who reviews an application for an assigned number. If a request 251 should be reviewed by a designated subject matter expert, 252 contact information must be provided. 254 - who has authority to replace the designated subject matter 255 expert, should a replacement be needed (e.g., if multiple 256 attempts to reach the designated subject matter fail). The 257 specific procedure to appoint the person should also be 258 indicated; it may often be appropriate to let the relevant IESG 259 Area Director designate the subject matter expert when a 260 replacement is necessary. 262 - If the request should also be reviewed by a specific public 263 mailing list (such as the ietf-types@iana.org for media types), 264 that mailing address should be specified. Note, however, that a 265 designated subject matter expert must also be specified. 267 - if the IANA is expected to review requests itself, sufficient 268 guidance must be provided so that the requests can be evaluated 269 with minimal subjectivity. 271 It should also be noted that the following are unacceptable: 273 - listing a Working Group mailing list as the designated subject 274 matter expert 276 - specifying that "the current Working Group Chairs of the FooBar 277 Working Group" are the designated subject matter experts, since 278 Working Groups eventually close down. However, it is acceptable 279 to list the current WG Chairs individually. 281 Finally, it is quite acceptable to pick one of the example policies 282 cited above and refer to it by name. For example, a document could 283 say something like: 285 numbers are allocated as First Come First Served as defined in 286 [IANA-CONSIDERATIONS] 288 For examples of documents that provide good and detailed guidance to 289 the IANA on the issue of assigning identifiers, consult [MIME-REG, 290 MIME-LANG]. 292 5. Security Considerations 294 Information that creates or updates a registration needs to be 295 authenticated. 297 Information concerning possible security vulnerabilities of a 298 protocol may change over time. Consequently, claims as to the 299 security properties of a registered protocol may change as well. As 300 new vulnerabilities are discovered, information about such 301 vulnerabilities may need to be attached to existing registrations, so 302 that users are not mislead as to the true security properties of a 303 registered protocol. 305 An analysis of security issues is required for for all types 306 registered in the IETF Tree [MIME-REG]. A similar analysis for media 307 types registered in the vendor or personal trees is encouraged but 308 not required. However, regardless of what security analysis has or 309 has not been done, all descriptions of security issues must be as 310 accurate as possible regardless of registration tree. In particular, 311 a statement that there are "no security issues associated with this 312 type" must not be confused with "the security issues associated with 313 this type have not been assessed". 315 Delegations of a name space should only be assigned to someone with 316 adequate security. 318 6. Acknowledgements 320 Jon Postel and Joyce Reynolds provided a detailed explanation on what 321 the IANA needs in order to manage assignments efficiently. Brian 322 Carpenter provided helpful comments on earlier versions of the 323 document. One paragraph in the Security Considerations section was 324 borrowed from [MIME-REG]. 326 7. References 328 [ASSIGNED] Reynolds, J., Postel, J., "Assigned Numbers", October 329 1994k, RFC 1700. 331 [BGP4-EXT] Bates. T., Chandra, R., Katz, D., Rekhter, Y., 332 Multiprotocol Extensions for BGP-4, draft-ietf-idr-bgp4- 333 multiprotocol-02.txt, January, 1998 335 [DHCP-OPTIONS] S. Alexander, R. Droms, DHCP Options and BOOTP 336 Vendor Extensions, RFC 2132, March 1997. 338 [IANA-CONSIDERATIONS] Alvestrand, H., Narten, T., "Guidelines for 339 Writing an IANA Considerations Section in RFCs", draft- 340 iesg-iana-considerations-02.txt. 342 [IP] J. Postel, Internet Protocol, RFC 791, September 1, 1981. 344 [IPSEC] Atkinson, R., Security Architecture for the Internet 345 Protocol, RFC 1825, August 1995. 347 [MIME-LANG] Freed, N., Moore, K., "MIME Parameter Value and Encoded 348 Word Extensions: Character Sets, Languages, and 349 Continuations", RFC 2184, August, 1997. 351 [MIME-REG] N. Freed, J. Klensin & J. Postel, Multipurpose Internet 352 Mail Extension (MIME) Part Four: Registration Procedures. 353 RFC 2048, November, 1996. 355 [SCSP] Luciani, J., Armitage, G, Halpern, J., "Server Cache 356 Synchronization Protocol (SCSP)" draft-ietf-ion-scsp- 357 02.txt. 359 [SMTP-EXT] Klensin, J., Freed, N., Rose, M., Stefferud, E., 360 Crocker, D.. "SMTP Service Extensions", RFC 1869, November 361 1995. 363 8. Authors' Addresses 365 Thomas Narten 366 IBM Corporation 367 3039 Cornwallis Ave. 368 PO Box 12195 - BRQA/502 369 Research Triangle Park, NC 27709-2195 371 Phone: 919-254-7798 372 EMail: narten@raleigh.ibm.com 374 Harald Tveit Alvestrand 375 UNINETT 376 P.O.Box 6883 Elgeseter 377 N-7002 TRONDHEIM 378 NORWAY 380 Phone: +47 73 59 70 94 381 EMail: Harald.T.Alvestrand@uninett.no