idnits 2.17.00 (12 Aug 2021) /tmp/idnits11660/draft-leiba-cotton-iana-5226bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' their IANA considerations. Instead, the intention is to permit' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 1, 2012) is 3579 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'BCP26' is mentioned on line 888, but not defined == Missing Reference: 'RFC9876' is mentioned on line 1128, but not defined == Outdated reference: draft-iab-extension-recs has been published as RFC 6709 -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6195 (Obsoleted by RFC 6895) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Cotton 3 Internet-Draft Internet Assigned Numbers 4 Obsoletes: 5226 (if approved) Authority (IANA) 5 Intended status: BCP B. Leiba 6 Expires: February 2, 2013 Huawei Technologies 7 T. Narten 8 IBM Corporation 9 August 1, 2012 11 Guidelines for Writing an IANA Considerations Section in RFCs 12 draft-leiba-cotton-iana-5226bis-00 14 Abstract 16 Many protocols make use of identifiers consisting of constants and 17 other well-known values. Even after a protocol has been defined and 18 deployment has begun, new values may need to be assigned (such as for 19 a new option type in DHCP, or a new encryption or authentication 20 transform for IPsec). To ensure that such quantities have consistent 21 values and interpretations across all implementations, their 22 assignment must be administered by a central authority. For IETF 23 protocols, that role is provided by the Internet Assigned Numbers 24 Authority (IANA). 26 In order for IANA to manage a given namespace prudently, it needs 27 guidelines describing the conditions under which new values can be 28 assigned or when modifications to existing values can be made. If 29 IANA is expected to play a role in the management of a namespace, 30 IANA must be given clear and concise instructions describing that 31 role. This document discusses issues that should be considered in 32 formulating a policy for assigning values to a namespace and provides 33 guidelines for authors on the specific text that must be included in 34 documents that place demands on IANA. 36 This document obsoletes RFC 5226. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on February 2, 2013. 55 Copyright Notice 57 Copyright (c) 2012 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.1. Terminology Used In This Document . . . . . . . . . . . . 5 74 2. Why Management of a Namespace May Be Necessary . . . . . . . . 6 75 3. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 7 76 3.1. The Motivation for Designated Experts . . . . . . . . . . 7 77 3.2. The Role of the Designated Expert . . . . . . . . . . . . 8 78 3.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 9 79 3.4. Expert Reviews and the Document Lifecycle . . . . . . . . 10 80 4. Creating a Registry . . . . . . . . . . . . . . . . . . . . . 11 81 4.1. Well-Known IANA Policy Definitions . . . . . . . . . . . . 11 82 4.1.1. Policy: Private Use . . . . . . . . . . . . . . . . . 12 83 4.1.2. Policy: Experimental Use . . . . . . . . . . . . . . . 12 84 4.1.3. Policy: Hierarchical Allocation . . . . . . . . . . . 13 85 4.1.4. Policy: First Come First Served . . . . . . . . . . . 13 86 4.1.5. Policy: Expert Review . . . . . . . . . . . . . . . . 13 87 4.1.6. Policy: Specification Required . . . . . . . . . . . . 14 88 4.1.7. Policy: RFC Required . . . . . . . . . . . . . . . . . 14 89 4.1.8. Policy: IETF Review . . . . . . . . . . . . . . . . . 14 90 4.1.9. Policy: Standards Action . . . . . . . . . . . . . . . 15 91 4.1.10. Policy: IESG Approval . . . . . . . . . . . . . . . . 15 92 4.2. Best Practice for Selecting an Appropriate Policy . . . . 16 93 4.3. What to Put in Documents That Create a Registry . . . . . 19 94 4.4. Updating IANA Guidelines for Existing Registries . . . . . 21 95 5. Registering New Values in an Existing Registry . . . . . . . . 22 96 5.1. What to Put in Documents When Registering Values . . . . . 22 97 5.2. Updating Registrations . . . . . . . . . . . . . . . . . . 23 98 5.3. Overriding Registration Procedures . . . . . . . . . . . . 24 99 6. Documentation References in IANA Registries . . . . . . . . . 25 100 7. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 25 101 8. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 26 102 8.1. When There Are No IANA Actions . . . . . . . . . . . . . . 26 103 8.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 27 104 8.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 27 105 8.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 28 106 8.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 28 107 8.6. BCP 78/79 Issues in Registries . . . . . . . . . . . . . . 29 108 9. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 109 10. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 29 110 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 111 12. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 30 112 12.1. 2012: Changes in This Document Relative to RFC 5226 . . . 30 113 12.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . . 31 114 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 115 13.1. Acknowledgments for This Document (2012) . . . . . . . . . 31 116 13.2. Acknowledgments from the second edition (2008) . . . . . . 32 117 13.3. Acknowledgments from the first edition (1998) . . . . . . 32 119 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 120 14.1. Normative References . . . . . . . . . . . . . . . . . . . 32 121 14.2. Informative References . . . . . . . . . . . . . . . . . . 32 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 124 1. Introduction 126 Many protocols make use of fields that contain constants and other 127 well-known values (such as the Protocol field in the IP header 128 [RFC0791] and MIME media types [RFC4288]). Even after a protocol has 129 been defined and deployment has begun, new values may need to be 130 assigned (such as a new option type in DHCP [RFC2132] or a new 131 encryption or authentication transform for IPsec [RFC4301]). To 132 ensure that such fields have consistent values and interpretations in 133 different implementations, their assignment must be administered by a 134 central authority. For IETF protocols, that role is provided by the 135 Internet Assigned Numbers Authority (IANA) [RFC2860]. 137 In this document, we call the set of possible values for such a field 138 a "namespace"; its actual value may be a text string, a number, or 139 another kind of value. The binding or association of a specific 140 value with a particular purpose within a namespace is called an 141 assigned number (or assigned value, or sometimes a "code point", 142 "protocol constant", or "protocol parameter"). Each assignment of a 143 value in a namespace is called a registration. 145 In order for IANA to manage a given namespace prudently, it needs 146 guidelines describing the conditions under which new values should be 147 assigned or when (and how) modifications to existing values can be 148 made. This document provides guidelines to authors on what sort of 149 text should be added to their documents in order to provide IANA 150 clear guidelines, and it reviews issues that should be considered in 151 formulating an appropriate policy for assigning numbers to name 152 spaces. 154 Not all namespaces require centralized administration. In some 155 cases, it is possible to delegate a namespace in such a way that 156 further assignments can be made independently and with no further 157 (central) coordination. In the Domain Name System, for example, IANA 158 only deals with assignments at the higher levels, while subdomains 159 are administered by the organization to which the space has been 160 delegated. As another example, Object Identifiers (OIDs) as defined 161 by the ITU are also delegated [RFC3232]; IANA manages the subtree 162 rooted at "iso.org.dod.internet" (1.3.6.1) . When a namespace is 163 delegated, the scope of IANA is limited to the parts of the namespace 164 where IANA has authority. 166 1.1. Terminology Used In This Document 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC 2119 [RFC2119]. 171 For this document, "the specification" as used by RFC 2119 refers to 172 the processing of protocol documents within the IETF standards 173 process. 175 2. Why Management of a Namespace May Be Necessary 177 One issue to consider in managing a namespace is its size. If the 178 space is small and limited in size, assignments must be made 179 carefully to prevent exhaustion of the space. If the space is 180 essentially unlimited, on the other hand, potential exhaustion will 181 probably not be a practical concern at all. Even when the space is 182 essentially unlimited, however, it is usually desirable to have at 183 least a minimal review prior to assignment in order to: 185 o prevent the hoarding of or unnecessary wasting of values. For 186 example, if the space consists of text strings, it may be 187 desirable to prevent entities from obtaining large sets of strings 188 that correspond to desirable names (existing company names, for 189 example). 191 o provide a sanity check that the request actually makes sense and 192 is necessary. Experience has shown that some level of minimal 193 review from a subject matter expert is useful to prevent 194 assignments in cases where the request is malformed or not 195 actually needed (for example, an existing assignment for an 196 essentially equivalent service already exists). 198 A second consideration is whether it makes sense to delegate the 199 namespace in some manner. This route should be pursued when 200 appropriate, as it lessens the burden on IANA for dealing with 201 assignments. 203 A third, and perhaps most important, consideration concerns potential 204 impact on the interoperability of unreviewed extensions. Proposed 205 protocol extensions generally benefit from community review; indeed, 206 review is often essential to avoid future interoperability problems 207 [I-D.iab-extension-recs]. 209 When the namespace is essentially unlimited and there are no 210 potential interoperability issues, assigned numbers can safely be 211 given out to anyone without any subjective review. In such cases, 212 IANA can make assignments directly, provided that IANA is given 213 specific instructions on what types of requests it should grant, and 214 what information must be provided as part of a well-formed request 215 for an assigned number. 217 3. Designated Experts 219 3.1. The Motivation for Designated Experts 221 It should be noted that IANA does not create or define assignment 222 policy itself; rather, it carries out policies that have been defined 223 by others and published in RFCs. IANA must be given a set of 224 guidelines that allow it to make allocation decisions with minimal 225 subjectivity and without requiring any technical expertise with 226 respect to the protocols that make use of a registry. 228 In many cases, some review of prospective allocations is appropriate, 229 and the question becomes who should perform the review and what is 230 the purpose of the review. One might think that an IETF working 231 group familiar with the namespace at hand should be consulted. In 232 practice, however, working groups eventually disband, so they cannot 233 be considered a permanent evaluator. It is also possible for 234 namespaces to be created through individual submission documents, for 235 which no working group is ever formed. 237 One way to ensure community review of prospective assignments is to 238 have the requester submit a document for publication as an RFC. Such 239 an action helps ensure that the specification is publicly and 240 permanently available, and it allows some review of the specification 241 prior to publication and assignment of the requested code points. 242 This is the preferred way of ensuring review, and is particularly 243 important if any potential interoperability issues can arise. For 244 example, some assignments are not just assignments, but also involve 245 an element of protocol specification. A new option may define fields 246 that need to be parsed and acted on, which (if specified poorly) may 247 not fit cleanly with the architecture of other options or the base 248 protocols on which they are built. 250 In some cases, however, the burden of publishing an RFC in order to 251 get an assignment is excessive. However, it is generally still 252 useful (and sometimes necessary) to discuss proposed additions on a 253 mailing list dedicated to the purpose (such as the 254 media-types@iana.org for media types) or on a more general mailing 255 list (such as that of a current or former IETF working group). Such 256 a mailing list provides a way for new registrations to be publicly 257 reviewed prior to getting assigned, or gives advice to persons 258 wanting help in understanding what a proper registration should 259 contain. 261 While discussion on a mailing list can provide valuable technical 262 feedback, opinions may vary and discussions may continue for some 263 time without clear resolution. In addition, IANA cannot participate 264 in all of these mailing lists and cannot determine if or when such 265 discussions reach consensus. Therefore, IANA relies on a "designated 266 expert" for advice regarding the specific question of whether an 267 assignment should be made. The designated expert is an individual 268 who is responsible for carrying out an appropriate evaluation and 269 returning a recommendation to IANA. 271 It should be noted that a key motivation for having designated 272 experts is for the IETF to provide IANA with a subject matter expert 273 to whom the evaluation process can be delegated. IANA forwards 274 requests for an assignment to the expert for evaluation, and the 275 expert (after performing the evaluation) informs IANA as to whether 276 or not to make the assignment or registration. 278 3.2. The Role of the Designated Expert 280 The designated expert is responsible for initiating and coordinating 281 the appropriate review of an assignment request. The review may be 282 wide or narrow, depending on the situation and the judgment of the 283 designated expert. This may involve consultation with a set of 284 technology experts, discussion on a public mailing list, consultation 285 with a working group (or its mailing list if the working group has 286 disbanded), etc. Ideally, the designated expert follows specific 287 review criteria as documented with the protocol that creates or uses 288 the namespace. See the IANA Considerations sections of [RFC3748] and 289 [RFC3575] for examples that have been done for specific namespaces. 291 Designated experts are expected to be able to defend their decisions 292 to the IETF community, and the evaluation process is not intended to 293 be secretive or bestow unquestioned power on the expert. Experts are 294 expected to apply applicable documented review or vetting procedures, 295 or in the absence of documented criteria, follow generally accepted 296 norms such as those in Section 3.3. 298 Section 5.2 discusses disputes and appeals in more detail. 300 Designated experts are appointed by the IESG (normally upon 301 recommendation by the relevant Area Director). They are typically 302 named at the time a document creating or updating a namespace is 303 approved by the IESG, but as experts originally appointed may later 304 become unavailable, the IESG will appoint replacements if necessary. 306 For some registries, it has proven useful to have multiple designated 307 experts. Sometimes those experts work together in evaluating a 308 request, while in other cases additional experts serve as backups. 309 In cases of disagreement among those experts, it is the 310 responsibility of those experts to make a single clear recommendation 311 to IANA. It is not appropriate for IANA to resolve disputes among 312 experts. In extreme situations, such as deadlock, the IESG may need 313 to step in to resolve the problem. 315 In registries where a pool of experts evaluates requests, the pool 316 should have a single chair responsible for defining how requests are 317 to be assigned to and reviewed by experts. In some cases, the expert 318 pool may consist of a primary and backups, with the backups involved 319 only when the primary expert is unavailable. In other cases, IANA 320 might assign requests to individual members in sequential or 321 approximate random order. In the event that IANA finds itself having 322 received conflicting advice from its experts, it is the 323 responsibility of the pool's chair to resolve the issue and provide 324 IANA with clear instructions. 326 Since the designated experts are appointed by the IESG, they may be 327 removed by the IESG. 329 3.3. Designated Expert Reviews 331 In the years since RFC 2434 was published and has been put to use, 332 experience has led to the following observations: 334 o A designated expert must respond in a timely fashion, normally 335 within a week for simple requests to a few weeks for more complex 336 ones. Unreasonable delays can cause significant problems for 337 those needing assignments, such as when products need code points 338 to ship. This is not to say that all reviews can be completed 339 under a firm deadline, but they must be started, and the requester 340 and IANA should have some transparency into the process if an 341 answer cannot be given quickly. 343 o If a designated expert does not respond to IANA's requests within 344 a reasonable period of time, either with a response or with a 345 reasonable explanation for the delay (some requests may be 346 particularly complex), and if this is a recurring event, IANA must 347 raise the issue with the IESG. Because of the problems caused by 348 delayed evaluations and assignments, the IESG should take 349 appropriate actions to ensure that the expert understands and 350 accepts his or her responsibilities, or appoint a new expert. 352 o The designated expert is not required to personally bear the 353 burden of evaluating and deciding all requests, but acts as a 354 shepherd for the request, enlisting the help of others as 355 appropriate. In the case that a request is denied, and rejecting 356 the request is likely to be controversial, the expert should have 357 the support of other subject matter experts. That is, the expert 358 must be able to defend a decision to the community as a whole. 360 When a designated expert is used, the documentation should give clear 361 guidance to the designated expert, laying out criteria for performing 362 an evaluation and reasons for rejecting a request. In the case where 363 there are no specific documented criteria, the presumption should be 364 that a code point should be granted unless there is a compelling 365 reason to the contrary. Possible reasons to deny a request include 366 these: 368 o Scarcity of code points, where the finite remaining code points 369 should be prudently managed, or when a request for a large number 370 of code points is made, when a single code point is the norm. 372 o Documentation is not of sufficient clarity to evaluate or ensure 373 interoperability. 375 o The code point is needed for a protocol extension, but the 376 extension is not consistent with the documented (or generally 377 understood) architecture of the base protocol being extended, and 378 would be harmful to the protocol if widely deployed. It is not 379 the intent that "inconsistencies" refer to minor differences "of a 380 personal preference nature". Instead, they refer to significant 381 differences such as inconsistencies with the underlying security 382 model, implying a change to the semantics of an existing message 383 type or operation, requiring unwarranted changes in deployed 384 systems (compared with alternate ways of achieving a similar 385 result), etc. 387 o The extension would cause problems with existing deployed systems. 389 o The extension would conflict with one under active development by 390 the IETF, and having both would harm rather than foster 391 interoperability. 393 3.4. Expert Reviews and the Document Lifecycle 395 Review by the designated expert is necessarily done at a particular 396 point in time, and represents review of a particular version of the 397 document. Deciding when the review should take place is a question 398 of good judgment. And while re-reviews might be done when it's 399 acknowledged that the documentation of the registered item has 400 changed substantially, making sure that re-review happens requires 401 attention and care. 403 It is possible, through carelessness, accident, inattentiveness, or 404 even willful disregard, that changes might be made after the 405 designated expert's review and approval that would, if the document 406 were re-reviewed, cause the expert not to approve the registration. 407 It is up to the IESG, with the token held by the responsible Area 408 Director, to be alert to such situations and to recognize that such 409 changes need to be checked. 411 4. Creating a Registry 413 Creating a registry involves describing the namespaces to be created, 414 an initial set of assignments (if appropriate), and guidelines on how 415 future assignments are to be made. 417 Once a registry has been created, IANA records assignments that have 418 been made. The following labels describe the status of an individual 419 (or range) of assignments: 421 Private Use: Private use only (not assigned), as described in 422 Section 4.1.1. 424 Experimental: Available for general experimental use as described 425 in [RFC3692]. IANA does not record specific assignments for 426 any particular use. 428 Unassigned: Not currently assigned, and available for assignment 429 via documented procedures. While it's generally clear that 430 any values that are not registered are unassigned and 431 available for assignment, it is sometimes useful to 432 explicitly specify that situation. Note that this is 433 distinctly different from "Reserved". 435 Reserved: Not assigned and not available for assignment. 436 Reserved values are held for special uses, such as to extend 437 the namespace when it becomes exhausted. Note that this is 438 distinctly different from "Unassigned". 440 4.1. Well-Known IANA Policy Definitions 442 The following are some defined policies, most of which are in use 443 today. These cover a range of typical policies that have been used 444 to describe the procedure for assigning new values in a namespace. 445 It is not strictly required that documents use these terms; the 446 actual requirement is that the instructions to IANA be clear and 447 unambiguous. However, use of these terms is strongly RECOMMENDED, 448 because their meanings are widely understood. The terms are fully 449 explained in the following subsections. 451 1. Private Use 452 2. Experimental Use 453 3. Hierarchical Allocation 454 4. First Come First Served 455 5. Expert Review 456 6. Specification Required 457 7. RFC Required 458 8. IETF Review 459 9. Standards Action 460 10. IESG Approval 462 It should be noted that it often makes sense to partition a namespace 463 into multiple categories, with assignments within each category 464 handled differently. Many protocols now partition namespaces into 465 two or more parts, with one range reserved for Private or 466 Experimental Use while other ranges are reserved for globally unique 467 assignments assigned following some review process. Dividing a 468 namespace into ranges makes it possible to have different policies in 469 place for different ranges and different use cases. 471 Examples: 472 LDAP [RFC4520] 473 TLS ClientCertificateType Identifiers [RFC5246] (as detailed in 474 the subsections below) 475 Pseudowire Edge to Edge Emulation (PWE3) [RFC4446] 477 4.1.1. Policy: Private Use 479 For private or local use only, with the type and purpose defined by 480 the local site. No attempt is made to prevent multiple sites from 481 using the same value in different (and incompatible) ways. There is 482 no need for IANA to review such assignments (since IANA does not 483 record them) and assignments are not generally useful for broad 484 interoperability. It is the responsibility of the sites making use 485 of the Private Use range to ensure that no conflicts occur (within 486 the intended scope of use). 488 Examples: 489 Site-specific options in DHCP [RFC2939] 490 Fibre Channel Port Type Registry [RFC4044] 491 TLS ClientCertificateType Identifiers 224-255 [RFC5246] 493 4.1.2. Policy: Experimental Use 495 Similar to private or local use only, with the purpose being to 496 facilitate experimentation. See [RFC3692] for details. 498 Example: 500 Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP 501 Headers [RFC4727] 503 4.1.3. Policy: Hierarchical Allocation 505 Delegated managers can assign values provided they have been given 506 control over that part of the namespace. IANA controls the higher 507 levels of the namespace according to one of the other policies. 509 Examples: 510 DNS names 511 Object Identifiers 512 IP addresses 514 4.1.4. Policy: First Come First Served 516 Assignments are made to anyone on a first come, first served basis. 517 There is no substantive review of the request, other than to ensure 518 that it is well-formed and doesn't duplicate an existing assignment. 519 However, requests must include a minimal amount of clerical 520 information, such as a point of contact (including an email address) 521 and a brief description of how the value will be used. Additional 522 information specific to the type of value requested may also need to 523 be provided, as defined by the namespace. For numbers, the exact 524 value is generally assigned by IANA; with names, specific text 525 strings can usually be requested. 527 Examples: 528 SASL mechanism names [RFC4422] 529 LDAP Protocol Mechanisms and LDAP Syntax [RFC4520] 531 4.1.5. Policy: Expert Review 533 (Sometimes also called "Designated Expert" in earlier editions of 534 this document.) Approval by a designated expert is required. The 535 required documentation and review criteria for use by the designated 536 expert should be provided when defining the registry. For example, 537 see Sections 6 and 7.2 in [RFC3748]. 539 It is particularly important, when using a designated expert, to give 540 clear guidance to the expert, laying out criteria for performing an 541 evaluation and reasons for rejecting a request. When specifying a 542 policy that involves a designated expert, the IANA Considerations 543 SHOULD contain such guidance. It is also a good idea to include, 544 when possible, a sense of whether many registrations are expected 545 over time, or if the registry is expected to be updated infrequently 546 or in exceptional circumstances only. 548 Examples: 549 EAP Method Types [RFC3748] 550 HTTP Digest AKA algorithm versions [RFC4169] 551 URI schemes [RFC4395] 552 GEOPRIV Location Types [RFC4589] 554 4.1.6. Policy: Specification Required 556 Values and their meanings must be documented in a permanent and 557 readily available public specification, in sufficient detail so that 558 interoperability between independent implementations is possible. 559 When used, Specification Required also implies use of a Designated 560 Expert (see Section 4.1.5), who will review the public specification 561 and evaluate whether it is sufficiently clear to allow interoperable 562 implementations. The intention behind "permanent and readily 563 available" is that a document can reasonably be expected to be 564 findable and retrievable long after IANA assignment of the requested 565 value. Publication of an RFC is an ideal means of achieving this 566 requirement, but Specification Required is intended to also cover the 567 case of a document published outside of the RFC path. For RFC 568 publication, the normal RFC review process is expected to provide the 569 necessary review for interoperability, though the designated expert 570 may be a particularly well-qualified person to perform such a review. 572 When specifying this policy, just use the term "Specification 573 Required". Some specifications have chosen to refer to it as "Expert 574 Review with Specification Required", and that only causes confusion. 576 Examples: 577 Diffserv-aware TE Bandwidth Constraints Model Identifiers 578 [RFC4124] 579 TLS ClientCertificateType Identifiers 64-223 [RFC5246] 580 ROHC Profile Identifiers [RFC5795] 582 4.1.7. Policy: RFC Required 584 RFC publication suffices, as an IETF submission or in any other 585 stream (currently an RFC Editor Independent Submission [RFC5742] or 586 an RFC in the IRTF or IAB Stream). Unless otherwise specified, any 587 type of RFC is sufficient (currently Standards Track, BCP, 588 Informational, Experimental, Historic). 590 4.1.8. Policy: IETF Review 592 (Formerly called "IETF Consensus" in the first edition of this 593 document.) New values are assigned only through RFCs in the IETF 594 Stream -- those that have been shepherded through the IESG as AD- 595 Sponsored or IETF working group Documents [RFC2026] [RFC5378]. The 596 intention is that the document and proposed assignment will be 597 reviewed by the IESG and appropriate IETF working groups (or experts, 598 if suitable working groups no longer exist) to ensure that the 599 proposed assignment will not negatively impact interoperability or 600 otherwise extend IETF protocols in an inappropriate or damaging 601 manner. 603 To ensure adequate community review, such documents are shepherded 604 through the IESG as AD-sponsored or working group documents with an 605 IETF Last Call. 607 Examples: 608 IPSECKEY Algorithm Types [RFC4025] 609 Accounting-Auth-Method AVP values in DIAMETER [RFC4005] 610 TLS Extension Types [RFC5246] 612 4.1.9. Policy: Standards Action 614 Values are assigned only for Standards Track RFCs approved by the 615 IESG. 617 Examples: 618 BGP message types [RFC4271] 619 Mobile Node Identifier option types [RFC4283] 620 TLS ClientCertificateType Identifiers 0-63 [RFC5246] 621 DCCP Packet Types [RFC4340] 623 4.1.10. Policy: IESG Approval 625 New assignments may be approved by the IESG. Although there is no 626 requirement that the request be documented in an RFC, the IESG has 627 discretion to request documents or other supporting materials on a 628 case-by-case basis. 630 IESG Approval is not intended to be used often or as a "common case"; 631 indeed, it has seldom been used in practice during the period RFC 632 2434 was in effect. Rather, it is intended to be available in 633 conjunction with other policies as a fall-back mechanism in the case 634 where one of the other allowable approval mechanisms cannot be 635 employed in a timely fashion or for some other compelling reason. 636 IESG Approval is not intended to circumvent the public review 637 processes implied by other policies that could have been employed for 638 a particular assignment. IESG Approval would be appropriate, 639 however, in cases where expediency is desired and there is strong 640 consensus (such as from a working group) for making the assignment. 642 The following guidelines are suggested for any evaluation under IESG 643 Approval: 645 o The IESG can (and should) reject a request if another path for 646 registration is available that is more appropriate and there is no 647 compelling reason not to use that path. 649 o Before approving a request, the community should be consulted, via 650 a "call for comments" that provides as much information as is 651 reasonably possible about the request. 653 Examples: 654 IPv4 Multicast address assignments [RFC5771] 655 IPv4 IGMP Type and Code values [RFC3228] 656 Mobile IPv6 Mobility Header Type and Option values [RFC6275] 658 4.2. Best Practice for Selecting an Appropriate Policy 660 The definitions above from "First Come First Served" to "Standards 661 Action" specify a range of policies in increasing order of 662 strictness: 664 4. First Come First Served: 665 No review, minimal documentation. 667 5. Expert Review: 668 Expert review, sufficient documentation for review. 670 6. Specification Required: 671 Expert review, significant, stable public documentation. 673 7. RFC Required: 674 Any RFC publication, IETF or a non-IETF Stream. 676 8. IETF Review: 677 RFC publication, IETF Stream only, but need not be Standards 678 Track. 680 9. Standards Action: 681 RFC publication, IETF Stream, Standards Track only. 683 In considering which of those policies to apply, it's important to 684 get the right balance of review and ease of registration. In many 685 cases, those needing to register items will not be IETF participants; 686 requests often come from other standards organizations, from 687 organizations not directly involved in standards, from ad-hoc 688 community work (from an open-source project, for example), and so on. 689 We must not make registration policies and procedures unnecessarily 690 difficult to navigate, unnecessarily costly (in terms of time and 691 other resources), nor unnecessarily subject to denial. 693 While it is sometimes necessary to restrict what gets registered (for 694 limited resources such as bits in a byte or numbers within a 695 relatively small range, or for items for which unsupported values can 696 be damaging to protocol operation), in many cases having items 697 registered is more important than putting restrictions on the 698 registration. A pattern of denial through overly strict review 699 criteria, or because of excessive cost in time and effort to get 700 through the process, discourages people from even attempting to 701 register their items. And failure to have in-use items registered 702 adversely affects the protocols in use on the Internet. 704 In particular, because policies 7 through 9 require involvement of 705 working groups, directorates, and/or communities of former working- 706 group participants to be actively involved and to support the effort, 707 requests frequently run into concerns that "it's not worth doing a 708 Standards-Track RFC for something this trivial," when, in fact, that 709 requirement was created by the working group in the first place, with 710 its selection of a Standards Action policy for the registry. Indeed, 711 publishing any RFC is costly, and a Standards Track RFC is especially 712 so, requiring a great deal of community time for review and 713 discussion, IETF-wide last call, involvement of the entire IESG as 714 well as concentrated time and review from the sponsoring AD, review 715 and action by IANA, and RFC-Editor processing. 717 Working groups and other document developers should use care in 718 selecting appropriate registration policies when their documents 719 create registries. They should select the least strict policy that 720 suits a registry's needs, and look for specific justification for 721 policies stricter than Specification Required. Examples of 722 situations that might merit RFC Required, IETF Review, or Standards 723 Action include the following. 725 o Registries of limited resources, such as bits in a byte (or in two 726 bytes, or four), or numbers in a limited range. In these cases, 727 allowing registrations that haven't been carefully reviewed and 728 agreed by community consensus could too quickly deplete the 729 allowable values. 731 o Registries for which thorough community review is necessary to 732 avoid extending or modifying the protocol in ways that could be 733 damaging. One example is in defining new command codes, as 734 opposed to options that use existing command codes: the former 735 might require a strict policy, where a more relaxed policy could 736 be adequate for the latter. Another example is in defining things 737 that change the semantics of existing operations. 739 There will be other cases, as well, of course; much assessment and 740 judgment is needed. It's not the intent here to put limits on the 741 applicability of particular registration policies, but to recommend 742 laxity, rather than strictness, in general, and to encourage document 743 developers to think carefully about each registry before deciding on 744 policies. 746 The description in Section 4.1.10 of "IESG Approval" suggests that 747 the IESG "can (and should) reject a request if another path for 748 registration is available that is more appropriate and there is no 749 compelling reason not to use that path." The IESG should give 750 similar consideration to any registration policy more stringent than 751 Specification Required, asking for justification and ensuring that 752 more relaxed policies have been considered, and the strict policy is 753 the right one. This is a situation that will -- and should -- 754 involve a substantive discussion between the IESG and the working 755 group, chairs, document editors, and/or document shepherd. The 756 important point, again, is not to relax the registration policy just 757 to get the document through quickly, but to carefully choose the 758 right policy for each registry. 760 Accordingly, document developers need to anticipate this and document 761 their considerations for selecting the specified policy. Ideally, 762 they should include that in the document. At the least, it should be 763 included in the shepherd writeup for the document, and in any case 764 the document shepherd should ensure that the selected policies have 765 been justified before sending the document to the IESG. 767 When specifications are revised, registration policies should be 768 reviewed in light of experience since the policies were set. It is 769 also possible to produce a small document at any time, which 770 "updates" the original specification and changes registration 771 policies. In either case, a policy can be relaxed or made more 772 strict, as appropriate to the actual situation. 774 Once again, it cannot be stressed enough that this must not be a 775 mechanical process, but one to which the document developers apply 776 thought, consideration, assessment, and judgment in choosing the 777 right policy for each registry. 779 The recommendations in this section apply whether the well-defined 780 policy names defined herein are used, or whether the document 781 contains other policy definitions. The point, again, is not to limit 782 registration policies, but to ensure that the policies selected are 783 appropriate, and that proper consideration has been given to the 784 level of strictness required by them. 786 4.3. What to Put in Documents That Create a Registry 788 The previous sections presented some issues that should be considered 789 in formulating a policy for assigning values in namespaces. It is 790 the working group and/or document author's job to formulate an 791 appropriate policy and specify it in the appropriate document. In 792 almost all cases, having an explicit "IANA Considerations" section is 793 appropriate. The following and later sections define what is needed 794 for the different types of IANA actions. 796 Documents that create a new namespace (or modify the definition of an 797 existing space) and that expect IANA to play a role in maintaining 798 that space (serving as a repository for registered values) MUST 799 provide clear instructions on details of the namespace. In 800 particular, instructions MUST include: 802 1. The name of the registry (or sub-registry) being created and/or 803 maintained. 804 The name will appear on the IANA web page and will be referred to 805 in future documents that need to allocate a value from the new 806 space. The full name (and abbreviation, if appropriate) should 807 be provided. It is highly desirable that the chosen name not be 808 easily confusable with the name of another registry. When 809 creating a sub-registry, the registry that it is a part of must 810 be clearly identified using its exact name (look it up, to be 811 sure). Providing a URL to precisely identify the registry is 812 helpful. Such URLs will be removed from the RFC prior to final 813 publication, but help to ensure that IANA will understand exactly 814 what is being requested. For example, a document could contain 815 something like this: 817 [TO BE REMOVED: This registration should be made in the Foobar 818 Operational Parameters registry, located at 819 http://www.iana.org/assignments/foobar-registry] 821 2. What information must be provided as part of a request in order 822 to assign a new value. This information may include the need to 823 document relevant security considerations, if any. 825 3. The review process that will apply to all future requests for a 826 value from the namespace. 828 Note: When a designated expert is used, documents MUST NOT name 829 the designated expert in the document itself; instead, any 830 suggested names should be relayed to the appropriate Area 831 Director at the time the document is sent to the IESG for 832 approval. This is usually done in the document shepherd writeup. 834 If the request should also be reviewed on a specific public 835 mailing list (such as the media-types@iana.org for media types), 836 that mailing address should be specified. Note, however, that 837 when mailing lists are specified, the requirement for a 838 designated expert MUST also be specified (see Section 3). 840 If IANA is expected to make assignments without requiring an 841 outside review, sufficient guidance MUST be provided so that the 842 requests can be evaluated with minimal subjectivity. 844 4. The size, format, and syntax of registry entries. When creating 845 a new name/number space, authors must describe any technical 846 requirements on registry (and sub-registry) values (valid ranges 847 for integers, length limitations on strings, etc.) as well as the 848 exact format in which registry values should be displayed. For 849 number assignments, one should specify whether values are to be 850 recorded in decimal, hexadecimal, or some other format. For 851 strings, the encoding format should be specified (ASCII, UTF8, 852 etc.). Authors should also clearly specify what fields to record 853 in the registry. 855 5. Initial assignments and reservations. Clear instructions should 856 be provided to identify any initial assignments or registrations. 857 In addition, any ranges that are to be reserved for "Private 858 Use", "Reserved", "Unassigned", etc. should be clearly indicated. 860 When specifying the process for making future assignments, it is 861 quite acceptable to pick one (or more) of the example policies listed 862 in Section 4.1 and refer to it by name. Indeed, this is the 863 preferred mechanism in those cases where the sample policies provide 864 the desired level of review. It is also acceptable to cite one of 865 the above policies and include additional guidelines for what kind of 866 considerations should be taken into account by the review process. 867 For example, RADIUS [RFC3575] specifies the use of a Designated 868 Expert, but includes specific additional criteria the Designated 869 Expert should follow. 871 For example, a document could say something like this: 873 --------------------------------------------------------------- 874 This document defines a new DHCP option, entitled "FooBar" (see 875 Section y), assigned a value of TBD1 from the DHCP Option space 876 [to be removed upon publication: 877 http://www.iana.org/assignments/bootp-dhcp-parameters] 878 [RFC2132] [RFC2939]: 879 Data 880 Tag Name Length Meaning 881 ---- ---- ------ ------- 882 TBD1 FooBar N FooBar server 884 The FooBar option also defines an 8-bit FooType field, for which 885 IANA is to create and maintain a new sub-registry entitled 886 "FooType values" under the FooBar option. Initial values for the 887 DHCP FooBar FooType registry are given below; future assignments 888 are to be made through Expert Review [BCP26]. 889 Assignments consist of a DHCP FooBar FooType name and its 890 associated value. 892 Value DHCP FooBar FooType Name Definition 893 ---- ------------------------ ---------- 894 0 Reserved 895 1 Frobnitz See Section y.1 896 2 NitzFrob See Section y.2 897 3-254 Unassigned 898 255 Reserved 899 --------------------------------------------------------------- 901 For examples of documents that provide detailed guidance to IANA on 902 the issue of assigning numbers, consult [RFC6195], [RFC3575], 903 [RFC3968], and [RFC4520]. 905 4.4. Updating IANA Guidelines for Existing Registries 907 Updating the registration process for an already existing (previously 908 created) namespace (whether created explicitly or implicitly) follows 909 a process similar to that used when creating a new namespace. That 910 is, a document is produced that makes reference to the existing 911 namespace and then provides detailed guidelines for handling 912 assignments in each individual namespace. Such documents are 913 normally processed as Best Current Practices (BCPs) [RFC2026]. 915 Example documents that updated the guidelines for managing (then) 916 pre-existing registries include: [RFC6195], [RFC3228], and [RFC3575]. 918 5. Registering New Values in an Existing Registry 920 5.1. What to Put in Documents When Registering Values 922 Often, documents request an assignment from an already existing 923 namespace (one created by a previously published document). In such 924 cases: 926 o Documents should clearly identify the namespace in which each 927 value is to be registered. If the registration goes into a sub- 928 registry, the author should clearly describe where the assignment 929 or registration should go. It is helpful to use the *exact* 930 namespace name as listed on the IANA web page (please look it up, 931 and don't guess), and cite the RFC where the namespace is defined. 933 Note 1: There is no need to mention what the assignment policy for 934 new assignments is, as that should be clear from the references. 936 Note 2: When referring to an existing registry, providing a URL to 937 precisely identify the registry is helpful. Such URLs, however, 938 should usually be removed from the RFC prior to final publication, 939 since IANA URLs are not guaranteed to be stable in the future. In 940 cases where it is important to include a URL in the document, IANA 941 should concur on its inclusion. 943 For example, a document could contain something like this: 945 [TO BE REMOVED: This registration should be made in the Foobar 946 Operational Parameters registry, located at 947 http://www.iana.org/assignments/foobar-registry] 949 o Each value requested should be given a unique reference. When the 950 value is numeric, use the notation: TBD1, TBD2, etc. Throughout 951 the document where an actual IANA-assigned value should be filled 952 in, use the "TBDx" notation. This helps ensure that the final RFC 953 has the correct assigned values inserted in all of the relevant 954 places where the value is expected to appear in the final 955 document. For values that are text strings, a specific name can 956 be suggested. IANA will normally assign the name, unless it 957 conflicts with a name already in use. 959 o Normally, the values to be used are chosen by IANA and documents 960 should specify values of "TBD". However, in some cases, a value 961 may have been used for testing or in early implementations. In 962 such cases, it is acceptable to include text suggesting what 963 specific value should be used (together with the reason for the 964 choice). For example, one might include the text "the value XXX 965 is suggested as it is used in implementations". However, it 966 should be noted that suggested values are just that; IANA will 967 attempt to assign them, but may find that impossible, if the 968 proposed number has already been assigned for some other use. For 969 some registries, IANA has a long-standing policy prohibiting 970 assignment of names or codes on a vanity or organization-name 971 basis. For example, codes are always assigned sequentially unless 972 there is a strong reason for making an exception. Nothing in this 973 document is intended to change those policies or prevent their 974 future application. 976 o The IANA Considerations section should summarize all of the IANA 977 actions, with pointers to the relevant sections elsewhere in the 978 document as appropriate. When multiple values are requested, it 979 is generally helpful to include a summary table. It is also 980 helpful for this table to be in the same format as it appears or 981 will appear on the IANA web site. For example: 983 Value Description Reference 984 -------- ------------------- --------- 985 TBD1 Foobar [[this RFC]] 987 Note: In cases where authors feel that including the full table is 988 too verbose or repetitive, authors should still include the table 989 in the draft, but may include a note asking that the table be 990 removed prior to publication of the final RFC. 992 As an example, the following text could be used to request assignment 993 of a DHCPv6 option number: 995 IANA has assigned an option code value of TBD1 to the DNS 996 Recursive Name Server option and an option code value of TBD2 to 997 the Domain Search List option from the DHCP option code space 998 defined in Section 24.3 of RFC 3315. 1000 5.2. Updating Registrations 1002 Registrations are a request to assign a new value, including the 1003 related information needed to evaluate and document the request. 1004 Even after a number has been assigned, some types of registrations 1005 contain additional information that may need to be updated over time. 1006 For example, MIME media types, character sets, and language tags, 1007 etc. typically include more information than just the registered 1008 value itself. Example information can include point-of-contact 1009 information, security issues, pointers to updates, literature 1010 references, etc. In such cases, the document defining the namespace 1011 must clearly state who is responsible for maintaining and updating a 1012 registration. In different cases, it may be appropriate to specify 1013 one or more of the following: 1015 o Let the author update the registration, subject to the same 1016 constraints and review as with new registrations. 1018 o Allow some mechanism to attach comments to the registration, for 1019 cases where others have significant objections to claims in a 1020 registration, but the author does not agree to change the 1021 registration. 1023 o Designate the IESG, a designated expert, or another entity as 1024 having the right to change the registrant associated with a 1025 registration and any requirements or conditions on doing so. This 1026 is mainly to get around the problem when a registrant cannot be 1027 reached in order to make necessary updates. 1029 5.3. Overriding Registration Procedures 1031 Since RFC 2434 was published, experience has shown that the 1032 documented IANA considerations for individual protocols do not always 1033 adequately cover the reality after the protocol is deployed. For 1034 example, many older routing protocols do not have documented, 1035 detailed IANA considerations. In addition, documented IANA 1036 considerations are sometimes found to be too stringent to allow even 1037 working group documents (for which there is strong consensus) to 1038 obtain code points from IANA in advance of actual RFC publication. 1039 In other cases, the documented procedures are unclear or neglected to 1040 cover all the cases. In order to allow assignments in individual 1041 cases where there is strong IETF consensus that an allocation should 1042 go forward, but the documented procedures do not support such an 1043 assignment, the IESG is granted authority to approve assignments in 1044 such cases. The intention is not to overrule properly documented 1045 procedures, or to obviate the need for protocols to properly document 1046 their IANA considerations. Instead, the intention is to permit 1047 assignments in individual cases where it is obvious that the 1048 assignment should just be made, but updating the IANA process just to 1049 assign a particular code point is viewed as too heavy a burden. 1051 In general, the IETF would like to see deficient IANA registration 1052 procedures for a namespace revised through the IETF standards 1053 process, but not at the cost of unreasonable delay for needed 1054 assignments. If the IESG has had to take the action in this section, 1055 it is a strong indicator that the IANA registration procedures should 1056 be updated, possibly in parallel with ongoing protocol work. 1058 6. Documentation References in IANA Registries 1060 Usually, registries and registry entries include references to 1061 documentation (RFCs or other documents). The purpose of these 1062 references is to provide pointers for implementors to find details 1063 necessary for implementation, NOT to simply note what document 1064 created the registry or entry. Therefore: 1066 o If a document registers an item that is defined and explained 1067 elsewhere, the registered reference should be to that document, 1068 and not to the document that is merely performing the 1069 registration. 1071 o If the registered item is defined and explained in the current 1072 document, it is important to include sufficient information to 1073 enable implementors to understand the item and to create a proper 1074 implementation. 1076 o If the registered item is explained primarily in a specific 1077 section of the reference document, it is useful to include a 1078 section reference. For example, "[RFC9876], Section 3.2", rather 1079 than just "[RFC9876]". 1081 o For documentation of a new registry, the reference should provide 1082 information about the registry itself, not just a pointer to the 1083 creation of it. Useful information includes the purpose of the 1084 registry, a rationale for its creation, documentation of the 1085 process and policy for new registrations, guidelines for new 1086 registrants or designated experts, and other such related 1087 information. 1089 7. What to Do in "bis" Documents 1091 We often produce a new edition of an RFC, which obsoletes the 1092 previous edition (we sometimes call these "bis" documents, such as 1093 when RFC 9876 is updated by draft-ietf-foo-rfc9876bis). When the 1094 original document created registries and/or registered entries, there 1095 is a question of how to handle the IANA Considerations section in the 1096 "bis" document. 1098 If the registrations specify the original document as a reference, 1099 those registrations should be updated to point to the current (not 1100 obsolete) documentation for those items. Usually, that will mean 1101 changing the reference to be the "bis" document. 1103 For example, suppose RFC 9876 registered the "BANANA" flag in the 1104 "Fruit Access Flags" registry, and the documentation for that flag is 1105 in Section 3.2. The current registry might look, in part, like this: 1107 Name Description Reference 1108 -------- ------------------- --------- 1109 BANANA Flag for bananas [RFC9876], Section 3.2 1111 If draft-ietf-foo-rfc9876bis obsoletes RFC 9876 and, because of some 1112 rearrangement, now documents the flag in Section 4.1.2, the IANA 1113 Considerations of the bis document might contain text such as this: 1115 IANA is asked to change the registration information for the 1116 BANANA flag in the "Fruit Access Flags" registry to the following: 1118 Name Description Reference 1119 -------- ------------------- --------- 1120 BANANA Flag for bananas [[this RFC]], Section 4.2.1 1122 In many cases, if there are a number of registered references to the 1123 original RFC and the document organization has not changed the 1124 registered section numbering much, it may simply be reasonable to do 1125 this: 1127 Because this document obsoletes RFC 9876, IANA is asked to change 1128 all registration information that references [RFC9876] to instead 1129 reference [[this RFC]]. 1131 If information for registered items has been or is being moved to 1132 other documents, then, of course, the registration information should 1133 be changed to point to those other documents. In no case is it 1134 reasonable to leave documentation pointers to the obsoleted document 1135 for any registries or registered items that are still in current use. 1137 8. Miscellaneous Issues 1139 8.1. When There Are No IANA Actions 1141 Before an Internet-Draft can be published as an RFC, IANA needs to 1142 know what actions (if any) it needs to perform. Experience has shown 1143 that it is not always immediately obvious whether a document has no 1144 IANA actions, without reviewing the document in some detail. In 1145 order to make it clear to IANA that it has no actions to perform (and 1146 that the author has consciously made such a determination), such 1147 documents should include an IANA Considerations section that states: 1149 This document has no IANA actions. 1151 This statement, or an equivalent, must only be inserted after the 1152 working group or individual submitter has carefully verified it to be 1153 true. Using such wording as a matter of "boilerplate" or without 1154 careful consideration can lead to incomplete or incorrect IANA 1155 actions being performed. 1157 If a specification makes use of values from a namespace that is not 1158 managed by IANA, it may be useful to note this fact, with wording 1159 such as this: 1161 The values of the Foobar parameter are assigned by the Barfoo 1162 registry on behalf of the Rabfoo Forum. Therefore, this document 1163 has no IANA actions. 1165 In some cases, the absence of IANA-assigned values may be considered 1166 valuable information for future readers; in other cases, it may be 1167 considered of no value once the document has been approved, and may 1168 be removed before archival publication. This choice should be made 1169 clear in the draft, for example, by including a sentence such as 1171 [RFC Editor: please remove this section prior to publication.] 1173 or 1175 [RFC Editor: please do not remove this section.] 1177 8.2. Namespaces Lacking Documented Guidance 1179 For all existing RFCs that either explicitly or implicitly rely on 1180 IANA to evaluate assignments without specifying a precise evaluation 1181 policy, IANA (in consultation with the IESG) will continue to decide 1182 what policy is appropriate. Changes to existing policies can always 1183 be initiated through the normal IETF consensus process. 1185 All future RFCs that either explicitly or implicitly rely on IANA to 1186 register or otherwise manage namespace assignments MUST provide 1187 guidelines for managing the namespace. 1189 8.3. After-the-Fact Registrations 1191 Occasionally, IANA becomes aware that an unassigned value from a 1192 managed namespace is in use on the Internet or that an assigned value 1193 is being used for a different purpose than originally registered. 1194 IANA will not condone such misuse; procedures of the type described 1195 in this document MUST be applied to such cases. In the absence of 1196 specifications to the contrary, values may only be reassigned for a 1197 different purpose with the consent of the original assignee (when 1198 possible) and with due consideration of the impact of such a 1199 reassignment. In cases of likely controversy, consultation with the 1200 IESG is advised. 1202 8.4. Reclaiming Assigned Values 1204 Reclaiming previously assigned values for reuse is tricky, because 1205 doing so can lead to interoperability problems with deployed systems 1206 still using the assigned values. Moreover, it can be extremely 1207 difficult to determine the extent of deployment of systems making use 1208 of a particular value. However, in cases where the namespace is 1209 running out of unassigned values and additional ones are needed, it 1210 may be desirable to attempt to reclaim unused values. When 1211 reclaiming unused values, the following (at a minimum) should be 1212 considered: 1214 o Attempts should be made to contact the original party to which a 1215 value is assigned, to determine if the value was ever used, and if 1216 so, the extent of deployment. (In some cases, products were never 1217 shipped or have long ceased being used. In other cases, it may be 1218 known that a value was never actually used at all.) 1220 o Reassignments should not normally be made without the concurrence 1221 of the original requester. Reclamation under such conditions 1222 should only take place where there is strong evidence that a value 1223 is not widely used, and the need to reclaim the value outweighs 1224 the cost of a hostile reclamation. In any case, IESG Approval is 1225 needed in this case. 1227 o It may be appropriate to write up the proposed action and solicit 1228 comments from relevant user communities. In some cases, it may be 1229 appropriate to write an RFC that goes through a formal IETF 1230 process (including IETF Last Call) as was done when DHCP reclaimed 1231 some of its "Private Use" options [RFC3942]. 1233 8.5. Contact Person vs Assignee or Owner 1235 Many registries include designation of a technical or administrative 1236 contact associated with each entry. Often, this is recorded as 1237 contact information for an individual. It is unclear, though, what 1238 role the individual has with respect to the registration: is this 1239 item registered on behalf of the individual, the company the 1240 individual worked for, or perhaps another organization the individual 1241 was acting for? 1243 This matters because some time later, when the individual has changed 1244 jobs or roles, and perhaps can no longer be contacted, someone might 1245 want to update the registration. IANA has no way to know what 1246 company, organization, or individual should be allowed to take the 1247 registration over. For registrations rooted in RFCs, the stream 1248 owner (such as the IESG or the IAB) can make an overriding decision. 1249 But in other cases, there is no recourse. 1251 Registries can include, in addition to a "Contact" field, an 1252 "Assignee" or "Owner" field that can be used to address this 1253 situation, giving IANA clear guidance as to the actual owner of the 1254 registration. Alternatively, organizations can put an organizational 1255 role into the "Contact" field in order to make their ownership clear. 1257 8.6. BCP 78/79 Issues in Registries 1259 [[anchor2: This section needs to be resolved before publication.]] 1261 9. Appeals 1263 Appeals of registration decisions made by IANA can be made using the 1264 normal IETF appeals process as described in Section 6.5 of [RFC2026]. 1265 Specifically, appeals should be directed to the IESG, followed (if 1266 necessary) by an appeal to the IAB, etc. 1268 10. Mailing Lists 1270 All IETF mailing lists associated with evaluating or discussing 1271 assignment requests as described in this document are subject to 1272 whatever rules of conduct and methods of list management are 1273 currently defined by Best Current Practices or by IESG decision. 1275 11. Security Considerations 1277 Information that creates or updates a registration needs to be 1278 authenticated and authorized. IANA updates registries according to 1279 instructions in published RFCs and from the IESG. It also may accept 1280 clarifications from document authors, relevant working group chairs, 1281 Designated Experts, and mail list participants, too. 1283 Information concerning possible security vulnerabilities of a 1284 protocol may change over time. Likewise, security vulnerabilities 1285 related to how an assigned number is used may change as well. As new 1286 vulnerabilities are discovered, information about such 1287 vulnerabilities may need to be attached to existing registrations, so 1288 that users are not misled as to the true security issues surrounding 1289 the use of a registered number. 1291 An analysis of security issues is generally required for all 1292 protocols that make use of parameters (data types, operation codes, 1293 keywords, etc.) used in IETF protocols or registered by IANA. Such 1294 security considerations are usually included in the protocol document 1295 [RFC3552]. It is the responsibility of the IANA considerations 1296 associated with a particular registry to specify what (if any) 1297 security considerations must be provided when assigning new values, 1298 and the process for reviewing such claims. 1300 12. Changes Relative to Earlier Editions of BCP 26 1302 12.1. 2012: Changes in This Document Relative to RFC 5226 1304 Significant additions: 1306 o Added Section 3.4, Expert Reviews and the Document Lifecycle 1308 o Moved well-known policies into a separate section for each, 1309 subsections of Section 4.1. 1311 o Added Section 4.2, Best Practice for Selecting an Appropriate 1312 Policy. 1314 o Added Section 6, Documentation References in IANA Registries 1316 o Added Section 7, What to Do in "bis" Documents 1318 o Added Section 8.5, Contact Person vs Assignee or Owner 1320 o Added Section 8.6, BCP 78/79 Issues in Registries 1322 Clarifications and such: 1324 o Made clarifications about identification of IANA registries and 1325 use of URLs for them. 1327 o Clarified the distinction between "Unassigned" and "Reserved". 1329 o Made some clarifications in "Expert Review" about instructions to 1330 the designated expert. 1332 o Made some clarifications in "Specification Required" about how to 1333 declare this policy. 1335 o Assorted minor clarifications and editorial changes throughout. 1337 12.2. 2008: Changes in RFC 5226 Relative to RFC 2434 1339 Changes include: 1341 o Major reordering of text to expand descriptions and to better 1342 group topics such as "updating registries" vs. "creating new 1343 registries", in order to make it easier for authors to find the 1344 text most applicable to their needs. 1346 o Numerous editorial changes to improve readability. 1348 o Changed the term "IETF Consensus" to "IETF Review" and added more 1349 clarifications. History has shown that people see the words "IETF 1350 Consensus" (without consulting the actual definition) and are 1351 quick to make incorrect assumptions about what the term means in 1352 the context of IANA Considerations. 1354 o Added "RFC Required" to list of defined policies. 1356 o Much more explicit directions and examples of "what to put in 1357 RFCs". 1359 o "Specification Required" now implies use of a Designated Expert to 1360 evaluate specs for sufficient clarity. 1362 o Significantly changed the wording in the Designated Experts 1363 section. Main purpose is to make clear that Expert Reviewers are 1364 accountable to the community, and to provide some guidance for 1365 review criteria in the default case. 1367 o Changed wording to remove any special appeals path. The normal 1368 RFC 2026 appeals path is used. 1370 o Added a section about reclaiming unused value. 1372 o Added a section on after-the-fact registrations. 1374 o Added a section indicating that mailing lists used to evaluate 1375 possible assignments (such as by a Designated Expert) are subject 1376 to normal IETF rules. 1378 13. Acknowledgments 1380 13.1. Acknowledgments for This Document (2012) 1382 Thomas Narten and Harald Tveit Alvestrand edited the two earlier 1383 editions of this document (RFCs 2434 and 5226), and Thomas continues 1384 his role in this third edition. Most of the text from RFC 5226 1385 remains in this edition. 1387 13.2. Acknowledgments from the second edition (2008) 1389 The original acknowledgments section in RFC 5226 was: 1391 This document has benefited from specific feedback from Jari Arkko, 1392 Marcelo Bagnulo Braun, Brian Carpenter, Michelle Cotton, Spencer 1393 Dawkins, Barbara Denny, Miguel Garcia, Paul Hoffman, Russ Housley, 1394 John Klensin, Allison Mankin, Blake Ramsdell, Mark Townsley, Magnus 1395 Westerlund, and Bert Wijnen. 1397 13.3. Acknowledgments from the first edition (1998) 1399 The original acknowledgments section in RFC 2434 was: 1401 Jon Postel and Joyce Reynolds provided a detailed explanation on what 1402 IANA needs in order to manage assignments efficiently, and patiently 1403 provided comments on multiple versions of this document. Brian 1404 Carpenter provided helpful comments on earlier versions of the 1405 document. One paragraph in the Security Considerations section was 1406 borrowed from [RFC4288]. 1408 14. References 1410 14.1. Normative References 1412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1413 Requirement Levels", BCP 14, RFC 2119, March 1997. 1415 14.2. Informative References 1417 [I-D.iab-extension-recs] 1418 Carpenter, B., Aboba, B., and S. Cheshire, "Design 1419 Considerations for Protocol Extensions", 1420 draft-iab-extension-recs-10 (work in progress), 1421 February 2012. 1423 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1424 September 1981. 1426 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1427 3", BCP 9, RFC 2026, October 1996. 1429 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1430 Extensions", RFC 2132, March 1997. 1432 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 1433 Understanding Concerning the Technical Work of the 1434 Internet Assigned Numbers Authority", RFC 2860, June 2000. 1436 [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition 1437 of New DHCP Options and Message Types", BCP 43, RFC 2939, 1438 September 2000. 1440 [RFC3228] Fenner, B., "IANA Considerations for IPv4 Internet Group 1441 Management Protocol (IGMP)", BCP 57, RFC 3228, 1442 February 2002. 1444 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 1445 an On-line Database", RFC 3232, January 2002. 1447 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1448 Text on Security Considerations", BCP 72, RFC 3552, 1449 July 2003. 1451 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1452 Authentication Dial In User Service)", RFC 3575, 1453 July 2003. 1455 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1456 Considered Useful", BCP 82, RFC 3692, January 2004. 1458 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1459 Levkowetz, "Extensible Authentication Protocol (EAP)", 1460 RFC 3748, June 2004. 1462 [RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration 1463 Protocol version 4 (DHCPv4) Options", RFC 3942, 1464 November 2004. 1466 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 1467 (IANA) Header Field Parameter Registry for the Session 1468 Initiation Protocol (SIP)", BCP 98, RFC 3968, 1469 December 2004. 1471 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 1472 "Diameter Network Access Server Application", RFC 4005, 1473 August 2005. 1475 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 1476 Material in DNS", RFC 4025, March 2005. 1478 [RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, 1479 May 2005. 1481 [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of 1482 Diffserv-aware MPLS Traffic Engineering", RFC 4124, 1483 June 2005. 1485 [RFC4169] Torvinen, V., Arkko, J., and M. Naslund, "Hypertext 1486 Transfer Protocol (HTTP) Digest Authentication Using 1487 Authentication and Key Agreement (AKA) Version-2", 1488 RFC 4169, November 2005. 1490 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1491 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1493 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 1494 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 1495 (MIPv6)", RFC 4283, November 2005. 1497 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1498 Registration Procedures", BCP 13, RFC 4288, December 2005. 1500 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1501 Internet Protocol", RFC 4301, December 2005. 1503 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1504 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1506 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 1507 Registration Procedures for New URI Schemes", BCP 35, 1508 RFC 4395, February 2006. 1510 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1511 Security Layer (SASL)", RFC 4422, June 2006. 1513 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 1514 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 1516 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 1517 Considerations for the Lightweight Directory Access 1518 Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 1520 [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types 1521 Registry", RFC 4589, July 2006. 1523 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1524 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 1526 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1527 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1529 [RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide 1530 to the IETF Trust", BCP 78, RFC 5378, November 2008. 1532 [RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for 1533 Handling of Independent and IRTF Stream Submissions", 1534 BCP 92, RFC 5742, December 2009. 1536 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 1537 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 1538 March 2010. 1540 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 1541 Header Compression (ROHC) Framework", RFC 5795, 1542 March 2010. 1544 [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA 1545 Considerations", BCP 42, RFC 6195, March 2011. 1547 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1548 in IPv6", RFC 6275, July 2011. 1550 Authors' Addresses 1552 Michelle Cotton 1553 Internet Assigned Numbers Authority (IANA) 1554 4676 Admiralty Way, Suite 330 1555 Marina del Rey, CA 90292 1556 USA 1558 Phone: +1 310 301 5812 1559 Email: michelle.cotton@icann.org 1561 Barry Leiba 1562 Huawei Technologies 1564 Phone: +1 646 827 0648 1565 Email: barryleiba@computer.org 1566 URI: http://internetmessagingtechnology.org/ 1567 Thomas Narten 1568 IBM Corporation 1569 3039 Cornwallis Ave., PO Box 12195 - BRQA/502 1570 Research Triangle Park, NC 27709-2195 1571 USA 1573 Phone: +1 919 254 7798 1574 Email: narten@us.ibm.com