idnits 2.17.1 draft-narten-iana-considerations-rfc2434bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 962. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 923. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 930. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 936. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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. ** Missing revision: the document name given in the document, 'draft-narten-iana-considerations-rfc2434bis', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-narten-iana-considerations-rfc2434bis', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-narten-iana-considerations-rfc2434bis', but the file name used is 'draft-narten-iana-considerations-rfc2434bis-04' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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. (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 6, 2005) is 6962 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 464, but not defined == Missing Reference: 'XXX' is mentioned on line 258, but not defined == Missing Reference: 'RFCXXX' is mentioned on line 530, but not defined == Missing Reference: 'RFC 1602' is mentioned on line 792, but not defined ** Obsolete undefined reference: RFC 1602 (Obsoleted by RFC 2026) == Unused Reference: 'DHCP-OPTIONS' is defined on line 827, but no explicit reference was found in the text == Unused Reference: 'MIME-LANG' is defined on line 854, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1700 (ref. 'ASSIGNED') (Obsoleted by RFC 3232) -- Obsolete informational reference (is this intentional?): RFC 2283 (ref. 'BGP4-EXT') (Obsoleted by RFC 2858) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 1825 (ref. 'IPSEC') (Obsoleted by RFC 2401) -- Obsolete informational reference (is this intentional?): RFC 2184 (ref. 'MIME-LANG') (Obsoleted by RFC 2231) -- Obsolete informational reference (is this intentional?): RFC 2048 (ref. 'MIME-REG') (Obsoleted by RFC 4288, RFC 4289) -- Obsolete informational reference (is this intentional?): RFC 1869 (ref. 'SMTP-EXT') (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 2929 (Obsoleted by RFC 5395) -- Obsolete informational reference (is this intentional?): RFC 3978 (Obsoleted by RFC 5378) -- Obsolete informational reference (is this intentional?): RFC 3932 (Obsoleted by RFC 5742) Summary: 6 errors (**), 1 flaw (~~), 10 warnings (==), 17 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 Cisco 6 March 6, 2005 8 Guidelines for Writing an IANA Considerations Section in RFCs 10 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft expires in six months. 37 Abstract 39 Many protocols make use of identifiers consisting of constants and 40 other well-known values. Even after a protocol has been defined and 41 deployment has begun, new values may need to be assigned (e.g., for a 42 new option type in DHCP, or a new encryption or authentication 43 transform for IPsec). To ensure that such quantities have consistent 44 values and interpretations in different implementations, their 45 assignment must be administered by a central authority. For IETF 46 protocols, that role is provided by the Internet Assigned Numbers 47 Authority (IANA). 49 In order for the IANA to manage a given name space prudently, it 50 needs guidelines describing the conditions under which new values can 51 be assigned. If the IANA is expected to play a role in the management 52 of a name space, the IANA must be given clear and concise 53 instructions describing that role. This document discusses issues 54 that should be considered in formulating a policy for assigning 55 values to a name space and provides guidelines to document authors on 56 the specific text that must be included in documents that place 57 demands on the IANA. 59 Contents 61 Status of this Memo.......................................... 1 63 1. Introduction............................................. 4 65 2. Why Management of a Name Space May be Necessary.......... 4 67 3. Designated Experts....................................... 5 68 3.1. The Motivation For Designated Experts............... 6 69 3.2. The Role of the Designated Expert................... 7 70 3.3. Designated Expert Reviews........................... 7 72 4. Creating A Registry...................................... 9 73 4.1. Well-Known IANA Policy Definitions.................. 9 74 4.2. What To Put In Documents That Create A Registry..... 11 75 4.3. Updating Guidelines In Existing Registries.......... 13 77 5. Registering Values In An Existing Registry............... 13 78 5.1. What to Put In Documents When Registering Values.... 13 79 5.2. Maintaining Registrations........................... 14 80 5.3. Overriding Registration Procedures.................. 15 82 6. Miscellaneous Issues..................................... 16 83 6.1. When There Are No IANA Actions...................... 16 84 6.2. Appeals............................................. 16 85 6.3. Namespaces Lacking Documented Guidance.............. 16 87 7. Security Considerations.................................. 17 89 8. Open Issues.............................................. 17 91 9. Changes Relative to RFC 2434............................. 18 92 9.1. Changes Relative to -00............................. 18 93 9.2. Changes Relative to -02............................. 18 95 10. IANA Considerations..................................... 19 97 11. Acknowledgments......................................... 19 99 12. Normative References.................................... 19 101 13. Informative References.................................. 19 103 14. Authors' Addresses.................................... 21 105 1. Introduction 107 Many protocols make use of fields that contain constants and other 108 well-known values (e.g., the Protocol field in the IP header [IP] or 109 MIME types in mail messages [MIME-REG]). Even after a protocol has 110 been defined and deployment has begun, new values may need to be 111 assigned (e.g., a new option type in DHCP [DHCP] or a new encryption 112 or authentication algorithm for IPsec [IPSEC]). To ensure that such 113 fields have consistent values and interpretations in different 114 implementations, their assignment must be administered by a central 115 authority. For IETF protocols, that role is provided by the Internet 116 Assigned Numbers Authority (IANA) [IANA-MOU]. 118 In this document, we call the set of possible values for such a field 119 a "name space"; its actual value may be a text string, a number or 120 another kind of value. The assignment of a specific value to a name 121 space is called an assigned number (or assigned value). Each 122 assignment of a number in a name space is called a registration. 124 In order for the IANA to manage a given name space prudently, it 125 needs guidelines describing the conditions under which new values 126 should be assigned. This document provides guidelines to authors on 127 what sort of text should be added to their documents, and reviews 128 issues that should be considered in formulating an appropriate policy 129 for assigning numbers to name spaces. 131 Not all name spaces require centralized administration. In some 132 cases, it is possible to delegate a name space in such a way that 133 further assignments can be made independently and with no further 134 (central) coordination. In the Domain Name System, for example, the 135 IANA only deals with assignments at the higher-levels, while 136 subdomains are administered by the organization to which the space 137 has been delegated. As another example, Object Identifiers (OIDs) as 138 defined by the ITU are also delegated [ASSIGNED]. When a name space 139 can be delegated, the scope of IANA is limited to the parts of the 140 namespace where IANA has authority. 142 This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their 143 negatives, in the way described in RFC 2119 [KEYWORDS]. In this case, 144 "the specification" as used by RFC 2119 refers to the processing of 145 protocols being submitted to the IETF standards process. 147 2. Why Management of a Name Space May be Necessary 149 One issue to consider in managing a name space is its size. If the 150 space is small and limited in size, assignments must be made 151 carefully to prevent exhaustion of the space. If the space is 152 essentially unlimited, on the other hand, potential exhaustion will 153 probably not be a practical concern at all. Even when the space is 154 essentially unlimited, however, it is usually desirable to have at 155 least a minimal review prior to assignment in order to: 157 - prevent the hoarding of or unnecessary wasting of a space. For 158 example, if the space consists of text strings, it may be 159 desirable to prevent entities from obtaining large sets of strings 160 that correspond to the "best" names (e.g., existing company 161 names). 163 - provide a sanity check that the request actually makes sense and 164 is necessary. Experience has shown that some level of minimal 165 review from a subject matter expert is useful to prevent 166 assignments in cases where the request is malformed or not 167 actually needed (i.e., an existing assignment for an essentially 168 equivalent service already exists). 170 A second consideration is whether it makes sense to delegate the name 171 space in some manner. This route should be pursued when appropriate, 172 as it lessens the burden on the IANA for dealing with assignments. 174 A third, and perhaps most important consideration, concerns potential 175 impact on interoperability of unreviewed extensions. Proposed 176 protocol extensions generally benefit from community review; indeed, 177 review is often essential to prevent future interoperability 178 problems. [VENDOR-EXT] discusses this topic in considerable detail. 180 In some cases, the name space is essentially unlimited and there are 181 no potential interoperability issues; in such cases assigned numbers 182 can safely be given out to anyone. When no subjective review is 183 needed, the IANA can make assignments directly, provided that the 184 IANA is given specific instructions on what types of requests it 185 should grant, and what information must be provided as part of the 186 request for an assigned number. 188 It should be noted that the IANA does not create or define assignment 189 policy itself; rather, it carries out policies that have been defined 190 by others, i.e., in RFCs. IANA must be given a set of guidelines 191 that allow it to make allocation decisions with minimal subjectivity 192 and without requiring any technical expertise with respect to the 193 protocols that make use of a registry. 195 3. Designated Experts 196 3.1. The Motivation For Designated Experts 198 In most cases, some review of prospective allocations is appropriate, 199 and the question becomes who should perform the review and what is 200 the purpose of the review. In many cases, one might think that an 201 IETF Working Group (WG) familiar with the name space at hand should 202 be consulted. In practice, however, WGs eventually disband, so they 203 cannot be considered a permanent evaluator. It is also possible for 204 name spaces to be created through individual submission documents, 205 for which no WG is ever formed. 207 One way to ensure community review of prospective assignments is to 208 have the requester submit a document for publication as an RFC. Such 209 an action helps ensure that the specification is publicly and 210 permanently available, and allows some review of the specification 211 prior to publication and assignment of the requested code points. 212 This is the preferred way of ensuring review, and is particularly 213 important if any potential interoperability issues can arise. For 214 example, many assignments are not just assignments, but also involve 215 an element of protocol specification. A new option may define fields 216 that need to be parsed and acted on, which (if specified poorly) may 217 not fit cleanly with the architecture of other options or the base 218 protocols on which they are built. 220 In some cases, however, the burden of publishing an RFC in order to 221 get an assignment is excessive. However, it is generally still useful 222 (and sometimes necessary) to discuss proposed additions on a mailing 223 list dedicated to the purpose (e.g., the ietf-types@iana.org for 224 media types) or on a more general mailing list (e.g., that of a 225 current or former IETF WG). Such a mailing list provides a way for 226 new registrations to be publicly reviewed prior to getting assigned, 227 or to give advice for persons who want help in understanding what a 228 proper registration should contain. 230 While discussion on a mailing list can provide valuable technical 231 feedback, opinions may vary and discussions may continue for some 232 time without clear resolution. In addition, the IANA cannot 233 participate in all of these mailing lists and cannot determine if or 234 when such discussions reach consensus. Therefore, the IANA relies on 235 a "designated expert" to advise it in assignment matters. The 236 designated expert is a single individual who is responsible for 237 carrying out an appropriate evaluation and returning a recommendation 238 to IANA. 240 It should be noted that a key motivation for having designated 241 experts is for the IETF to provide IANA with a single-person subject 242 matter expert to which it can delegate the evaluation process to, 243 with that person informing IANA whether the assignment is to be made. 245 IANA effectively delegates evaluating the request to the IETF's 246 designated expert. 248 3.2. The Role of the Designated Expert 250 The designated expert is responsible for initiating and coordinating 251 as wide a review of an assignment request as appropriate to evaluate 252 it properly. This may involve consultation with a set of technology 253 experts, discussion on a public mailing list, or consultation with a 254 working group (or its mailing list if the working group has 255 disbanded), etc. Ideally, the designated expert follows specific 256 review criteria as documented in a related document that describes 257 management of the namespace. (See the IANA Considerations sections of 258 [RFC3748,RFC3575,XXX] for examples that have been done for specific 259 name spaces). 261 Designated experts are expected to be able to defend their decisions 262 to the IETF community and the evaluation process is not intended to 263 be secretive or bestow unquestioned power on the expert. Experts are 264 expected to apply any documented review or vetting procedures that 265 may apply, or in the absence of documented criteria, follow 266 generally-accepted norms, e.g., those in section 3.3. 268 Section 5.2 discusses disputes and appeals in more detail. 270 Designated experts are appointed by the IESG (e.g., upon 271 recommendation by the relevant Area Director). They are typically 272 named at the time a document that creates a new numbering space is 273 approved by the IESG, but as experts originally appointed may later 274 become unavailable, the IESG will appoint replacements if necessary. 276 Since the designated experts are appointed by the IESG, they may be 277 removed by the IESG. 279 3.3. Designated Expert Reviews 281 In the seven years since RFC 2434 was published and has been put to 282 use, experience has led to the following observations: 284 - a designated expert must respond in a timely fashion, normally 285 within a week for simple requests to a few weeks for more complex 286 ones. Unreasonable delays can cause significant problems, such as 287 when products need code points to ship. This is not to say that 288 all reviews can be completed under a firm deadline, but they must 289 be started, and the requester and IANA should have some 290 transparency into the process if an answer cannot be given 291 quickly. 293 - if a designated expert does not respond to IANA's requests within 294 a reasonable period of time, either with a response, or to explain 295 that the requests are particularly complex, and if this is a 296 recurring event, the IANA must raise the issue with the IESG. 297 Because of the problems caused by delayed evaluations and 298 assignments, the IESG should take appropriate actions, such as 299 ensuring that the expert understands their responsibilities, or 300 appointing a new expert. 302 - The designated expert is not required to personally bear the 303 burden of evaluating and deciding all requests, but acts as a sort 304 of shepherd for the request, enlisting the help of others as 305 appropriate. In the case that a request is denied, and rejecting 306 the request is likely to be controversial, the expert should have 307 the support of other subject matter experts for a particular 308 decision. That is, the expert must be able to defend a decision to 309 the community as a whole. 311 In the case where a designated expert is used, but there are no 312 specific documented criteria for performing an evaluation, the 313 presumption should be that a code point should be granted, unless 314 there is a compelling reason not to. Possible reasons include: 316 - scarcity of codepoints, where the finite remaining codepoints 317 should be prudently managed, or when a request for a large number 318 of codepoints is made, when a single codepoint is the norm. 320 - documentation is not of sufficient clarity to evaluate or ensure 321 interoperability 323 - the code point is needed for a protocol extension, but the 324 extension is not consistent with the documented (or generally 325 understood) architecture of the base protocol being extended, and 326 would be harmful to the protocol if widely deployed. It is not the 327 intent that "inconsistencies" refer to minor differences "of a 328 personal preference nature;" instead, they refer to significant 329 differences such as inconsistencies with the underlying security 330 model, implying a change to the semantics of an existing message 331 type or operation, requiring unwarranted changes in deployed 332 systems (compared with alternate ways of achieving a similar 333 result), etc. 335 - the extension would cause problems with existing deployed systems. 337 - the extension would conflict with one under active development by 338 the IETF, and having both would harm rather than foster 339 interoperability. 341 4. Creating A Registry 343 Creating a registry involves describing the name spaces to be created 344 together with an initial set of assignments (if appropriate) and 345 guidelines on how future assignments are to be made. 347 4.1. Well-Known IANA Policy Definitions 349 The following are some defined policies, some of which are in use 350 today. These cover a range of typical policies that have been used to 351 date to describe the procedure for assigning new values in a name 352 space. It is not required that documents use these terms; the actual 353 requirement is that the instructions to IANA are clear and 354 unambiguous. However, it is preferable to use these terms where 355 possible, since their meaning is widely understood. 357 Private Use - For private or local use only, with the type and 358 purpose defined by the local site. No attempt is made to 359 prevent multiple sites from using the same value in 360 different (and incompatible) ways. There is no need for 361 IANA to review such assignments (since IANA does not record 362 them) and assignments are not generally useful for broad 363 interoperability. 365 Examples: Site-specific options in DHCP [DHCP] have 366 significance only within a single site. "X-foo:" header 367 lines in email messages. 369 Experimental Use - Similar to private or local use only, with the 370 purpose being to facilitate experimentation. See 371 [EXPERIMENTATION] for details. 373 Hierarchical allocation - Delegated managers can assign values 374 provided they have been given control over that part of the 375 name space. IANA controls the higher levels of the 376 namespace according to one of the other policies. 378 Examples: DNS names, Object Identifiers, IP addresses 380 First Come First Served - Anyone can obtain an assigned number, so 381 long as they provide a point of contact and a brief 382 description of what the value would be used for together 383 with any other required information that is specifically 384 required to be provided by the name space in question. For 385 numbers, the exact value is generally assigned by the IANA; 386 with names, specific text strings are usually requested. 388 Examples: vnd. (vendor assigned) MIME types [MIME-REG], TCP 389 and UDP port numbers. 391 Expert Review (or Designated Expert) - approval by a Designated 392 Expert is required. The required documentation and review 393 criteria to be used by the Designated Expert should be 394 provided when defining the registry. 396 Specification required - Values and their meaning must be 397 documented in an RFC or other permanent and readily 398 available public specification, in sufficient detail so 399 that interoperability between independent implementations 400 is possible. When used, Specification Required also implies 401 useage of a Designated Expert, who will review the public 402 specification and evaluate whether it is sufficiently clear 403 to allow interoperable implementations. 405 Examples: SCSP [SCSP] 407 RFC Required - RFC publication (either as IETF Submission or as an 408 RFC Editor submission [RFC3932]) suffices. 410 IETF Review - (Formerly called "IETF Consensus" in [IANA- 411 CONSIDERATIONS]) New values are assigned only through RFCs 412 that have been shepherded through the IESG as AD-Sponsored 413 IETF Documents [RFC3932,RFC3978]. The intention is that the 414 document and proposed assignment will be reviewed by the 415 IESG and appropriate IETF WGs (or experts, if suitable 416 working groups no longer exist) to ensure that the proposed 417 assignment will not negatively impact interoperability or 418 otherwise extend IETF protocols in an inappropriate or 419 damaging manner. 421 To ensure adequate community review, such documents are 422 shepherded through the IESG as AD-sponsored documents with 423 an IETF Last Call. 425 Examples: SMTP extensions [SMTP-EXT], BGP Subsequent 426 Address Family Identifiers [BGP4-EXT]. 428 Standards Action - Values are assigned only for Standards Track 429 RFCs approved by the IESG. 431 Examples: MIME top level types [MIME-REG] 433 IESG Approval - New assignments may be approved by the IESG. 434 Although there is no requirement that the request be 435 documented in an RFC, the IESG has discretion to request 436 documents or other supporting materials on a case-by-case 437 basis. 439 IESG Approval is not intended to be used often or as a 440 "common case;" indeed, it has seldom been used in practice 441 during the period RFC 2434 was in effect. Rather, it is 442 intended to be available in conjunction with other policies 443 as a fall-back mechanism in the case where one of the other 444 allowable approval mechanisms cannot be employed in a 445 timely fashion or for some other compelling reason. IESG 446 Approval is not intended to circumvent the public review 447 processes implied by other policies that could have been 448 employed for a particular assignment. 450 The following guidelines are suggested for any evaluation 451 under IESG Approval: 453 - The IESG can (and should) reject a request if another 454 path is available that is more appropriate and allows 455 broader community review 457 - before approving a request, the community should be 458 consulted, via a "call for comments" that provides as 459 much information as is reasonably possible about the 460 request. 462 It should be noted that it often makes sense to partition a name 463 space into several categories, with assignments out of each category 464 handled differently. For example, the DHCP option space [DHCP] is 465 split into two parts. Option numbers in the range of 1-127 are 466 globally unique and assigned according to the Specification Required 467 policy described above, while options number 128-254 are "site 468 specific", i.e., Private Use. Dividing the name space up makes it 469 possible to have different policies in place for different ranges. 471 4.2. What To Put In Documents That Create A Registry 473 The previous sections presented some issues that should be considered 474 in formulating a policy for assigning well-known numbers and other 475 protocol constants. It is the Working Group and/or document author's 476 job to formulate an appropriate policy and specify it in the 477 appropriate document. In almost all cases, having an explicit "IANA 478 Considerations" section is appropriate. The following subsections 479 define what is needed for the different types of IANA actions. 481 Documents that create a new name space (or modify the definition of 482 an existing space) and that expect the IANA to play a role in 483 maintaining that space (e.g., serving as a repository for registered 484 values) MUST provide clear instructions on details of the name space. 485 In particular, instructions MUST include: 487 1) The name of the registry being created and/or maintained. The 488 name will appear on the IANA web page and will be referred to in 489 future documents that need to allocate a value from the new 490 space. The full name (and abbreviation, if appropriate) should 491 be provided. Ideally, the chosen name will not be easily 492 confusable with the name of another registry. 494 2) What information must be provided as part of a request in order 495 to assign a new value. 497 3) The review process that will apply to all future requests for a 498 value from the namespace. 500 Note: When a Designated Expert is used, documents MUST NOT name 501 the Designated Expert in the document itself; instead, the name 502 should be relayed to the appropriate IESG Area Director at the 503 time the document is sent to the IESG for approval. 505 If the request should also be reviewed on a specific public 506 mailing list (such as the ietf-types@iana.org for media types), 507 that mailing address should be specified. Note, however, that 508 use of a Designated Expert MUST also be specified (see Section 509 3). 511 If the IANA is expected to make assignments without requiring an 512 outside review, sufficient guidance MUST be provided so that the 513 requests can be evaluated with minimal subjectivity. 515 When specifying the process for making future assignments, it is 516 quite acceptable to pick one of the example policies listed in 517 Section 4.1 and refer to it by name. Indeed, this is the preferred 518 mechanism in those cases where the sample policies provide the 519 desired level of review. It is also acceptable to cite one of the 520 above policies and include additional guidelines for what kind of 521 considerations should be taken into account by the review process. 522 For example, RADIUS [RFC3575] specifies the use of a Designated 523 Expert, but includes specific additional criteria the Designated 524 Expert should follow. 526 For example, a document could say something like: 528 This document defines a new DHCP option, entitled "FooBar" (see 529 Section y), assigned a value of TBD1 from the DCHP Option space 530 [RFCXXX]. The FooBar option also contains an 8-bit FooType 531 field, for which IANA is to create and maintain a registry 532 entitled "FooType values". Initial values for the FooType 533 registry are given below; future assignments are to be made 534 through Expert Review [IANA-CONSIDERATIONS]. Assignments consist 535 of a name and the value. 537 Name Value Definition 538 ---- ----- ---------- 539 Frobnitz 1 See Section y.1 540 NitzFrob 2 See Section y.2 542 For examples of documents that provide good and detailed guidance to 543 the IANA on the issue of assigning numbers, consult [MIME-REG, MIME- 544 LANG, RFC3757, RFC3749, RFC3575]. 546 4.3. Updating Guidelines In Existing Registries 548 Updating the registration process for an existing name space is 549 similar to that used when creating a new namespace. That is, a 550 document is produced that makes reference to the existing namespace 551 and then provides detailed management guidelines for each individual 552 name space. Such documents are normally processed as BCPs [IETF- 553 PROCESS]. 555 Example documents that updated the guidelines for managing (then) 556 pre-existing registries include: [RFC2929,RFC3228,RFC3575]. 558 5. Registering Values In An Existing Registry 560 5.1. What to Put In Documents When Registering Values 562 Often, a document requests the assignment of a code point from an 563 already existing name space (i.e., one created by a previously-pub- 564 lished RFC). In such cases documents should make clear: 566 - From what name space is a value is being requested? List the exact 567 name space listed on the IANA web page (and RFC), and cite the RFC 568 where the name space is defined. (Note: There is no need to men- 569 tion what the allocation policy for new assignments is, as that 570 should be clear from the references.) 572 - For each value being requested, give it a unique name. When the 573 value is numeric, use the notation: TBD1, TBD2, etc. Throughout 574 the document where an actual IANA-assigned value should be filled 575 in, use the "TBDx" notation. This helps ensure that the final RFC 576 has the correct assigned value inserted in in all of the relevant 577 places where the value is expected to be listed in the final docu- 578 ment. For values that are text strings, a specific name can be 579 suggested: IANA will assign the name, unless it conflicts with a 580 name already in use. 582 - Normally, the values to be used are chosen by IANA; documents 583 shouldn't pick values themselves. However, in some cases a value 584 may have been used for testing or in early implementations. In 585 such cases, it is acceptable to include text suggesting what spe- 586 cific value should be used (together with the reason for the 587 choice). For example, one might include the text "the value XXX is 588 suggested as it is used in implementations". However, it should be 589 noted that suggested values are just that; IANA will attempt to 590 assign them, but may find that impossible, if the proposed number 591 has already been assigned for some other use. 593 For many registries, IANA also has a long-standing policy pro- 594 hibiting assignment of names or codes on a vanity or organization 595 name basis, e.g., codes are always assigned sequentially unless 596 there is a strong reason for making an exception. Nothing in this 597 document is intended to change those policies or prevent their 598 future application. 600 - The IANA Considerations section should summarize all of the IANA 601 actions, with pointers to the relevant sections elsewhere in the 602 document as appropriate. When multiple values are requested, it is 603 generally helpful to include a summary table. It is also often 604 useful for this table to be in the format of the registry data in 605 the IANA site 607 As an example, the following text could be used to request assignment 608 of a DHCPv6 option number: 610 IANA has assigned an option code value of TBD1 to the DNS Recur- 611 sive Name Server option and an option code value of TBD2 to the 612 Domain Search List option from the DHCP option code space defined 613 in section 24.3 of RFC 3315. 615 5.2. Maintaining Registrations 617 Registrations are a request for an assigned number, including the 618 related information needed to evaluate and document the request. Even 619 after a number has been assigned, some types of registrations contain 620 additional information that may need to be updated over time. For 621 example, MIME types, character sets, language tags, etc. typically 622 include more information than just the registered value itself. 623 Example information can include point of contact information, 624 security issues, pointers to updates, literature references, etc. In 625 such cases, the document defining the namespace must clearly state 626 who is responsible for maintaining and updating a registration. In 627 different cases, it may be appropriate to specify one or more of the 628 following: 630 - Let the author update the registration, subject to the same 631 constraints and review as with new registrations. 633 - Allow some mechanism to attach comments to the registration, for 634 cases where others have significant objections to claims in a 635 registration, but the author does not agree to change the 636 registration. 638 - Designate the IESG or another entity as having the right to 639 change the registrant associated with a registration and any 640 requirements or conditions on doing so. This is mainly to get 641 around the problem when a registrant cannot be reached in order 642 to make necessary updates. 644 5.3. Overriding Registration Procedures 646 Since RFC 2434 was published, experience has shown that the 647 documented IANA considerations for individual protocols do not always 648 adequately cover the reality on the ground. For example, many older 649 routing protocols do not have documented, detailed IANA 650 considerations. In addition, documented IANA considerations are 651 sometimes found to be too stringent to allow even working group 652 documents (for which there is strong consensus) to obtain code points 653 from IANA in advance of actual RFC publication. In other cases, the 654 documented procedures are unclear or neglected to cover all the 655 cases. In order to allow assignments in individual cases where there 656 is strong IETF consensus that an allocation should go forward, but 657 the documented procedures do not support such an assignment, the IESG 658 is granted authority to approve assignments in such cases. The 659 intention is not to overrule properly documented procedures, or to 660 obviate the need for protocols to properly document their IANA 661 Considerations. Instead, the intention is to permit assignments in 662 individual cases where it is obvious that the assignment should just 663 be made, but updating the IANA process just to assign a particular 664 code point is viewed as too heavy a burden. In general, the IETF 665 would like to see deficient IANA registration procedures for a 666 namespace revised through the IETF standards process, but not at the 667 cost of unreasonable delay for needed assignments. 669 6. Miscellaneous Issues 671 6.1. When There Are No IANA Actions 673 Before an Internet-Draft can be published as an RFC, IANA needs to 674 know what actions (if any) it needs to perform. Experience has shown 675 that it is not always immediately obvious whether a document has no 676 IANA actions, without reviewing a document in some detail. In order 677 to make it clear to IANA that it has no actions to perform (and that 678 the author has consciously made such a determination!), such 679 documents should include an IANA Considerations section that states: 681 This document has no IANA Actions. 683 This statement, or an equivalent form of words, must only be inserted 684 after the WG or individual submitter has carefully verified it to be 685 true. 687 In some cases, the absence of IANA-assigned values may be considered 688 valuable information for future readers; in other cases it may be 689 considered of no value once the document has been approved, and may 690 be removed before archival publication. This choice should be made 691 clear in the draft, for example by including a sentence such as 693 [RFC Editor: please remove this section prior to publication.] 695 or 697 [RFC Editor: please do not remove this section.] 699 6.2. Appeals 701 Appeals on registration decisions made by the IANA can be appealed 702 using the normal IETF appeals process as described in Section 6.5 of 703 [IETF-PROCESS]. Specifically, appeals should be directed to the IESG, 704 followed (if necessary) by an appeal to the IAB, etc. 706 6.3. Namespaces Lacking Documented Guidance 708 For all existing RFCs that either explicitly or implicitly rely on 709 the IANA to evaluate assignments without specifying a precise 710 evaluation policy, the IANA (in consultation with the IESG) will 711 continue to decide what policy is appropriate. Changes to existing 712 policies can always be initiated through the normal IETF consensus 713 process. 715 All future RFCs that either explicitly or implicitly rely on the IANA 716 to register or otherwise manage assignments MUST provide guidelines 717 for managing the name space. 719 7. Security Considerations 721 Information that creates or updates a registration needs to be 722 authenticated and authorized. 724 Information concerning possible security vulnerabilities of a 725 protocol may change over time. Likewise, security vulnerabilities 726 related to how an assigned number is used (e.g., if it identifies a 727 protocol) may change as well. As new vulnerabilities are discovered, 728 information about such vulnerabilities may need to be attached to 729 existing registrations, so that users are not mislead as to the true 730 security issues surrounding the use of a registered number. 732 An analysis of security issues is required for all parameters (data 733 types, operation codes, keywords, etc.) used in IETF protocols or 734 registered by the IANA. All descriptions of security issues must be 735 as accurate as possible regardless of level of registration. In 736 particular, a statement that there are "no security issues associated 737 with this type" must not given when it would be more accurate to 738 state that "the security issues associated with this type have not 739 been assessed". 741 8. Open Issues 743 - It has been suggested that mailing lists associated with public 744 reviews (e.g., ietf-types) should be hosted by IETF servers and 745 should have public archives available. To what degree should we 746 have requirements? Should we have a policy, and should it be 747 documented here? 749 - Added text to "Specification Required" stating that an Expert will 750 be used to evaluate a spec for adequate "implementability". Is 751 this reasonable? [IANA can't do the evaluation, as they lack the 752 necessary time/expertise. So someone has to do it...] 754 - It would be good to get feedback on whether the examples of "good 755 IANA Considerations" that are cited are actually good, or whether 756 better ones are available. 758 9. Changes Relative to RFC 2434 760 Changes include: 762 - Major reordering of text to group the "creation of registries" 763 text in same section, etc. 765 - Numerous editorial changes to improve readability. 767 - Change "IETF Consensus" term to "IETF Review" and added more 768 clarifications. 770 - Added "RFC Required" to list of defined policies. 772 - Much more explicit directions and examples of "what to put in 773 RFCs". 775 - "Specification Required" now implies use of Designated Expert to 776 evaluate specs for sufficient clarity. 778 - no doubt other things... 780 9.1. Changes Relative to -00 782 - Revised Section 5.3 to try and make it even more clear. 784 9.2. Changes Relative to -02 786 - Significantly changed the wording in Section 3. Main purpose is 787 to make clear the Expert Reviewers are accountable to the com- 788 munity, and to provide some guidance for review criteria in the 789 default case. 791 - removed wording: "By virtue of the IAB's role as overseer of 792 IANA administration [RFC 1602], the IAB's decision is final 793 [IETF-PROCESS]." This document now makes no changes to existing 794 appeal mechanisms relative to RFC 2026. 796 10. IANA Considerations 798 This document is all about IANA Considerations. 800 11. Acknowledgments 802 This document has benefited from specific feedback from Marcelo 803 Bagnulo Braun, Brian Carpenter, Spencer Dawkins, John Klensin, 804 Allison Mankin, Mark Townsley and Bert Wijnen. 806 The original acknowledgements section in RFC 2434 was: 808 Jon Postel and Joyce Reynolds provided a detailed explanation on what 809 the IANA needs in order to manage assignments efficiently, and 810 patiently provided comments on multiple versions of this document. 811 Brian Carpenter provided helpful comments on earlier versions of the 812 document. One paragraph in the Security Considerations section was 813 borrowed from [MIME-REG]. 815 12. Normative References 817 13. Informative References 819 [ASSIGNED] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, 820 RFC 1700, October 1994. See also: 821 http://www.iana.org/numbers.html 823 [BGP4-EXT] Bates. T., Chandra, R., Katz, D. and Y. Rekhter, 824 "Multiprotocol Extensions for BGP-4", RFC 2283, 825 February 1998. 827 [DHCP-OPTIONS] Alexander, S. and R. Droms, "DHCP Options and BOOTP 828 Vendor Extensions", RFC 2132, March 1997. 830 [EXPERIMENTATION] "Assigning Experimental and Testing Numbers 831 Considered Useful". T. Narten, RFC 3692, January 832 2004. 834 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 835 Writing an IANA Considerations Section in RFCs", BCP 836 26, RFC 2434, October 1998. 838 [IANA-MOU] Memorandum of Understanding Concerning the Technical Work 839 of the Internet Assigned Numbers Authority. B. 840 Carpenter, F. Baker, M. Roberts, RFC 2860, June 841 2000. 843 [IETF-PROCESS] Bradner, S., "The Internet Standards Process -- 844 Revision 3", BCP 9, RFC 2026, October 1996. 846 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 848 [IPSEC] Atkinson, R., "Security Architecture for the Internet 849 Protocol", RFC 1825, August 1995. 851 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 852 Requirement Levels", BCP 14, RFC 2119, March 1997. 854 [MIME-LANG] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 855 Word Extensions: Character Sets, Languages, and 856 Continuations", RFC 2184, August 1997. 858 [MIME-REG] Freed, N., Klensin, J. and J. Postel, "Multipurpose 859 Internet Mail Extension (MIME) Part Four: 860 Registration Procedures", RFC 2048, November 1996. 862 [SCSP] Luciani, J., Armitage, G. and J. Halpern, "Server Cache 863 Synchronization Protocol (SCSP)", RFC 2334, April 864 1998. 866 [SMTP-EXT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. 867 Crocker, "SMTP Service Extensions", RFC 1869, 868 November 1995. 870 [VENDOR-EXT] "Considerations on the Extensibility of IETF protocols", 871 draft-iesg-vendor-extensions-02.txt 873 [RFC2929] Domain Name System (DNS) IANA Considerations. D. Eastlake 874 3rd, E. Brunner-Williams, B. Manning. September 875 2000. 877 [RFC3228] IANA Considerations for IPv4 Internet Group Management 878 Protocol (IGMP). B. Fenner. February 2002. 880 [RFC3575] IANA Considerations for RADIUS (Remote Authentication Dial 881 In User Service). B. Aboba. RFC 3575, July 2003. 883 [RFC3978] IETF Rights in Contributions. S. Bradner, Ed.. March 2005. 885 [RFC3575] IANA Considerations for RADIUS (Remote Authentication Dial 886 In User Service). B. Aboba. July 2003. 888 [RFC3748] Extensible Authentication Protocol (EAP). B. Aboba, L. 889 Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, 890 Ed.. June 2004. 892 [RFC3932] The IESG and RFC Editor Documents: Procedures. H. 893 Alvestrand. October 2004. 895 14. Authors' Addresses 897 Thomas Narten 898 IBM Corporation 899 3039 Cornwallis Ave. 900 PO Box 12195 - BRQA/502 901 Research Triangle Park, NC 27709-2195 903 Phone: 919-254-7798 904 EMail: narten@us.ibm.com 906 Harald Tveit Alvestrand 907 Cisco Systems 908 5245 Arboretum Dr 909 Los Altos, CA 910 USA 912 Email: Harald@Alvestrand.no 914 Intellectual Property Statement 916 The IETF takes no position regarding the validity or scope of any 917 Intellectual Property Rights or other rights that might be claimed to 918 pertain to the implementation or use of the technology described in 919 this document or the extent to which any license under such rights 920 might or might not be available; nor does it represent that it has 921 made any independent effort to identify any such rights. Information 922 on the procedures with respect to rights in RFC documents can be 923 found in BCP 78 and BCP 79. 925 Copies of IPR disclosures made to the IETF Secretariat and any 926 assurances of licenses to be made available, or the result of an 927 attempt made to obtain a general license or permission for the use of 928 such proprietary rights by implementers or users of this 929 specification can be obtained from the IETF on-line IPR repository at 930 http://www.ietf.org/ipr. 932 The IETF invites any interested party to bring to its attention any 933 copyrights, patents or patent applications, or other proprietary 934 rights that may cover technology that may be required to implement 935 this standard. Please address the information to the IETF at ietf- 936 ipr@ietf.org. 938 Disclaimer of Validity 940 This document and the information contained herein are provided on an 941 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 942 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 943 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 944 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 945 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 946 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 948 Copyright Statement 950 Copyright (C) The Internet Society (2006). 952 This document is subject to the rights, licenses and restrictions 953 contained in BCP 78, and except as set forth therein, the authors 954 retain all their rights. 956 This document and the information contained herein are provided on an 957 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 958 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 959 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 960 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 961 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 962 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.