idnits 2.17.1 draft-narten-iana-considerations-rfc2434bis-07.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, updated by RFC 4748 on line 1085. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1056. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1063. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1069. 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. == 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 IETF Trust 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 (July 9, 2007) is 6136 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: 'RFCXXX' is mentioned on line 570, but not defined == Missing Reference: 'RFC 1602' is mentioned on line 913, but not defined ** Obsolete undefined reference: RFC 1602 (Obsoleted by RFC 2026) == Unused Reference: 'MIME-LANG' is defined on line 974, but no explicit reference was found in the text == Unused Reference: 'RFC3968' is defined on line 1023, 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 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) == Outdated reference: A later version (-04) exists of draft-carpenter-protocol-extensions-01 -- 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: 3 errors (**), 0 flaws (~~), 8 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Thomas Narten 3 IBM 4 Harald Alvestrand 5 Obsoletes: 2434 Google 6 July 9, 2007 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 IANA to manage a given name space prudently, it needs 50 guidelines describing the conditions under which new values can be 51 assigned, or when modifications to existing values can be made. If 52 IANA is expected to play a role in the management of a name space, 53 the IANA must be given clear and concise instructions describing that 54 role. This document discusses issues that should be considered in 55 formulating a policy for assigning values to a name space and 56 provides guidelines to document authors on the specific text that 57 must be included in documents that place demands on IANA. 59 This document obsoletes RFC 2434. 61 Contents 63 Status of this Memo.......................................... 1 65 1. Introduction............................................. 4 67 2. Why Management of a Name Space May be Necessary.......... 5 69 3. Designated Experts....................................... 5 70 3.1. The Motivation For Designated Experts............... 5 71 3.2. The Role of the Designated Expert................... 7 72 3.3. Designated Expert Reviews........................... 7 74 4. Creating A Registry...................................... 9 75 4.1. Well-Known IANA Policy Definitions.................. 9 76 4.2. What To Put In Documents That Create A Registry..... 12 77 4.3. Updating IANA Guidelines For Existing Registries.... 14 79 5. Registering New Values In An Existing Registry........... 14 80 5.1. What to Put In Documents When Registering Values.... 14 81 5.2. Updating Registrations.............................. 15 82 5.3. Overriding Registration Procedures.................. 16 84 6. Miscellaneous Issues..................................... 17 85 6.1. When There Are No IANA Actions...................... 17 86 6.2. Namespaces Lacking Documented Guidance.............. 18 87 6.3. After-The-Fact Registrations........................ 18 88 6.4. Reclaiming Assigned Values.......................... 18 90 7. Appeals.................................................. 19 92 8. Mailing Lists............................................ 19 94 9. Security Considerations.................................. 19 96 10. Changes Relative to RFC 2434............................ 20 97 10.1. Changes Relative to -00............................ 21 98 10.2. Changes Relative to -02............................ 21 100 11. IANA Considerations..................................... 21 102 12. Acknowledgments......................................... 21 104 13. Normative References.................................... 21 106 14. Informative References.................................. 22 108 15. Authors' Addresses...................................... 24 110 1. Introduction 112 Many protocols make use of fields that contain constants and other 113 well-known values (e.g., the Protocol field in the IP header [IP] or 114 MIME types in mail messages [MIME-REG]). Even after a protocol has 115 been defined and deployment has begun, new values may need to be 116 assigned (e.g., a new option type in DHCP [DHCP-OPTIONS] or a new 117 encryption or authentication transform for IPsec [IPSEC]). To ensure 118 that such fields have consistent values and interpretations in 119 different implementations, their assignment must be administered by a 120 central authority. For IETF protocols, that role is provided by the 121 Internet Assigned Numbers Authority (IANA) [IANA-MOU]. 123 In this document, we call the set of possible values for such a field 124 a "name space"; its actual value may be a text string, a number or 125 another kind of value. The binding or association of a specific value 126 with a particular purpose within a name space is called an assigned 127 number (or assigned value, or sometimes a "code point", "protocol 128 constant", or "protocol parameter"). Each assignment of a value in a 129 name space is called a registration. 131 In order for IANA to manage a given name space prudently, it needs 132 guidelines describing the conditions under which new values should be 133 assigned, or when (and how) modifications to existing values can be 134 made. This document provides guidelines to authors on what sort of 135 text should be added to their documents in order to provide IANA 136 clear guidelines and reviews issues that should be considered in 137 formulating an appropriate policy for assigning numbers to name 138 spaces. 140 Not all name spaces require centralized administration. In some 141 cases, it is possible to delegate a name space in such a way that 142 further assignments can be made independently and with no further 143 (central) coordination. In the Domain Name System, for example, the 144 IANA only deals with assignments at the higher-levels, while 145 subdomains are administered by the organization to which the space 146 has been delegated. As another example, Object Identifiers (OIDs) as 147 defined by the ITU are also delegated [ASSIGNED]; IANA manages the 148 subtree rooted at "iso.org.dod.internet" (1.3.6.1) . When a name 149 space is delegated, the scope of IANA is limited to the parts of the 150 namespace where IANA has authority. 152 This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their 153 negatives, in the way described in RFC 2119 [KEYWORDS]. In this case, 154 "the specification" as used by RFC 2119 refers to the processing of 155 protocol documents within the IETF standards process. 157 2. Why Management of a Name Space May be Necessary 159 One issue to consider in managing a name space is its size. If the 160 space is small and limited in size, assignments must be made 161 carefully to prevent exhaustion of the space. If the space is 162 essentially unlimited, on the other hand, potential exhaustion will 163 probably not be a practical concern at all. Even when the space is 164 essentially unlimited, however, it is usually desirable to have at 165 least a minimal review prior to assignment in order to: 167 - prevent the hoarding of or unnecessary wasting of values. For 168 example, if the space consists of text strings, it may be 169 desirable to prevent entities from obtaining large sets of strings 170 that correspond to desirable names (e.g., existing company names). 172 - provide a sanity check that the request actually makes sense and 173 is necessary. Experience has shown that some level of minimal 174 review from a subject matter expert is useful to prevent 175 assignments in cases where the request is malformed or not 176 actually needed (i.e., an existing assignment for an essentially 177 equivalent service already exists). 179 A second consideration is whether it makes sense to delegate the name 180 space in some manner. This route should be pursued when appropriate, 181 as it lessens the burden on IANA for dealing with assignments. 183 A third, and perhaps most important consideration, concerns potential 184 impact on interoperability of unreviewed extensions. Proposed 185 protocol extensions generally benefit from community review; indeed, 186 review is often essential to avoid future interoperability problems 187 [PROTOCOL-EXT]. 189 When the name space is essentially unlimited and there are no 190 potential interoperability issues, assigned numbers can safely be 191 given out to anyone without any subjective review. In such cases, 192 IANA can make assignments directly, provided that IANA is given 193 specific instructions on what types of requests it should grant, and 194 what information must be provided as part of a well-formed request 195 for an assigned number. 197 3. Designated Experts 199 3.1. The Motivation For Designated Experts 201 It should be noted that IANA does not create or define assignment 202 policy itself; rather, it carries out policies that have been defined 203 by others and published in RFCs. IANA must be given a set of 204 guidelines that allow it to make allocation decisions with minimal 205 subjectivity and without requiring any technical expertise with 206 respect to the protocols that make use of a registry. 208 In many cases, some review of prospective allocations is appropriate, 209 and the question becomes who should perform the review and what is 210 the purpose of the review. One might think that an IETF Working 211 Group (WG) familiar with the name space at hand should be consulted. 212 In practice, however, WGs eventually disband, so they cannot be 213 considered a permanent evaluator. It is also possible for name spaces 214 to be created through individual submission documents, for which no 215 WG is ever formed. 217 One way to ensure community review of prospective assignments is to 218 have the requester submit a document for publication as an RFC. Such 219 an action helps ensure that the specification is publicly and 220 permanently available, and allows some review of the specification 221 prior to publication and assignment of the requested code points. 222 This is the preferred way of ensuring review, and is particularly 223 important if any potential interoperability issues can arise. For 224 example, some assignments are not just assignments, but also involve 225 an element of protocol specification. A new option may define fields 226 that need to be parsed and acted on, which (if specified poorly) may 227 not fit cleanly with the architecture of other options or the base 228 protocols on which they are built. 230 In some cases, however, the burden of publishing an RFC in order to 231 get an assignment is excessive. However, it is generally still useful 232 (and sometimes necessary) to discuss proposed additions on a mailing 233 list dedicated to the purpose (e.g., the ietf-types@iana.org for 234 media types) or on a more general mailing list (e.g., that of a 235 current or former IETF WG). Such a mailing list provides a way for 236 new registrations to be publicly reviewed prior to getting assigned, 237 or to give advice to persons wanting help in understanding what a 238 proper registration should contain. 240 While discussion on a mailing list can provide valuable technical 241 feedback, opinions may vary and discussions may continue for some 242 time without clear resolution. In addition, IANA cannot participate 243 in all of these mailing lists and cannot determine if or when such 244 discussions reach consensus. Therefore, IANA relies on a "designated 245 expert" for advice regarding the specific question of whether an 246 assignment should be made. The designated expert is an individual who 247 is responsible for carrying out an appropriate evaluation and 248 returning a recommendation to IANA. 250 It should be noted that a key motivation for having designated 251 experts is for the IETF to provide IANA with a subject matter expert 252 to whom the evaluation process can be delegated. IANA forwards 253 requests for an assignment to the expert for evaluation, and the 254 expert (after performing the evaluation) informs IANA whether or not 255 to make the assignment or registration. 257 3.2. The Role of the Designated Expert 259 The designated expert is responsible for initiating and coordinating 260 the appropriate review of an assignment request. The review may be 261 wide or narrow, depending to the situation and the judgment of the 262 designated expert. This may involve consultation with a set of 263 technology experts, discussion on a public mailing list, or 264 consultation with a working group (or its mailing list if the working 265 group has disbanded), etc. Ideally, the designated expert follows 266 specific review criteria as documented with the protocol that creates 267 or uses the namespace. (See the IANA Considerations sections of 268 [RFC3748,RFC3575] for examples that have been done for specific name 269 spaces). 271 Designated experts are expected to be able to defend their decisions 272 to the IETF community and the evaluation process is not intended to 273 be secretive or bestow unquestioned power on the expert. Experts are 274 expected to apply applicable documented review or vetting procedures, 275 or in the absence of documented criteria, follow generally-accepted 276 norms, e.g., those in section 3.3. 278 Section 5.2 discusses disputes and appeals in more detail. 280 Designated experts are appointed by the IESG (normally upon 281 recommendation by the relevant Area Director). They are typically 282 named at the time a document creating or updating a name space is 283 approved by the IESG, but as experts originally appointed may later 284 become unavailable, the IESG will appoint replacements if necessary. 286 Since the designated experts are appointed by the IESG, they may be 287 removed by the IESG. 289 3.3. Designated Expert Reviews 291 In the eight years since RFC 2434 was published and has been put to 292 use, experience has led to the following observations: 294 - a designated expert must respond in a timely fashion, normally 295 within a week for simple requests to a few weeks for more complex 296 ones. Unreasonable delays can cause significant problems for those 297 needing assignments, such as when products need code points to 298 ship. This is not to say that all reviews can be completed under a 299 firm deadline, but they must be started, and the requester and 300 IANA should have some transparency into the process if an answer 301 cannot be given quickly. 303 - if a designated expert does not respond to IANA's requests within 304 a reasonable period of time, either with a response, or with a 305 reasonable explanation for a delay (e.g., some requests may be 306 particularly complex), and if this is a recurring event, IANA must 307 raise the issue with the IESG. Because of the problems caused by 308 delayed evaluations and assignments, the IESG should take 309 appropriate actions to ensure that the expert understands and 310 accepts their responsibilities, or appoint a new expert. 312 - The designated expert is not required to personally bear the 313 burden of evaluating and deciding all requests, but acts as a 314 shepherd for the request, enlisting the help of others as 315 appropriate. In the case that a request is denied, and rejecting 316 the request is likely to be controversial, the expert should have 317 the support of other subject matter experts. That is, the expert 318 must be able to defend a decision to the community as a whole. 320 In the case where a designated expert is used, but there are no 321 specific documented criteria for performing an evaluation, the 322 presumption should be that a code point should be granted, unless 323 there is a compelling reason to the contrary. Possible reasons to 324 deny a request include: 326 - scarcity of codepoints, where the finite remaining codepoints 327 should be prudently managed, or when a request for a large number 328 of codepoints is made, when a single codepoint is the norm. 330 - documentation is not of sufficient clarity to evaluate or ensure 331 interoperability. 333 - the code point is needed for a protocol extension, but the 334 extension is not consistent with the documented (or generally 335 understood) architecture of the base protocol being extended, and 336 would be harmful to the protocol if widely deployed. It is not the 337 intent that "inconsistencies" refer to minor differences "of a 338 personal preference nature;" instead, they refer to significant 339 differences such as inconsistencies with the underlying security 340 model, implying a change to the semantics of an existing message 341 type or operation, requiring unwarranted changes in deployed 342 systems (compared with alternate ways of achieving a similar 343 result), etc. 345 - the extension would cause problems with existing deployed systems. 347 - the extension would conflict with one under active development by 348 the IETF, and having both would harm rather than foster 349 interoperability. 351 4. Creating A Registry 353 Creating a registry involves describing the name spaces to be 354 created, an initial set of assignments (if appropriate) and 355 guidelines on how future assignments are to be made. 357 4.1. Well-Known IANA Policy Definitions 359 The following are some defined policies, some of which are in use 360 today. These cover a range of typical policies that have been used to 361 date to describe the procedure for assigning new values in a name 362 space. It is not required that documents use these terms; the actual 363 requirement is that the instructions to IANA are clear and 364 unambiguous. However, use of these terms is RECOMMENDED where 365 possible, since their meaning is widely understood. 367 Private Use - For private or local use only, with the type and 368 purpose defined by the local site. No attempt is made to 369 prevent multiple sites from using the same value in 370 different (and incompatible) ways. There is no need for 371 IANA to review such assignments (since IANA does not record 372 them) and assignments are not generally useful for broad 373 interoperability. 375 Examples: Site-specific options in DHCP [DHCP-OPTIONS] have 376 significance only within a single site, "X-foo:" header 377 lines in email messages. 379 Experimental Use - Similar to private or local use only, with the 380 purpose being to facilitate experimentation. See 381 [EXPERIMENTATION] for details. 383 Hierarchical allocation - Delegated managers can assign values 384 provided they have been given control over that part of the 385 name space. IANA controls the higher levels of the 386 namespace according to one of the other policies. 388 Examples: DNS names, Object Identifiers, IP addresses 390 First Come First Served - Assignments are made to anyone on a 391 first come, first served basis. There is no substantive 392 review of the request, other than to ensure that it is 393 well-formed and doesn't duplicate an existing assignment. 394 However, requests must include a minimal amount of clerical 395 information, such as a a point of contact (including an 396 email address) and a brief description of how the value 397 will be used. Additional information specific to the type 398 of value requested may also need to be provided, as defined 399 by the name space. For numbers, the exact value is 400 generally assigned by IANA; with names, specific text 401 strings can usually be requested. 403 Examples: vnd. (vendor assigned) MIME types [MIME-REG]. 405 Expert Review (or Designated Expert) - approval by a Designated 406 Expert is required. The required documentation and review 407 criteria for use by the Designated Expert should be 408 provided when defining the registry. For example, see 409 Sections 6 and 7.2 in [RFC3748]. 411 Specification required - Values and their meaning must be 412 documented in an RFC or other permanent and readily 413 available public specification, in sufficient detail so 414 that interoperability between independent implementations 415 is possible. When used, Specification Required also implies 416 usage of a Designated Expert, who will review the public 417 specification and evaluate whether it is sufficiently clear 418 to allow interoperable implementations. The intention 419 behind "permanent and readily available" is that a document 420 can be reasonably be expected to easily be found long after 421 IANA assignment of the requested value. Publication of an 422 RFC is the ideal means of achieving this requirement. 424 Examples: SCSP [SCSP]. 426 RFC Required - RFC publication (either as IETF Submission or as an 427 RFC Editor submission [RFC3932]) suffices. Unless otherwise 428 specified, any type of RFC is sufficient (e.g., 429 Informational, Experimental, Standards Track, etc.) 431 IETF Review - (Formerly called "IETF Consensus" in [IANA- 432 CONSIDERATIONS]) New values are assigned only through RFCs 433 that have been shepherded through the IESG as AD-Sponsored 434 IETF (or WG) Documents [RFC3932,RFC3978]. The intention is 435 that the document and proposed assignment will be reviewed 436 by the IESG and appropriate IETF WGs (or experts, if 437 suitable working groups no longer exist) to ensure that the 438 proposed assignment will not negatively impact 439 interoperability or otherwise extend IETF protocols in an 440 inappropriate or damaging manner. 442 To ensure adequate community review, such documents are 443 shepherded through the IESG as AD-sponsored documents with 444 an IETF Last Call. 446 Examples: SMTP extensions [SMTP-EXT], BGP Subsequent 447 Address Family Identifiers [BGP4-EXT]. 449 Standards Action - Values are assigned only for Standards Track 450 RFCs approved by the IESG. 452 Examples: MIME top level types [MIME-REG]. 454 IESG Approval - New assignments may be approved by the IESG. 455 Although there is no requirement that the request be 456 documented in an RFC, the IESG has discretion to request 457 documents or other supporting materials on a case-by-case 458 basis. 460 IESG Approval is not intended to be used often or as a 461 "common case;" indeed, it has seldom been used in practice 462 during the period RFC 2434 was in effect. Rather, it is 463 intended to be available in conjunction with other policies 464 as a fall-back mechanism in the case where one of the other 465 allowable approval mechanisms cannot be employed in a 466 timely fashion or for some other compelling reason. IESG 467 Approval is not intended to circumvent the public review 468 processes implied by other policies that could have been 469 employed for a particular assignment. IESG Approval would 470 be appropriate, however, in cases where expediency is 471 desired and there is strong consensus for making the 472 assignment (e.g., WG consensus). 474 The following guidelines are suggested for any evaluation 475 under IESG Approval: 477 - The IESG can (and should) reject a request if another 478 path is available that is more appropriate and there is 479 no compelling reason to bypass normal community review. 481 - before approving a request, the community should be 482 consulted, via a "call for comments" that provides as 483 much information as is reasonably possible about the 484 request. 486 It should be noted that it often makes sense to partition a name 487 space into multiple categories, with assignments within each category 488 handled differently. For example, many protocols now partition name 489 spaces into two (or even more) parts, where one range is reserved for 490 Private or Experimental Use, while other ranges are reserved for 491 globally unique assignments assigned following some review process. 492 Dividing a name space into ranges makes it possible to have different 493 policies in place for different ranges. 495 4.2. What To Put In Documents That Create A Registry 497 The previous sections presented some issues that should be considered 498 in formulating a policy for assigning values in name spaces. It is 499 the Working Group and/or document author's job to formulate an 500 appropriate policy and specify it in the appropriate document. In 501 almost all cases, having an explicit "IANA Considerations" section is 502 appropriate. The following and later sections define what is needed 503 for the different types of IANA actions. 505 Documents that create a new name space (or modify the definition of 506 an existing space) and that expect IANA to play a role in maintaining 507 that space (e.g., serving as a repository for registered values) MUST 508 provide clear instructions on details of the name space. In 509 particular, instructions MUST include: 511 1) The name of the registry being created and/or maintained. The 512 name will appear on the IANA web page and will be referred to in 513 future documents that need to allocate a value from the new 514 space. The full name (and abbreviation, if appropriate) should 515 be provided. It is highly desirable that the chosen name not be 516 easily confusable with the name of another registry. 518 2) What information must be provided as part of a request in order 519 to assign a new value. This information may include the need to 520 document relevant security considerations, if any. 522 3) The review process that will apply to all future requests for a 523 value from the namespace. 525 Note: When a Designated Expert is used, documents MUST NOT name 526 the Designated Expert in the document itself; instead, the name 527 should be relayed to the appropriate Area Director at the time 528 the document is sent to the IESG for approval. 530 If the request should also be reviewed on a specific public 531 mailing list (such as the ietf-types@iana.org for media types), 532 that mailing address should be specified. Note, however, that 533 when mailing lists are specified, the requirement for a 534 Designated Expert MUST also be specified (see Section 3). 536 If IANA is expected to make assignments without requiring an 537 outside review, sufficient guidance MUST be provided so that the 538 requests can be evaluated with minimal subjectivity. 540 4) The size and format of registry entries. When creating a new 541 name/number space, authors must specify the size of the registry 542 or sub-registry as well as the exact format for recording 543 registry values. For number assignments, one should specify 544 whether values are to be recorded in decimal, hexadecimal or 545 some other format. For strings, the encoding format should be 546 specified (e.g., ASCII, UTF8, etc.) Authors should also clear 547 specify what fields to record in the registry. 549 5) Initial assignments and reservations. Clear instructions should 550 be provided to identify any initial assignments or 551 registrations. In addition, any ranges that are to be reserved 552 for "Private Use", "Reserved", "Unassigned", etc. should be 553 clearly indicated. 555 When specifying the process for making future assignments, it is 556 quite acceptable to pick one (or more) of the example policies listed 557 in Section 4.1 and refer to it by name. Indeed, this is the 558 preferred mechanism in those cases where the sample policies provide 559 the desired level of review. It is also acceptable to cite one of the 560 above policies and include additional guidelines for what kind of 561 considerations should be taken into account by the review process. 562 For example, RADIUS [RFC3575] specifies the use of a Designated 563 Expert, but includes specific additional criteria the Designated 564 Expert should follow. 566 For example, a document could say something like: 568 This document defines a new DHCP option, entitled "FooBar" (see 569 Section y), assigned a value of TBD1 from the DCHP Option space 570 [RFCXXX]. The FooBar option also defines an 8-bit FooType field, 571 for which IANA is to create and maintain a registry entitled 572 "FooType values". Initial values for the DHCP FooBar FooType 573 registry are given below; future assignments are to be made 574 through Expert Review [IANA-CONSIDERATIONS]. Assignments consist 575 of a DHCP FooBar FooType name and its associated value. 577 DHCP FooBar FooType Name Value Definition 578 ------------------------ ---------- 579 Frobnitz 1 See Section y.1 580 NitzFrob 2 See Section y.2 582 For examples of documents that provide good and detailed guidance to 583 IANA on the issue of assigning numbers, consult [MIME-LANG, RFC3757, 584 RFC3749, RFC3575, RFC3968]. 586 4.3. Updating IANA Guidelines For Existing Registries 588 Updating the registration process for an already existing (i.e., 589 previously created) name space (whether created explicitly or 590 implicitly) follows a process similar to that used when creating a 591 new namespace. That is, a document is produced that makes reference 592 to the existing namespace and then provides detailed guidelines for 593 handling assignments in each individual name space. Such documents 594 are normally processed as BCPs [IETF-PROCESS]. 596 Example documents that updated the guidelines for managing (then) 597 pre-existing registries include: [RFC2929,RFC3228,RFC3575]. 599 5. Registering New Values In An Existing Registry 601 5.1. What to Put In Documents When Registering Values 603 Often, documents request an assignment from an already existing name 604 space (i.e., one created by a previously-published RFC). In such 605 cases: 607 - Documents should clearly identify the name space in which each 608 value is to be registered. If the registration goes into a sub- 609 registry, the author should clearly describe where the assignment 610 or registration should go. It is helpful to use the exact name 611 space name as listed on the IANA web page (and defining RFC), and 612 cite the RFC where the name space is defined. (Note: There is no 613 need to mention what the assignment policy for new assignments is, 614 as that should be clear from the references.) 616 - Each value requested should be given a unique reference. When the 617 value is numeric, use the notation: TBD1, TBD2, etc. Throughout 618 the document where an actual IANA-assigned value should be filled 619 in, use the "TBDx" notation. This helps ensure that the final RFC 620 has the correct assigned values inserted in in all of the relevant 621 places where the value is expected to appear in the final 622 document. For values that are text strings, a specific name can be 623 suggested. IANA will normally assign the name, unless it conflicts 624 with a name already in use. 626 - Normally, the values to be used are chosen by IANA and documents 627 should specify values of "TBD". However, in some cases a value may 628 have been used for testing or in early implementations. In such 629 cases, it is acceptable to include text suggesting what specific 630 value should be used (together with the reason for the choice). 631 For example, one might include the text "the value XXX is 632 suggested as it is used in implementations". However, it should be 633 noted that suggested values are just that; IANA will attempt to 634 assign them, but may find that impossible, if the proposed number 635 has already been assigned for some other use. 637 For some registries, IANA has a longstanding policy prohibiting 638 assignment of names or codes on a vanity or organization name 639 basis, e.g., codes are always assigned sequentially unless there 640 is a strong reason for making an exception. Nothing in this 641 document is intended to change those policies or prevent their 642 future application. 644 - The IANA Considerations section should summarize all of the IANA 645 actions, with pointers to the relevant sections elsewhere in the 646 document as appropriate. When multiple values are requested, it is 647 generally helpful to include a summary table. It is also helpful 648 for this table to be in the same format as it should appear on the 649 IANA web site. 651 Note: in cases where authors feel that including the full table is 652 too verbose or repetitive, authors should still include the table, 653 but may include a note asking the table be removed prior to 654 publication of the final RFC. 656 As an example, the following text could be used to request assignment 657 of a DHCPv6 option number: 659 IANA has assigned an option code value of TBD1 to the DNS 660 Recursive Name Server option and an option code value of TBD2 to 661 the Domain Search List option from the DHCP option code space 662 defined in section 24.3 of RFC 3315. 664 5.2. Updating Registrations 666 Registrations are a request to assign a new value, including the 667 related information needed to evaluate and document the request. Even 668 after a number has been assigned, some types of registrations contain 669 additional information that may need to be updated over time. For 670 example, MIME types, character sets, language tags, etc. typically 671 include more information than just the registered value itself. 673 Example information can include point of contact information, 674 security issues, pointers to updates, literature references, etc. In 675 such cases, the document defining the namespace must clearly state 676 who is responsible for maintaining and updating a registration. In 677 different cases, it may be appropriate to specify one or more of the 678 following: 680 - Let the author update the registration, subject to the same 681 constraints and review as with new registrations. 683 - Allow some mechanism to attach comments to the registration, for 684 cases where others have significant objections to claims in a 685 registration, but the author does not agree to change the 686 registration. 688 - Designate the IESG, a Designated Expert or another entity as 689 having the right to change the registrant associated with a 690 registration and any requirements or conditions on doing so. 691 This is mainly to get around the problem when a registrant 692 cannot be reached in order to make necessary updates. 694 5.3. Overriding Registration Procedures 696 Since RFC 2434 was published, experience has shown that the 697 documented IANA considerations for individual protocols do not always 698 adequately cover the reality after the protocol is deployed. For 699 example, many older routing protocols do not have documented, 700 detailed IANA considerations. In addition, documented IANA 701 considerations are sometimes found to be too stringent to allow even 702 working group documents (for which there is strong consensus) to 703 obtain code points from IANA in advance of actual RFC publication. 704 In other cases, the documented procedures are unclear or neglected to 705 cover all the cases. In order to allow assignments in individual 706 cases where there is strong IETF consensus that an allocation should 707 go forward, but the documented procedures do not support such an 708 assignment, the IESG is granted authority to approve assignments in 709 such cases. The intention is not to overrule properly documented 710 procedures, or to obviate the need for protocols to properly document 711 their IANA Considerations. Instead, the intention is to permit 712 assignments in individual cases where it is obvious that the 713 assignment should just be made, but updating the IANA process just to 714 assign a particular code point is viewed as too heavy a burden. 716 In general, the IETF would like to see deficient IANA registration 717 procedures for a namespace revised through the IETF standards 718 process, but not at the cost of unreasonable delay for needed 719 assignments. If the IESG has had to take the action in this section, 720 it is a strong indicator that the IANA registration procedures should 721 be updated, possibly in parallel with ongoing protocol work. 723 6. Miscellaneous Issues 725 6.1. When There Are No IANA Actions 727 Before an Internet-Draft can be published as an RFC, IANA needs to 728 know what actions (if any) it needs to perform. Experience has shown 729 that it is not always immediately obvious whether a document has no 730 IANA actions, without reviewing a document in some detail. In order 731 to make it clear to IANA that it has no actions to perform (and that 732 the author has consciously made such a determination!), such 733 documents should include an IANA Considerations section that states: 735 This document has no IANA Actions. 737 This statement, or an equivalent form of words, must only be inserted 738 after the WG or individual submitter has carefully verified it to be 739 true. Using such wording as a matter of "boilerplate" or without 740 careful consideration can lead to incomplete or incorrect IANA 741 actions being performed. 743 If a specification makes use of values from a name space that is not 744 managed by IANA, it may be useful to note this fact, e.g., with 745 wording such as: 747 The values of the Foobar parameter are assigned by the Barfoo 748 registry on behalf of the Rabfoo Forum. Therefore, this document 749 has no IANA Actions. 751 In some cases, the absence of IANA-assigned values may be considered 752 valuable information for future readers; in other cases it may be 753 considered of no value once the document has been approved, and may 754 be removed before archival publication. This choice should be made 755 clear in the draft, for example by including a sentence such as 757 [RFC Editor: please remove this section prior to publication.] 759 or 761 [RFC Editor: please do not remove this section.] 763 6.2. Namespaces Lacking Documented Guidance 765 For all existing RFCs that either explicitly or implicitly rely on 766 IANA to evaluate assignments without specifying a precise evaluation 767 policy, IANA (in consultation with the IESG) will continue to decide 768 what policy is appropriate. Changes to existing policies can always 769 be initiated through the normal IETF consensus process. 771 All future RFCs that either explicitly or implicitly rely on IANA to 772 register or otherwise manage name space assignments MUST provide 773 guidelines for managing the name space. 775 6.3. After-The-Fact Registrations 777 Occasionally, IANA becomes aware that an unassigned value from a 778 managed name space is in use on the Internet, or that an assigned 779 value is being used for a different purpose than originally 780 registered. IANA will not condone such misuse, i.e., procedures of 781 the type described in this document MUST be applied to such cases. In 782 the absence of specifications to the contrary, values may only be 783 reassigned for a different purpose with the consent of the original 784 assignee (when possible) and with due consideration of the impact of 785 such a reassignment. 787 6.4. Reclaiming Assigned Values 789 Reclaiming previously-assigned values for reuse is tricky, because 790 doing so can lead to interoperability problems with deployed systems 791 still using the assigned values. Moreover, it can be extremely 792 difficult to determine the extent of deployment of systems making use 793 of a particular value. However, in cases where the name space is 794 running out of unassigned values and additional ones are needed, it 795 may be desirable to attempt to reclaim unused values. When reclaiming 796 unused values, the following (at a minimum) should be considered: 798 - attempts should be made to contact the original party to which a 799 value is assigned, to determine if the value was ever used, and if 800 so, the extent of deployment. (In some cases, products were never 801 shipped or have long ceased being used. In other cases, it may be 802 known that a value was never actually used at all.) 804 - reassignments should not normally be made without the concurrence 805 of the original requester. Reclamation under such conditions 806 should only take place where there is strong evidence that a value 807 is not widely used, and the need to reclaim the value outweighs 808 the cost of a hostile reclamation. In any case, IESG approval is 809 needed in this case. 811 - it may be appropriate to write up the proposed action and solicit 812 comments from relevant user communities. In some cases, it may be 813 appropriate to write an RFC that goes through a formal IETF 814 process (including IETF Last Call) as was done when DHCP reclaimed 815 some of its "Private Use" options [RFC3942] 817 7. Appeals 819 Appeals on registration decisions made by IANA can be appealed using 820 the normal IETF appeals process as described in Section 6.5 of 821 [IETF-PROCESS]. Specifically, appeals should be directed to the IESG, 822 followed (if necessary) by an appeal to the IAB, etc. 824 8. Mailing Lists 826 All IETF mailing lists associated with evaluating or discussing 827 assignment requests as described in this document are subject to 828 whatever rules of conduct and methods of list management are 829 currently defined by Best Current Practices or by IESG decision. 831 9. Security Considerations 833 Information that creates or updates a registration needs to be 834 authenticated and authorized. IANA updates registries according to 835 instructions in published RFCs and from the IESG. It also may accept 836 clarifications from document authors, relevant WG chairs, Designated 837 Experts and mail list participants too. 839 Information concerning possible security vulnerabilities of a 840 protocol may change over time. Likewise, security vulnerabilities 841 related to how an assigned number is used (e.g., if it identifies a 842 protocol) may change as well. As new vulnerabilities are discovered, 843 information about such vulnerabilities may need to be attached to 844 existing registrations, so that users are not mislead as to the true 845 security issues surrounding the use of a registered number. 847 An analysis of security issues is required for all parameters (data 848 types, operation codes, keywords, etc.) used in IETF protocols or 849 registered by IANA. All descriptions of security issues must be as 850 accurate as possible regardless of level of registration. In 851 particular, a statement that there are "no security issues associated 852 with this type" must not be given when it would be more accurate to 853 state that "the security issues associated with this type have not 854 been assessed". 856 It is the responsibility of the IANA Considerations associated with a 857 particular registry to specify what (if any) security considerations 858 must be provided when assigning new values. 860 10. Changes Relative to RFC 2434 862 Changes include: 864 - Major reordering of text to group the "creation of registries" 865 text in same section, etc. 867 - Numerous editorial changes to improve readability. 869 - Change "IETF Consensus" term to "IETF Review" and added more 870 clarifications. (History has shown that people see the words "IETF 871 Consensus" and know what that means; in contrast, the term has a 872 specific definition within this document.) 874 - Added "RFC Required" to list of defined policies. 876 - Much more explicit directions and examples of "what to put in 877 RFCs". 879 - "Specification Required" now implies use of Designated Expert to 880 evaluate specs for sufficient clarity. 882 - Significantly changed the wording in Section 3. Main purpose is to 883 make clear that Expert Reviewers are accountable to the community, 884 and to provide some guidance for review criteria in the default 885 case. 887 - removed wording: "By virtue of the IAB's role as overseer of IANA 888 administration [RFC 1602], the IAB's decision is final [IETF- 889 PROCESS]." This document now makes no changes to existing appeal 890 mechanisms relative to RFC 2026. 892 - Added section about reclaiming unused value. 894 - Added a section on after-the-fact registrations. 896 - no doubt other things... 898 [RFC Editor: please remove the "changes relative to individual 899 drafts" below upon publication.] 901 10.1. Changes Relative to -00 903 - Revised Section 5.3 to try and make it even more clear. 905 10.2. Changes Relative to -02 907 - Significantly changed the wording in Section 3. Main purpose is 908 to make clear the Expert Reviewers are accountable to the com- 909 munity, and to provide some guidance for review criteria in the 910 default case. 912 - removed wording: "By virtue of the IAB's role as overseer of 913 IANA administration [RFC 1602], the IAB's decision is final 914 [IETF-PROCESS]." This document now makes no changes to existing 915 appeal mechanisms relative to RFC 2026. 917 11. IANA Considerations 919 This document is all about IANA Considerations. 921 12. Acknowledgments 923 This document has benefited from specific feedback from Marcelo 924 Bagnulo Braun, Brian Carpenter, Barbara Denny, Spencer Dawkins, Paul 925 Hoffman, John Klensin, Allison Mankin, Mark Townsley and Bert Wijnen. 927 The original acknowledgments section in RFC 2434 was: 929 Jon Postel and Joyce Reynolds provided a detailed explanation on what 930 IANA needs in order to manage assignments efficiently, and patiently 931 provided comments on multiple versions of this document. Brian 932 Carpenter provided helpful comments on earlier versions of the 933 document. One paragraph in the Security Considerations section was 934 borrowed from [MIME-REG]. 936 13. Normative References 937 14. Informative References 939 [ASSIGNED] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, 940 RFC 1700, October 1994. See also: 941 http://www.iana.org/numbers.html 943 [BGP4-EXT] Bates. T., Chandra, R., Katz, D. and Y. Rekhter, 944 "Multiprotocol Extensions for BGP-4", RFC 2283, 945 February 1998. 947 [DHCP-OPTIONS] Alexander, S. and R. Droms, "DHCP Options and BOOTP 948 Vendor Extensions", RFC 2132, March 1997. 950 [EXPERIMENTATION] "Assigning Experimental and Testing Numbers 951 Considered Useful". T. Narten, RFC 3692, January 952 2004. 954 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 955 Writing an IANA Considerations Section in RFCs", BCP 956 26, RFC 2434, October 1998. 958 [IANA-MOU] Memorandum of Understanding Concerning the Technical Work 959 of the Internet Assigned Numbers Authority. B. 960 Carpenter, F. Baker, M. Roberts, RFC 2860, June 961 2000. 963 [IETF-PROCESS] Bradner, S., "The Internet Standards Process -- 964 Revision 3", BCP 9, RFC 2026, October 1996. 966 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 968 [IPSEC] S. Kent, K. Seo., "Security Architecture for the Internet 969 Protocol", RFC 4301, December 2005. 971 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 972 Requirement Levels", BCP 14, RFC 2119, March 1997. 974 [MIME-LANG] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 975 Word Extensions: Character Sets, Languages, and 976 Continuations", RFC 2184, August 1997. 978 [MIME-REG] Freed, N., Klensin, J. and J. Postel, "Multipurpose 979 Internet Mail Extension (MIME) Part Four: 980 Registration Procedures", RFC 2048, November 1996. 982 [SCSP] Luciani, J., Armitage, G. and J. Halpern, "Server Cache 983 Synchronization Protocol (SCSP)", RFC 2334, April 984 1998. 986 [SMTP-EXT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. 987 Crocker, "SMTP Service Extensions", RFC 1869, 988 November 1995. 990 [PROTOCOL-EXT] "Procedures for protocol extensions and variations", 991 draft-carpenter-protocol-extensions-01.txt 993 [RFC2929] Domain Name System (DNS) IANA Considerations. D. Eastlake 994 3rd, E. Brunner-Williams, B. Manning. September 995 2000. 997 [RFC3228] IANA Considerations for IPv4 Internet Group Management 998 Protocol (IGMP). B. Fenner. February 2002. 1000 [RFC3575] IANA Considerations for RADIUS (Remote Authentication Dial 1001 In User Service). B. Aboba. RFC 3575, July 2003. 1003 [RFC3748] Extensible Authentication Protocol (EAP), B. Aboba, L. 1004 Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, 1005 Ed., RFC 3748, June, 2004. 1007 [RFC3978] IETF Rights in Contributions. S. Bradner, Ed.. March 2005. 1009 [RFC3575] IANA Considerations for RADIUS (Remote Authentication Dial 1010 In User Service). B. Aboba. July 2003. 1012 [RFC3748] Extensible Authentication Protocol (EAP). B. Aboba, L. 1013 Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, 1014 Ed.. June 2004. 1016 [RFC3932] The IESG and RFC Editor Documents: Procedures. H. 1017 Alvestrand. October 2004. 1019 [RFC3942] "Reclassifying Dynamic Host Configuration Protocol version 1020 4 (DHCPv4) Options", B. Volz. RFC 3942, November 1021 2004 1023 [RFC3968] "The Internet Assigned Number Authority (IANA) Header Field 1024 Parameter Registry for the Session Initiation 1025 Protocol (SIP)," G. Camarillo. RFC 3968, December 1026 2004. 1028 15. Authors' Addresses 1030 Thomas Narten 1031 IBM Corporation 1032 3039 Cornwallis Ave. 1033 PO Box 12195 - BRQA/502 1034 Research Triangle Park, NC 27709-2195 1036 Phone: 919-254-7798 1037 EMail: narten@us.ibm.com 1039 Harald Tveit Alvestrand 1040 Google 1041 Beddingen 10 1042 Trondheim, 7014 1043 Norway 1045 Email: Harald@Alvestrand.no 1047 Intellectual Property Statement 1049 The IETF takes no position regarding the validity or scope of any 1050 Intellectual Property Rights or other rights that might be claimed to 1051 pertain to the implementation or use of the technology described in 1052 this document or the extent to which any license under such rights 1053 might or might not be available; nor does it represent that it has 1054 made any independent effort to identify any such rights. Information 1055 on the procedures with respect to rights in RFC documents can be 1056 found in BCP 78 and BCP 79. 1058 Copies of IPR disclosures made to the IETF Secretariat and any 1059 assurances of licenses to be made available, or the result of an 1060 attempt made to obtain a general license or permission for the use of 1061 such proprietary rights by implementers or users of this 1062 specification can be obtained from the IETF on-line IPR repository at 1063 http://www.ietf.org/ipr. 1065 The IETF invites any interested party to bring to its attention any 1066 copyrights, patents or patent applications, or other proprietary 1067 rights that may cover technology that may be required to implement 1068 this standard. Please address the information to the IETF at ietf- 1069 ipr@ietf.org. 1071 Copyright Statement 1073 Copyright (C) The IETF Trust (2007). 1075 This document is subject to the rights, licenses and restrictions 1076 contained in BCP 78, and except as set forth therein, the authors 1077 retain all their rights. 1079 This document and the information contained herein are provided on an 1080 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1081 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1082 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1083 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1084 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1085 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.