idnits 2.17.1 draft-iesg-iana-considerations-00.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-26) 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 (October 6, 1997) is 9699 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 193, but not defined == Missing Reference: 'RFC ASSIGN' is mentioned on line 224, but not defined == Unused Reference: 'DHCP-OPTIONS' is defined on line 235, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2048 (ref. 'MIME') (Obsoleted by RFC 4288, RFC 4289) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Thomas Narten 3 IBM 4 Harald Tveit Alvestrand 5 UNINETT 6 October 6, 1997 8 Guidelines for Writing an IANA Considerations Section in RFCs 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ds.internic.net (US East Coast), nic.nordu.net 27 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 28 Rim). 30 Distribution of this memo is unlimited. 32 This Internet Draft expires April 6, 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., a new 39 option type in DHCP). To insure that such quantities have unique 40 values, their assignment must be administered by a central authority. 41 In the Internet, that role is provided by the Internet Assigned 42 Numbers Authority (IANA). 44 In order for the IANA to manage a given numbering space prudently, it 45 needs guidelines describing the conditions under which new values can 46 be assigned. If the IANA is expected to play a role in the management 47 of a numbering space, the IANA must be given clear and concise 48 guidelines describing that role. This document discusses issues that 49 should be considered in formulating an identifier assignment policy 50 and provides guidelines to document authors on the specific text that 51 must be included in documents that place demands on the IANA. 53 Contents 55 Status of this Memo.......................................... 1 57 1. Introduction............................................. 3 59 2. Issues To Consider....................................... 4 61 3. What To Put In Documents................................. 6 63 4. Security Considerations.................................. 6 65 5. References............................................... 6 67 6. Authors' Addresses....................................... 7 69 1. Introduction 71 Many protocols make use of fields that contain constants and other 72 well-known values (e.g., the Protocol field in the IP header [IP] or 73 MIME types in mail messages [MIME]). Even after a protocol has been 74 defined and deployment has begun, new values may need to be assigned 75 (e.g., a new option type in DHCP [DHCP]). To insure that such fields 76 have unique values, their assignment must be administered by a 77 central authority. In the Internet, that role is provided by the 78 Internet Assigned Numbers Authority (IANA). 80 In order for the IANA to manage a given numbering space prudently, it 81 needs guidelines describing the conditions under which new values 82 should be assigned. This document provides guidelines to authors on 83 what sort of text should be added to their documents, and reviews 84 issues that should be considered in formulating an appropriate policy 85 for assigning identifiers. 87 Not all name spaces require centralized administration. In some 88 cases, it is possible to delegate a name space in such a way that 89 further assignments can be made independently and with no further 90 (central) coordination. In the Domain Name System, for example, the 91 IANA only deals with assignments at the higher-levels, while 92 subdomains are administered by the organization to which the space 93 has been delegated. As another example, Object Identifiers (OIDs) as 94 defined by the ITU are also delegated [XXX reference]. When a name 95 space can be delegated, the IANA only deals with assignments at the 96 top level. 98 2. Issues To Consider 100 The primary issue to consider in managing a numbering space is its 101 size. If the space is small and limited in size, assignments must be 102 made carefully to insure that the space doesn't become exhausted. On 103 the other hand, it may be perfectly reasonable to hand out new values 104 to anyone that wants one, if the space is essentially unlimited. Even 105 when the space is essentially unlimited, however, it may be desirable 106 to have a minimal review to prevent hoarding of the space. For 107 example, if the space consists of text strings, it may be desirable 108 to prevent organizations from obtaining large sets of strings that 109 correspond to the "best" names (e.g., existing company names). 111 A second consideration is whether it makes sense to delegate the name 112 space in some manner. This route should be pursued when appropriate, 113 as it lessens the burden on the IANA for dealing with assignments. 115 In most cases, some review of prospective allocations is appropriate, 116 and the first question to answer is who should perform the review. 117 In some cases, it is reasonable for the IANA to review prospective 118 assignments. In such cases, the IANA will need specific guidelines 119 on what types of requests it should grant, and what information must 120 be provided before a request of an assigned number will be 121 considered. Note that the IANA will not define such a policy; it 122 should be given a set of guidelines that allow it to make allocation 123 decisions with little subjectivity. The following are example 124 policies, some of which are in use today: 126 Free For All - For local use only, with the type and purpose 127 defined by the local site. No attempt is made to prevent 128 multiple sites from using the same value in different (and 129 incompatible) ways. There is no need for IANA to review 130 such assignments and assignments are not generally useful 131 for interoperability. 133 Examples: Site-specific options in DHCP [DHCP] have 134 significance only within a single site. 136 Hierarchical allocation - Delegated managers can assign 137 identifiers provided they have been given control over that 138 part of the identifier space. IANA controls the top levels 139 of the namespace according to one of the other policies. 141 Examples: DNS names 143 First Come First Served - Anyone can obtain an identifier, so long 144 as they provide a point of contact and a brief description 145 of what the identifier would be used for. For numbers, the 146 exact value is generally assigned by the IANA, with names, 147 specific names are usually requested. 149 Examples: MIME types, TCP and UDP port numbers. 151 Documentation Required - Values and their meaning must be 152 documented in an RFC or other permanent reference, in 153 sufficient detail so that interoperability between 154 independent implementations is possible. 156 Examples: XXX 158 IESG Action - IESG must explicitly approve new values. 160 Examples: XXX 162 Standards Action - Only identifiers that have been documented in 163 standards track RFCs approved by the IESG will be 164 registered. 166 Examples: XXX 168 In some cases, it may be appropriate for the IANA to serve as a 169 point-of-contact for publishing information about numbers that have 170 been assigned, without actually having it evaluate and grant 171 requests. For example, it is useful (and sometimes necessary) to 172 discuss proposed additions on a mailing list dedicated to the purpose 173 (e.g., the ietf-types@iana.org for media types) or on a mailing list 174 associated with an IETF Working Group. Since the IANA cannot 175 participate in all of these mailing lists and cannot determine if or 176 when such discussion reaches a consensus, the IANA will rely on a 177 designated subject matter expert to advise it in these matters. 178 Consequently, the IANA should be directed to forward the requests it 179 receives to a specific point-of-contact or mailing list (i.e., a 180 mailing list set up specifically for the purpose of discussing such 181 requests) and act upon the returned recommendation from the 182 designated subject matter expert. In all cases, it is the designated 183 subject matter expert that the IANA relies on for an authoritative 184 response. 186 Of course, combinations of the above are also possible. When defining 187 new DHCP option types [DHCP], for example, the IANA assigns options 188 to anyone, with the stipulation that the number will be returned to 189 the IANA should the option fail to gain acceptance. 191 In some cases, it may make sense to partition the number space into 192 several categories, with assignments out of each category handled 193 differently. For example, the DHCP option space [DHCP] is split into 194 two parts. Option numbers in the range of 1-127 are globally unique 195 and assigned according to the Documentation Required policy described 196 earlier, while options number 128-254 are "site specific", i.e., Free 197 For All. 199 3. What To Put In Documents 201 The previous section presented some issues that should be considered 202 in formulating a policy for assigning well-known numbers and other 203 protocol constants. It is the Working Group and/or document author's 204 job to formulate an appropriate policy and specify it in the 205 appropriate document. In some cases, having an "IANA Considerations" 206 section may be appropriate. Such a section should state clearly: 208 - who reviews an application for an assigned number. If a request 209 should be reviewed by a designated subject matter expert, 210 contact information for that person should be provided. If the 211 request should also be reviewed by a specific mailing list (such 212 as the ietf-types@iana.org for media types), that mailing 213 address should be specified. 215 - if the IANA is expected to review requests itself, sufficient 216 guidance must be provided so that the requests can be evaluated 217 with minimal subjectivity. 219 Finally, it is quite acceptable to pick one of the example policies 220 cited above and refer to it by name. For example, a document could 221 say something like: 223 numbers are allocated as First Come First Served as defined in 224 [RFC ASSIGN] 226 XXX: give pointers to 3 or 4 particularly good examples in existing 227 RFCs? 1) DHCP options seems reasonable. Others? 229 4. Security Considerations 231 There are no known security issues raised by this document. 233 5. References 235 [DHCP-OPTIONS] S. Alexander, R. Droms, DHCP Options and BOOTP 236 Vendor Extensions, RFC 2132, March 1997. 238 [IP] J. Postel, Internet Protocol, RFC 791, September 1, 1981. 240 [MIME] N. Freed, J. Klensin & J. Postel, Multipurpose Internet Mail 241 Extension (MIME) Part Four: Registration Procedures. RFC 242 2048, November, 1996. 244 6. Authors' Addresses 246 Thomas Narten 247 IBM Corporation 248 3039 Cornwallis Ave. 249 PO Box 12195 - BRQA/502 250 Research Triangle Park, NC 27709-2195 252 Phone: 919-254-7798 253 EMail: narten@raleigh.ibm.com 255 Harald Tveit Alvestrand 256 UNINETT 257 P.O.Box 6883 Elgeseter 258 N-7002 TRONDHEIM 259 NORWAY 261 Phone: +47 73 59 70 94 262 EMail: Harald.T.Alvestrand@uninett.no