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