idnits 2.17.1 draft-narten-iana-considerations-rfc2434bis-03.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 911. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 872. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 879. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 885. ** 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 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-03' == 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 (October 24, 2005) is 6758 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 438, but not defined == Missing Reference: 'XXX' is mentioned on line 250, but not defined == Missing Reference: 'RFCXXX' is mentioned on line 502, but not defined == Missing Reference: 'RFC 1602' is mentioned on line 742, but not defined ** Obsolete undefined reference: RFC 1602 (Obsoleted by RFC 2026) == Unused Reference: 'DHCP-OPTIONS' is defined on line 773, but no explicit reference was found in the text == Unused Reference: 'MIME-LANG' is defined on line 800, 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: 5 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 October 24, 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 April, 2005. 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............... 5 69 3.2. The Role of the Designated Expert................... 7 70 3.3. Designated Expert Reviews........................... 7 72 4. Creating A Registry...................................... 8 73 4.1. Well-Known IANA Policy Definitions.................. 8 74 4.2. What To Put In Documents That Create A Registry..... 11 75 4.3. Updating Guidelines In Existing Registries.......... 12 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.................. 14 82 6. Miscellaneous Issues..................................... 15 83 6.1. When There Are No IANA Actions...................... 15 84 6.2. Appeals............................................. 16 85 6.3. Namespaces Lacking Documented Guidance.............. 16 87 7. Security Considerations.................................. 16 89 8. Changes Relative to RFC 2434............................. 17 90 8.1. Changes Relative to -00............................. 17 91 8.2. Changes Relative to -02............................. 17 93 9. IANA Considerations...................................... 18 95 10. Acknowledgments......................................... 18 97 11. Normative References.................................... 18 99 12. Informative References.................................. 18 101 13. Authors' Addresses.................................... 20 103 1. Introduction 105 Many protocols make use of fields that contain constants and other 106 well-known values (e.g., the Protocol field in the IP header [IP] or 107 MIME types in mail messages [MIME-REG]). Even after a protocol has 108 been defined and deployment has begun, new values may need to be 109 assigned (e.g., a new option type in DHCP [DHCP] or a new encryption 110 or authentication algorithm for IPsec [IPSEC]). To ensure that such 111 fields have consistent values and interpretations in different 112 implementations, their assignment must be administered by a central 113 authority. For IETF protocols, that role is provided by the Internet 114 Assigned Numbers Authority (IANA) [IANA-MOU]. 116 In this document, we call the set of possible values for such a field 117 a "name space"; its actual value may be a text string, a number or 118 another kind of value. The assignment of a specific value to a name 119 space is called an assigned number (or assigned value). Each 120 assignment of a number in a name space is called a registration. 122 In order for the IANA to manage a given name space prudently, it 123 needs guidelines describing the conditions under which new values 124 should be assigned. This document provides guidelines to authors on 125 what sort of text should be added to their documents, and reviews 126 issues that should be considered in formulating an appropriate policy 127 for assigning numbers to name spaces. 129 Not all name spaces require centralized administration. In some 130 cases, it is possible to delegate a name space in such a way that 131 further assignments can be made independently and with no further 132 (central) coordination. In the Domain Name System, for example, the 133 IANA only deals with assignments at the higher-levels, while 134 subdomains are administered by the organization to which the space 135 has been delegated. As another example, Object Identifiers (OIDs) as 136 defined by the ITU are also delegated [ASSIGNED]. When a name space 137 can be delegated, the scope of IANA is limited to the parts of the 138 namespace where IANA has authority. 140 This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their 141 negatives, in the way described in RFC 2119 [KEYWORDS]. In this case, 142 "the specification" as used by RFC 2119 refers to the processing of 143 protocols being submitted to the IETF standards process. 145 2. Why Management of a Name Space May be Necessary 147 One issue to consider in managing a name space is its size. If the 148 space is small and limited in size, assignments must be made 149 carefully to prevent exhaustion of the space. If the space is 150 essentially unlimited, on the other hand, potential exhaustion may 151 not be a practical concern at all. Even when the space is 152 essentially unlimited, however, it is usually desirable to have at 153 least a minimal review in order to: 155 - prevent the hoarding of or unnecessary wasting of a space. For 156 example, if the space consists of text strings, it may be 157 desirable to prevent organizations from obtaining large sets of 158 strings that correspond to the "best" names (e.g., existing 159 company names). 161 - provide a sanity check that the request actually makes sense and 162 is necessary. Experience has shown that some level of minimal 163 review from a subject matter expert is useful to prevent 164 assignments in cases where the request is malformed or not 165 actually needed (i.e., an existing assignment for a essentially 166 equivalent service already exists). 168 A second consideration is whether it makes sense to delegate the name 169 space in some manner. This route should be pursued when appropriate, 170 as it lessens the burden on the IANA for dealing with assignments. 172 A third, and perhaps most important consideration, concerns potential 173 impact on interoperability of unreviewed extensions. Proposed 174 protocol extensions generally benefit from community review; indeed, 175 review is often essential to prevent future interoperability 176 problems. [VENDOR-EXT] discusses this topic in considerable detail. 178 In some cases, the name space is essentially unlimited, there are no 179 potential interoperability issues, and assigned numbers can safely be 180 given out to anyone. When no subjective review is needed, the IANA 181 can make assignments directly, provided that the IANA is given 182 specific instructions on what types of requests it should grant, and 183 what information must be provided before a request for an assigned 184 number will be considered. Note that the IANA will not define an 185 assignment policy; it should be given a set of guidelines that allow 186 it to make allocation decisions with minimal subjectivity. 188 3. Designated Experts 190 3.1. The Motivation For Designated Experts 192 In most cases, some review of prospective allocations is appropriate, 193 and the question becomes who should perform the review and the 194 purpose of the review. In many cases, one might think that an IETF 195 Working Group (WG) familiar with the name space at hand should be 196 consulted. In practice, however, WGs eventually disband, so they 197 cannot be considered a permanent evaluator. It is also possible for 198 name spaces to be created through individual submission documents, 199 for which no WG is ever formed. 201 One way to ensure community review of prospective assignments is to 202 have the requester submit a document for publication as an RFC. Such 203 an action helps ensure that the specification is publicly and 204 permanently available, and allows some review of the specification 205 prior to publication and assignment of the requested code points. 206 This is the preferred way of ensuring review, and is particularly 207 important if any potential interoperability issues can arise. For 208 example, many assignments are not just assignments, but also involve 209 an element of protocol specification. A new option may define fields 210 that need to be parsed and acted on, which (if specified poorly) may 211 not fit cleanly with the architecture of other options or the base 212 protocols on which they are built. 214 In some cases, however, the burden of publishing an RFC in order to 215 get an assignment is excessive. However, it is generally still useful 216 (and sometimes necessary) to discuss proposed additions on a mailing 217 list dedicated to the purpose (e.g., the ietf-types@iana.org for 218 media types) or on a more general mailing list (e.g., that of a 219 current or former IETF WG). Such a mailing list provides a way for 220 new registrations to be publicly reviewed prior to getting assigned, 221 or to give advice for persons who want help in understanding what a 222 proper registration should contain. 224 While discussion on a mailing list can provide valuable technical 225 expertise, opinions may vary and discussions may continue for some 226 time without clear resolution. In addition, the IANA cannot 227 participate in all of these mailing lists and cannot determine if or 228 when such discussions reach consensus. Therefore, the IANA relies on 229 a "designated expert" to advise it in assignment matters. The 230 designated expert is a single individual who is responsible for 231 carrying out an appropriate evaluation and returning a recommendation 232 to IANA. 234 It should be noted that a key motivation for having designated 235 experts is to provide IANA with a single-person subject matter expert 236 to which it can delegate the evaluation process to, with that person 237 informing IANA whether the assignment is to be made. IANA effectively 238 delegates evaluating the request to the designated expert. 240 3.2. The Role of the Designated Expert 242 The designated expert is responsible for initiating and coordinating 243 as wide a review of an assignment request as appropriate to evaluate 244 it properly. This may involve consultation with a set of technology 245 experts, discussion on a public mailing list, or consultation with a 246 working group (or its mailing list if the working group has 247 disbanded), etc. Ideally, the designated expert follows specific 248 review criteria as documented in a related document that describes 249 management of the namespace. (See the IANA Considerations sections of 250 [RFC3748,RFC3575,XXX] for examples that have been done for specific 251 name spaces). 253 Designated experts are expected to be able to defend their decisions 254 to the IETF community and the evaluation process is not intended to 255 be secretive or bestow unquestioned power on the expert. Experts are 256 expected to apply any documented review or vetting procedures that 257 may apply, or in the absence of documented criteria, follow 258 generally-accepted norms, e.g., those in section 3.3. 260 Section 5.2 discusses disputes and appeals in more detail. 262 Designated experts are appointed by the IESG (e.g., upon 263 recommendation by the relevant Area Director). They are typically 264 named at the time a document that creates a new numbering space is 265 published as an RFC, but as experts originally appointed may later 266 become unavailable, the IESG will appoint replacements if necessary. 268 Since the designated experts are appointed by the IESG, they may be 269 removed by the IESG. 271 3.3. Designated Expert Reviews 273 In the seven years since RFC 2434 was published and has been put to 274 use, experience has led to the following observations: 276 - a designated expert must respond in a timely fashion, normally 277 within a week for simple requests to a few weeks for more complex 278 ones. Unreasonable delays can cause significant problems, such as 279 when products need code points to ship. This is not to say that 280 all reviews can be completed under a firm deadline, but they must 281 be started, and the requester should have some transparency into 282 the process if an answer cannot be given quickly. 284 - The designated expert is not intended to personally bear the 285 burden of evaluating and deciding all requests, but acts as a sort 286 of shepherd for the request, enlisting the help of others as 287 appropriate. In the case that a request is denied, and rejecting 288 the request is likely to be controversial, the expert should have 289 the support of other subject matter experts for a particular 290 decision. That is, the expert must be able to defend a decision to 291 the community as a whole. 293 In the case where a designated expert is used, but there are no 294 specific documented criteria for performing an evaluation, the 295 presumption should be that a code point should be granted, unless 296 there is a compelling reason not to. Possible reasons include: 298 - scarcity of codepoints 300 - documentation is not of sufficient clarity to evaluate or ensure 301 interoperability 303 - the code point is needed for a protocol extension, but the 304 extension is not consistent with the documented (or generally 305 understood) architecture of the base protocol being extended, and 306 would be harmful to the protocol if widely deployed. It is not the 307 intent that "inconsistencies" refer to minor differences "of a 308 personal preference nature;" instead, they refer to significant 309 differences such as inconsistencies with the underlying security 310 model, implying a change to the semantics of an existing message 311 type or operation, requiring unwarranted changes in deployed 312 systems (compared with alternate ways of achieving a similar 313 result), etc. 315 - the extension would cause problems with existing deployed systems. 317 4. Creating A Registry 319 Creating a registry involves describing the name spaces to be created 320 together with an initial set of assignments (if appropriate) and 321 guidelines on how future assignments are to be made. 323 4.1. Well-Known IANA Policy Definitions 325 The following are some defined policies, some of which are in use 326 today. These cover a range of typical policies that have been used to 327 date to describe the procedure for assigning new values in a name 328 space. It is not required that documents use these terms; the actual 329 requirement is that the instructions to IANA are clear and 330 unambiguous. However, it is preferable to use these terms where 331 possible, since their meaning is widely understood. 333 Private Use - For private or local use only, with the type and 334 purpose defined by the local site. No attempt is made to 335 prevent multiple sites from using the same value in 336 different (and incompatible) ways. There is no need for 337 IANA to review such assignments and assignments are not 338 generally useful for interoperability. 340 Examples: Site-specific options in DHCP [DHCP] have 341 significance only within a single site. "X-foo:" header 342 lines in email messages. 344 Experimental Use - Similar to private or local use only, with the 345 purpose being to facilitate experimentation. See 346 [EXPERIMENTATION] for details. 348 Hierarchical allocation - Delegated managers can assign values 349 provided they have been given control over that part of the 350 name space. IANA controls the higher levels of the 351 namespace according to one of the other policies. 353 Examples: DNS names, Object Identifiers, IP addresses 355 First Come First Served - Anyone can obtain an assigned number, so 356 long as they provide a point of contact and a brief 357 description of what the value would be used for. For 358 numbers, the exact value is generally assigned by the IANA; 359 with names, specific text strings are usually requested. 361 Examples: vnd. (vendor assigned) MIME types [MIME-REG], TCP 362 and UDP port numbers. 364 Expert Review (or Designated Expert) - approval by a Designated 365 Expert is required. The required documentation and review 366 criteria to be used by the Designated Expert should be 367 provided when defining the registry. 369 Specification required - Values and their meaning must be 370 documented in an RFC or other permanent and readily 371 available public specification, in sufficient detail so 372 that interoperability between independent implementations 373 is possible. [XXX: who assesses whether a non-RFC document 374 is sufficiently clear for interoperability? IANA cannot.] 376 Examples: SCSP [SCSP] 378 RFC Required - RFC publication (either as IETF Submission or as an 379 RFC Editor submission [RFC3932]) suffices. 381 IETF Review - (Formerly called "IETF Consensus" in [IANA- 382 CONSIDERATIONS]) New values are assigned only through RFCs 383 that have been shepherded through the IESG as AD-Sponsored 384 IETF Documents [RFC3932,RFC3978]. The intention is that the 385 document and proposed assignment will be reviewed by the 386 IESG and appropriate IETF WGs (or experts, if suitable 387 working groups no longer exist) to ensure that the proposed 388 assignment will not negatively impact interoperability or 389 otherwise extend IETF protocols in an inappropriate or 390 damaging manner. 392 To ensure adequate community review, such documents are 393 shepherded through the IESG as AD-sponsored documents with 394 an IETF Last Call. 396 Examples: SMTP extensions [SMTP-EXT], BGP Subsequent 397 Address Family Identifiers [BGP4-EXT]. 399 Standards Action - Values are assigned only for Standards Track 400 RFCs approved by the IESG. 402 Examples: MIME top level types [MIME-REG] 404 IESG Approval - New assignments may be approved by the IESG. 405 Although there is no requirement that the request be 406 documented in an RFC, the IESG has discretion to request 407 documents or other supporting materials on a case-by-case 408 basis. 410 IESG Approval is not intended to be used often or as a 411 "common case;" indeed, it has been seldom used in practice. 412 Rather, it is intended to be available in conjunction with 413 other policies as a fall-back mechanism in the case where 414 one of the other allowable approval mechanisms cannot be 415 employed in a timely fashion or for some other compelling 416 reason. IESG Approval is not intended to circumvent the 417 public review processes implied by other policies that 418 could have been employed for a particular assignment. 420 The following guidelines are suggested for any evaluation 421 under IESG Approval: 423 - The IESG can (and should) reject a request if another 424 path is available that is more appropriate and allows 425 broader community review 427 - before approving a request, the community should be 428 consulted, via a "call for comments" that provides as 429 much information as is reasonably possible. 431 Except in unusual circumstances, the IESG is expected 433 [XXX: Is Section 4.3. below sufficient to cover the case 434 that IESG is designed to handle?] 436 It should be noted that it often makes sense to partition a name 437 space into several categories, with assignments out of each category 438 handled differently. For example, the DHCP option space [DHCP] is 439 split into two parts. Option numbers in the range of 1-127 are 440 globally unique and assigned according to the Specification Required 441 policy described above, while options number 128-254 are "site 442 specific", i.e., Private Use. Dividing the name space up makes it 443 possible to have different policies in place for different ranges. 445 4.2. What To Put In Documents That Create A Registry 447 The previous sections presented some issues that should be considered 448 in formulating a policy for assigning well-known numbers and other 449 protocol constants. It is the Working Group and/or document author's 450 job to formulate an appropriate policy and specify it in the 451 appropriate document. In almost all cases, having an explicit "IANA 452 Considerations" section is appropriate. The following subsections 453 define what is needed for the different types of IANA actions. 455 Documents that create a new name space (or modify the definition of 456 an existing space) and that expect the IANA to play a role in 457 maintaining that space (e.g., serving as a repository for registered 458 values) MUST provide clear instructions on details of the name space. 459 In particular, instructions MUST include: 461 1) The name of the registry being created and/or maintained. The 462 name will appear on the IANA web page and will be referred to in 463 future documents that need to allocate a value from the new 464 space. The full name (and abbreviation, if appropriate) should 465 be provided. 467 2) What information must be provided in order to assign a new 468 value. 470 3) The process through which future assignments are made (see 471 Section 3.1). 473 Note: When a Designated Expert is used, documents MUST NOT name 474 the Designated Expert in the document itself; instead, the name 475 should be relayed to the appropriate IESG Area Director at the 476 time the document is sent to the IESG for approval. 478 If the request should also be reviewed on a specific public 479 mailing list (such as the ietf-types@iana.org for media types), 480 that mailing address should be specified. Note, however, that 481 use of a Designated Expert MUST also be specified. 483 If the IANA is expected to make assignments without requiring an 484 outside review, sufficient guidance MUST be provided so that the 485 requests can be evaluated with minimal subjectivity. 487 When specifying the process for making future assignments, it is 488 quite acceptable to pick one of the example policies listed in 489 Section 3.1 and refer to it by name. Indeed, this is the preferred 490 mechanism in those cases where the sample policies provide the 491 desired level of review. It is also acceptable to cite one of the 492 above policies and include additional guidelines for what kind of 493 considerations should be taken into account by the review process. 494 For example, RADIUS [RFC3575] specifies the use of a Designated 495 Expert, but includes additional criteria the Designated Expert should 496 follow. 498 For example, a document could say something like: 500 This document defines a new DHCP option, entitled "FooBar" (see 501 Section y), assigned a value of TBD1 from the DCHP Option space 502 [RFCXXX]. The FooBar option also contains an 8-bit FooType 503 field, for which IANA is to create and maintain a registry 504 entitled "FooType values". Initial values for FooType field are 505 given below; future assignments are to be made through Expert 506 Review [IANA-CONSIDERATIONS]. Assignments consist of a name and 507 the value. 509 Name Value Definition 510 ---- ----- ---------- 511 Frobnitz 1 See Section y.1 512 NitzFrob 2 See Section y.2 514 For examples of documents that provide good and detailed guidance to 515 the IANA on the issue of assigning numbers, consult [MIME-REG, MIME- 516 LANG, RFC3757, RFC3749, RFC3575]. 518 4.3. Updating Guidelines In Existing Registries 520 Updating the registration process for an existing name space is 521 similar to that used when creating a new namespace. That is, a 522 document is produced that makes reference to the existing namespace 523 and then provides detailed management guidelines for each registry. 524 Such documents are normally processed as BCPs [RFC1818]. 526 Example documents that updated the guidelines for managing (then) 527 pre-existing registries include: [RFC2929,RFC3228,RFC3575]. 529 5. Registering Values In An Existing Registry 531 5.1. What to Put In Documents When Registering Values 533 Often, a document requests the assignment of a code point from an 534 already existing name space (i.e., one created by a previously-pub- 535 lished RFC). In such cases documents should make clear: 537 - From what name space is a value is being requested? List the exact 538 name space listed on the IANA web page (and RFC), and cite the RFC 539 where the name space is defined. (Note: There is no need to men- 540 tion what the allocation policy for new assignments is, as that 541 should be clear from the references.) 543 - For each value being requested, give it a unique name. When the 544 value is numeric, use the notation: TBD1, TBD2, etc. Throughout 545 the document where an actual IANA-assigned value should be filled 546 in, use the "TDBx" notation. This helps ensure that the final RFC 547 has the correct assigned value filled in in all of the relevant 548 places where the value is listed in the final document. For values 549 that are text strings, a specific name can be suggested: IANA will 550 assign the name, unless it conflicts with a name already in use. 552 - Normally, the values to be used are chosen by IANA; documents 553 shouldn't pick values themselves. However, in some cases a value 554 may have been used for testing or in early implementations. In 555 such cases, it is acceptable to include text suggesting what spe- 556 cific value should be used (together with the reason for the 557 choice. For example, one might include the text "the value XXX is 558 suggested as it is used in implementations". However, it should be 559 noted that suggested values are just that; IANA will attempt to 560 assign them, but may find that impossible, if the proposed number 561 has already been assigned for some other use. 563 For many registries, IANA also has a long-standing policy pro- 564 hibiting assignment of names or codes on a vanity or organization 565 name basis, e.g., codes are always assigned sequentially unless 566 there is a strong reason for making an exception. Nothing in this 567 document is intended to change those policies or prevent their 568 future application. 570 - The IANA Considerations section should summarize all of the IANA 571 actions, with pointers to the relevant sections as appropriate. 572 When multiple values are requested, it is generally helpful to 573 include a summary table. 575 As an example, the following text could be used to request assignment 576 of a DHCPv6 option number: 578 IANA has assigned an option code value of TBD1 to the DNS Recur- 579 sive Name Server option and an option code value of TBD2 to the 580 Domain Search List option from the DHCP option code space defined 581 in section 24.3 of RFC 3315. 583 5.2. Maintaining Registrations 585 Registrations are a request for an assigned number, including the 586 related information needed to evaluate and document the request. Even 587 after a number has been assigned, some types of registrations contain 588 additional information that may need to be updated over time. For 589 example, MIME types, character sets, language tags, etc. typically 590 include more information than just the registered value itself. 591 Example information can include point of contact information, 592 security issues, pointers to updates, literature references, etc. In 593 such cases, the document defining the namespace must clearly state 594 who is responsible for maintaining and updating a registration. In 595 different cases, it may be appropriate to specify one or more of the 596 following: 598 - Let the author update the registration, subject to the same 599 constraints and review as with new registrations. 601 - Allow some mechanism to attach comments to the registration, for 602 cases where others have significant objections to claims in a 603 registration, but the author does not agree to change the 604 registration. 606 - Designate the IESG or another entity as having the right to 607 reassign ownership of a registration and any requirements or 608 conditions on doing so. This is mainly to get around the problem 609 when some registration owner cannot be reached in order to make 610 necessary updates. 612 5.3. Overriding Registration Procedures 614 [XXX: following is new text w.r.t. 2434. Is this something that is 615 appropriate to include??] 616 Since RFC 2434 was published, experience has shown that the 617 documented IANA considerations for individual protocols do not always 618 adequately cover the reality on the ground. For example, many older 619 routing protocols do not have documented, detailed IANA 620 considerations. In addition, documented IANA considerations are 621 sometimes found to be too stringent to allow even working group 622 documents (for which there is strong consensus) to obtain code points 623 from IANA in advance of actual RFC publication. In other cases, the 624 documented procedures are unclear or neglected to cover all the 625 cases. In order to allow assignments in individual cases where there 626 is strong IETF consensus that an allocation should go forward, but 627 the documented procedures do not support such an assignment, the IESG 628 is granted authority to approve assignments in such cases. The 629 intention is not to overrule properly documented procedures, or to 630 obviate the need for protocols to properly document their IANA 631 Considerations, but to permit assignments in individual cases where 632 it is obvious that the assignment should just be made, but updating 633 the IANA process just to assign a particular code point is viewed as 634 too heavy a burden. In general, the IETF would like to see deficient 635 IANA registration procedures for a namespace revised through the IETF 636 standards process, but not at the cost of unreasonable delay for 637 needed assignments. 639 6. Miscellaneous Issues 641 6.1. When There Are No IANA Actions 643 Before an Internet-Draft can be published as an RFC, IANA needs to 644 know what actions (if any) it needs to perform. Experience has shown 645 that it is not always immediately obvious whether a document has no 646 IANA actions, without reviewing a document in some detail. In order 647 to make it clear to IANA that it has no actions to perform (and that 648 the author has consciously made such a determination!), such 649 documents should include an IANA Considerations section that states: 651 This document has no IANA Actions. 653 This statement, or an equivalent form of words, must only be inserted 654 after the WG or individual submitter has carefully verified it to be 655 true. 657 In some cases, the absence of IANA-assigned values may be considered 658 valuable information for future readers; in other cases it may be 659 considered of no value once the document has been approved, and may 660 be removed before archival publication. This choice should be made 661 clear in the draft, for example by including a sentence such as 663 [RFC Editor: please remove this section prior to publication.] 665 or 667 [RFC Editor: please do not remove this section.] 669 6.2. Appeals 671 Appeals on registration decisions made by the IANA can be appealed to 672 the IESG using the normal IETF appeals process as outlined in Section 673 6.5 of [IETF-PROCESS]. Specifically, appeals should be directed to 674 the IESG, followed (if necessary) by an appeal to the IAB. 676 6.3. Namespaces Lacking Documented Guidance 678 For all existing RFCs that either explicitly or implicitly rely on 679 the IANA to evaluate assignments without specifying a precise 680 evaluation policy, the IANA (in consultation with the IESG) will 681 continue to decide what policy is appropriate. Changes to existing 682 policies can always be initiated through the normal IETF consensus 683 process. 685 All future RFCs that either explicitly or implicitly rely on the IANA 686 to register or otherwise manage assignments MUST provide guidelines 687 for managing the name space. 689 7. Security Considerations 691 Information that creates or updates a registration needs to be 692 authenticated. 694 Information concerning possible security vulnerabilities of a 695 protocol may change over time. Likewise, security vulnerabilities 696 related to how an assigned number is used (e.g., if it identifies a 697 protocol) may change as well. As new vulnerabilities are discovered, 698 information about such vulnerabilities may need to be attached to 699 existing registrations, so that users are not mislead as to the true 700 security issues surrounding the use of a registered number. 702 An analysis of security issues is required for all parameters (data 703 types, operation codes, keywords, etc.) used in IETF protocols or 704 registered by the IANA. All descriptions of security issues must be 705 as accurate as possible regardless of level of registration. In 706 particular, a statement that there are "no security issues associated 707 with this type" must not given when it would be more accurate to 708 state that "the security issues associated with this type have not 709 been assessed". 711 8. Changes Relative to RFC 2434 713 Changes include: 715 - Major reordering of text to group the "creation of registries" 716 text in same section, etc. 718 - Numerous editorial changes to improve readability. 720 - Change "IETF Consensus" term to "IETF Review" and added more 721 clarifications. 723 - Added "RFC Required" to list of defined policies. 725 - Much more explicit directions and examples of "what to put in 726 RFCs". 728 - no doubt other things... 730 8.1. Changes Relative to -00 732 - Revised Section 5.3 to try and make it even more clear. 734 8.2. Changes Relative to -02 736 - Significantly changed the wording in Section 3. Main purpose is 737 to make clear the Expert Reviewers are accountable to the com- 738 munity, and to provide some guidance for review criteria in the 739 default case. 741 - removed wording: "By virtue of the IAB's role as overseer of 742 IANA administration [RFC 1602], the IAB's decision is final 743 [IETF-PROCESS]." This document now makes no changes to existing 744 appeal mechanisms relative to RFC 2026. 746 9. IANA Considerations 748 This document is all about IANA Considerations. 750 10. Acknowledgments 752 From RFC 2434: 754 Jon Postel and Joyce Reynolds provided a detailed explanation on what 755 the IANA needs in order to manage assignments efficiently, and 756 patiently provided comments on multiple versions of this document. 757 Brian Carpenter provided helpful comments on earlier versions of the 758 document. One paragraph in the Security Considerations section was 759 borrowed from [MIME-REG]. 761 11. Normative References 763 12. Informative References 765 [ASSIGNED] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, 766 RFC 1700, October 1994. See also: 767 http://www.iana.org/numbers.html 769 [BGP4-EXT] Bates. T., Chandra, R., Katz, D. and Y. Rekhter, 770 "Multiprotocol Extensions for BGP-4", RFC 2283, 771 February 1998. 773 [DHCP-OPTIONS] Alexander, S. and R. Droms, "DHCP Options and BOOTP 774 Vendor Extensions", RFC 2132, March 1997. 776 [EXPERIMENTATION] "Assigning Experimental and Testing Numbers 777 Considered Useful". T. Narten, RFC 3692, January 778 2004. 780 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 781 Writing an IANA Considerations Section in RFCs", BCP 782 26, RFC 2434, October 1998. 784 [IANA-MOU] Memorandum of Understanding Concerning the Technical Work 785 of the Internet Assigned Numbers Authority. B. 786 Carpenter, F. Baker, M. Roberts, RFC 2860, June 787 2000. 789 [IETF-PROCESS] Bradner, S., "The Internet Standards Process -- 790 Revision 3", BCP 9, RFC 2026, October 1996. 792 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 794 [IPSEC] Atkinson, R., "Security Architecture for the Internet 795 Protocol", RFC 1825, August 1995. 797 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 798 Requirement Levels", BCP 14, RFC 2119, March 1997. 800 [MIME-LANG] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 801 Word Extensions: Character Sets, Languages, and 802 Continuations", RFC 2184, August 1997. 804 [MIME-REG] Freed, N., Klensin, J. and J. Postel, "Multipurpose 805 Internet Mail Extension (MIME) Part Four: 806 Registration Procedures", RFC 2048, November 1996. 808 [SCSP] Luciani, J., Armitage, G. and J. Halpern, "Server Cache 809 Synchronization Protocol (SCSP)", RFC 2334, April 810 1998. 812 [SMTP-EXT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. 813 Crocker, "SMTP Service Extensions", RFC 1869, 814 November 1995. 816 [VENDOR-EXT] "Considerations on the Extensibility of IETF protocols", 817 draft-iesg-vendor-extensions-02.txt 819 [RFC1818] Best Current Practices. J. Postel, T. Li, Y. Rekhter. 820 August 1995. 822 [RFC2929] Domain Name System (DNS) IANA Considerations. D. Eastlake 823 3rd, E. Brunner-Williams, B. Manning. September 824 2000. 826 [RFC3228] IANA Considerations for IPv4 Internet Group Management 827 Protocol (IGMP). B. Fenner. February 2002. 829 [RFC3575] IANA Considerations for RADIUS (Remote Authentication Dial 830 In User Service). B. Aboba. RFC 3575, July 2003. 832 [RFC3978] IETF Rights in Contributions. S. Bradner, Ed.. March 2005. 834 [RFC3575] IANA Considerations for RADIUS (Remote Authentication Dial 835 In User Service). B. Aboba. July 2003. 837 [RFC3748] Extensible Authentication Protocol (EAP). B. Aboba, L. 838 Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, 839 Ed.. June 2004. 841 [RFC3932] The IESG and RFC Editor Documents: Procedures. H. 842 Alvestrand. October 2004. 844 13. Authors' Addresses 846 Thomas Narten 847 IBM Corporation 848 3039 Cornwallis Ave. 849 PO Box 12195 - BRQA/502 850 Research Triangle Park, NC 27709-2195 852 Phone: 919-254-7798 853 EMail: narten@us.ibm.com 855 Harald Tveit Alvestrand 856 Cisco Systems 857 5245 Arboretum Dr 858 Los Altos, CA 859 USA 861 Email: Harald@Alvestrand.no 863 Intellectual Property Statement 865 The IETF takes no position regarding the validity or scope of any 866 Intellectual Property Rights or other rights that might be claimed to 867 pertain to the implementation or use of the technology described in 868 this document or the extent to which any license under such rights 869 might or might not be available; nor does it represent that it has 870 made any independent effort to identify any such rights. Information 871 on the procedures with respect to rights in RFC documents can be 872 found in BCP 78 and BCP 79. 874 Copies of IPR disclosures made to the IETF Secretariat and any 875 assurances of licenses to be made available, or the result of an 876 attempt made to obtain a general license or permission for the use of 877 such proprietary rights by implementers or users of this 878 specification can be obtained from the IETF on-line IPR repository at 879 http://www.ietf.org/ipr. 881 The IETF invites any interested party to bring to its attention any 882 copyrights, patents or patent applications, or other proprietary 883 rights that may cover technology that may be required to implement 884 this standard. Please address the information to the IETF at ietf- 885 ipr@ietf.org. 887 Disclaimer of Validity 889 This document and the information contained herein are provided on an 890 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 891 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 892 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 893 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 894 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 895 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 897 Copyright Statement 899 Copyright (C) The Internet Society (2005). 901 This document is subject to the rights, licenses and restrictions 902 contained in BCP 78, and except as set forth therein, the authors 903 retain all their rights. 905 This document and the information contained herein are provided on an 906 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 907 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 908 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 909 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 910 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 911 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.