idnits 2.17.00 (12 Aug 2021) /tmp/idnits20337/draft-leiba-cotton-iana-5226bis-08.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 01, 2014) is 2788 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: 'RFC2132' is mentioned on line 372, but not defined == Missing Reference: 'BCP26' is mentioned on line 572, but not defined == Missing Reference: 'RFC9876' is mentioned on line 1345, but not defined -- 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: 0 errors (**), 0 flaws (~~), 5 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 ICANN 4 BCP: 26 B. Leiba 5 Obsoletes: 5226 (if approved) Huawei Technologies 6 Intended status: Best Current Practice T. Narten 7 Expires: April 02, 2015 IBM Corporation 8 October 01, 2014 10 Guidelines for Writing an IANA Considerations Section in RFCs 11 draft-leiba-cotton-iana-5226bis-08 13 Abstract 15 Many protocols make use of points of extensibility that use constants 16 to identify various protocol parameters. To ensure that the values 17 used in these fields do not have conflicting uses, and to promote 18 interoperability, their allocation is often coordinated by a central 19 authority. For IETF protocols, that role is filled by the Internet 20 Assigned Numbers Authority (IANA). 22 To make assignments in a given namespace prudently, IANA needs 23 guidance describing the conditions under which new values should be 24 assigned, as well as when and how modifications to existing values 25 can be made. This document defines a framework for the documentation 26 of these guidelines by specification authors, in order to assure that 27 the guidance given to IANA is clear and addresses the various issues 28 that are likely in the operation of a registry. 30 This is the third edition, and obsoletes RFC 5226. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 02, 2015. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Keep IANA Considerations for IANA . . . . . . . . . . . . 3 67 1.2. For More Information . . . . . . . . . . . . . . . . . . . 4 68 1.3. Terminology Used In This Document . . . . . . . . . . . . 4 69 2. Creating and Revising Registries . . . . . . . . . . . . . . . 4 70 2.1. Hierarchical Registry Structure . . . . . . . . . . . . . 5 71 2.2. Documentation Requirements for Registries . . . . . . . . 6 72 2.3. Defining an Appropriate Registry Policy . . . . . . . . . 8 73 2.3.1. Using the Well-Known Registration Policies . . . . . . 10 74 2.3.2. Using Multiple Policies in Combination . . . . . . . . 11 75 2.3.3. Specifying Change Control for a Registry . . . . . . . 12 76 2.4. Revising Existing Registries . . . . . . . . . . . . . . . 12 77 3. Registering New Values in an Existing Registry . . . . . . . . 13 78 3.1. Documentation Requirements for Registrations . . . . . . . 13 79 3.2. Updating Existing Registrations . . . . . . . . . . . . . 14 80 3.3. Overriding Registration Procedures . . . . . . . . . . . . 15 81 3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 15 82 4. Well-Known Registration Policies . . . . . . . . . . . . . . . 16 83 4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 17 84 4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . . 17 85 4.3. Hierarchical Allocation . . . . . . . . . . . . . . . . . 17 86 4.4. First Come First Served . . . . . . . . . . . . . . . . . 17 87 4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 18 88 4.6. Specification Required . . . . . . . . . . . . . . . . . . 19 89 4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . . 19 90 4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 19 91 4.9. Standards Action . . . . . . . . . . . . . . . . . . . . . 20 92 4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 20 93 5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 21 94 5.1. The Motivation for Designated Experts . . . . . . . . . . 21 95 5.2. The Role of the Designated Expert . . . . . . . . . . . . 22 96 5.2.1. Managing Designated Experts in the IETF . . . . . . . 23 97 5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 23 98 5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 25 99 6. Well-Known Registration Status Terminology . . . . . . . . . . 25 100 7. Documentation References in IANA Registries . . . . . . . . . 26 101 8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 26 102 9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 27 103 9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 27 104 9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 28 105 9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 28 106 9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 29 107 9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 29 108 9.6. Closing or Obsoleting a Registry . . . . . . . . . . . . . 30 109 10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 110 11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 30 111 12. Security Considerations . . . . . . . . . . . . . . . . . . . 30 112 13. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 31 113 13.1. 2014: Changes in This Document Relative to RFC 5226 . . . 31 114 13.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 32 115 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 116 14.1. Acknowledgments for This Document (2014) . . . . . . . . 33 117 14.2. Acknowledgments from the second edition (2008) . . . . . 33 118 14.3. Acknowledgments from the first edition (1998) . . . . . . 33 119 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 120 15.1. Normative References . . . . . . . . . . . . . . . . . . 34 121 15.2. Informative References . . . . . . . . . . . . . . . . . 34 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 124 1. Introduction 126 Many protocols make use of points of extensibility that use constants 127 to identify various protocol parameters. To ensure that the values 128 used in these fields do not have conflicting uses, and to promote 129 interoperability, their allocation is often coordinated by a central 130 authority. For IETF protocols, that role is filled by the Internet 131 Assigned Numbers Authority (IANA) [RFC2860]. IANA services are 132 currently provided by the International Corporation for Assigned 133 Names and Numbers (ICANN). 135 The Protocol field in the IP header [RFC0791] and MIME media types 136 [RFC4288] are two examples of such coordinations. 138 In this document, we call the range of possible values for such a 139 field a "namespace". The binding or association of a specific value 140 with a particular purpose within a namespace is called an assignment 141 (or, variously: an assigned number, assigned value, code point, 142 protocol constant, or protocol parameter). The act of assignment is 143 called a registration, and it takes place in the context of a 144 registry. The terms "assignment" and "registration" are used 145 interchangably throughout this document. 147 To make assignments in a given namespace prudently, IANA needs 148 guidance describing the conditions under which new values should be 149 assigned, as well as when and how modifications to existing values 150 can be made. This document defines a framework for the documentation 151 of these guidelines by specification authors, in order to assure that 152 the guidance given to IANA is clear and addresses the various issues 153 that are likely in the operation of a registry. 155 Typically, this information is recorded in a dedicated section of the 156 specification with the title "IANA Considerations". 158 1.1. Keep IANA Considerations for IANA 159 The purpose of having a dedicated IANA Considerations section is to 160 provide a single place to collect clear and concise information and 161 instructions for IANA. Technical documentation should reside in 162 other parts of the document, and should be included by reference 163 only. Using the IANA Considerations section as primary technical 164 documentation both hides it from the target audience of the document 165 and interferes with IANA's review of the actions they need to take. 167 If, for example, the registration of an item in a registry includes a 168 short description of the item being registered, that should be placed 169 in the IANA Considerations directly. But if it's necessary to 170 include a longer technical explanation of the purpose and use of the 171 item, the IANA Considerations should refer to a technical section of 172 the document where that information resides. Similarly, if the 173 document is pointing out the use of an existing assignment in a 174 registry, but makes no modification to the registration, that should 175 be in a technical section of the document, reserving the IANA 176 Considerations section for instructions to IANA. 178 An ideal IANA Considerations section clearly enumerates and specifies 179 each requested IANA action; includes all information IANA needs, such 180 as the full names of all applicable registries; and includes clear 181 references to elsewhere in the document for other information. 183 1.2. For More Information 185 IANA maintains a web page that includes current important information 186 from IANA. Document authors should check that page for additional 187 information, beyond what is provided here. 189 . 191 [[***** The URI above is not yet ready. IANA is setting it up. 192 *****]] 194 1.3. Terminology Used In This Document 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 198 document are to be interpreted as described in RFC 2119 [RFC2119]. 199 For this document, "the specification" as used by RFC 2119 refers to 200 the processing of protocol documents within the IETF standards 201 process. 203 2. Creating and Revising Registries 205 Defining a registry involves describing the namespace(s) to be 206 created, listing an initial set of assignments (if appropriate), and 207 documenting guidelines on how future assignments are to be made. 209 Before defining a registry, however, consider delegating the 210 namespace in some manner. This route should be pursued when 211 appropriate, as it lessens the burden on IANA for dealing with 212 assignments. 214 In particular, not all namespaces require a registry; in some cases, 215 assignments can be made independently and with no further (central) 216 coordination. In the Domain Name System, for example, IANA only 217 deals with assignments at the higher levels, while subdomains are 218 administered by the organization to which the space has been 219 delegated. When a namespace is delegated in this manner, the scope 220 of IANA is limited to the parts of the namespace where IANA has 221 authority. 223 2.1. Hierarchical Registry Structure 225 It's important to start with a word on the IANA registry structure. 226 All registries are anchored from the IANA "Protocol Registries" page: 228 . 230 That page lists registries in protocol category groups, like this: 232 --------------------------------------------------------------- 233 Author Domain Signing Practices (ADSP) Parameters 235 ADSP Outbound Signing Practices RFC 5617 236 IETF Review 238 ADSP Specification Tags RFC 5617 239 IETF Review 241 Automatic Responses to Electronic Mail Parameters 243 Auto-Submitted Header Field RFC 5436 244 Keywords Specification Required 246 Auto-Submitted header field RFC 3834 247 optional parameters IETF Consensus 249 Autonomous System (AS) Numbers 251 16-bit Autonomous System Numbers RFC 1930, RFC 5398, RFC 6996 252 RIR request to the IANA 253 or IETF Review 255 32-bit Autonomous System Numbers RFC 1930, RFC 5398, RFC 6793, 256 RFC 6996 257 RIR request to the IANA 258 or IETF Review 259 --------------------------------------------------------------- 261 The grouping allows related registries to be placed together, making 262 it easier for users of the registries to find the necessary 263 information. In the example section above, there are two registries 264 related to the ADSP protocol, and they are both placed in the "ADSP 265 Parameters" group. 267 Within the "ADSP Parameters" group are two registries: "ADSP Outbound 268 Signing Practices" and "ADSP Specification Tags". Clicking on the 269 title of one of these registries on the IANA Protocol Registries page 270 will take the reader to the details page for that registry. Often, 271 multiple registries are shown on the same details page. 273 Unfortunately, we have been inconsistent in how we refer to these 274 entities. The group names, as they are referred to here, have been 275 variously called "protocol category groups", "groups", "top-level 276 registries", or just "registries". The registries under them have 277 been called "registries" or "sub-registries". And when new 278 registries are created, the documents that define them often don't 279 specify the grouping at all, but only name the new registry. This 280 results in questions from IANA and delays in processing, or, worse, 281 in related registries that should have been grouped together, but 282 that are instead scattered about and hard to find and correlate. 284 Regardless of the terminology used, document authors should pay 285 attention to the registry groupings, should request that related 286 registries be grouped together, and, when creating a new registry, 287 should check whether that registry might best be included in an 288 existing group. That grouping information should be clearly 289 communicated to IANA in the registry creation request. 291 2.2. Documentation Requirements for Registries 293 Documents that create a new namespace (or modify the definition of an 294 existing space) and that expect IANA to play a role in maintaining 295 that space (serving as a repository for registered values) MUST 296 provide clear instructions on details of the namespace, either in the 297 IANA Considerations section, or referenced from it. 299 In particular, such instructions MUST include: 301 The name of the registry (or sub-registry) 302 This name will appear on the IANA web page and will be referred to 303 in future documents that need to allocate a value from the new 304 space. The full name (and abbreviation, if appropriate) should be 305 provided. It is highly desirable that the chosen name not be 306 easily confused with the name of another registry. 308 When creating a sub-registry, the registry that it is a part of 309 MUST be identified using its full name, exactly as it appears in 310 the IANA registry list. 312 Providing a URL to precisely identify the registry helps IANA 313 understand the request. Such URLs can be removed from the RFC 314 prior to final publication. If they are to be left in, it is 315 important that they be permanent links. IANA intends to include 316 the permalink for each registry in the registry header. Until 317 that is done, IANA can answer questions about the correct URLs to 318 use. 320 For example, a document could contain something like this: 322 This registration should be made in the Foobar Operational 323 Parameters registry, located at . 326 It might be tempting to use the URL that appears in your web 327 browser's address bar, which might look something like this for 328 the example above: 330 http://www.iana.org/assignments/foobar-registry/foobar- 331 registry.xml 333 ...but that is not the permanent link to the registry. 335 Required information for registrations 337 This information may include the need to document relevant 338 Security Considerations, if any. 340 Applicable review process 342 The review process that will apply to all future requests for 343 registration. See Section 2.3. 345 Size, format and syntax of registry entries 347 What fields to record in the registry, any technical requirements 348 on registry entries (valid ranges for integers, length limitations 349 on strings, and such), and the exact format in which registry 350 values should be displayed. For numeric assignments, one should 351 specify whether values are to be recorded in decimal, in 352 hexadecimal, or in some other format. For strings, the encoding 353 format should be specified (ASCII, UTF8, etc.). 355 Initial assignments and reservations 357 Any initial assignments or registrations to be included. In 358 addition, any ranges that are to be reserved for "Private Use", 359 "Reserved", "Unassigned", etc. (see Section 6) should be 360 indicated. 362 For example, a document might specify a new registry by including: 364 --------------------------------------------------------------- 366 X. IANA Considerations 368 This document defines a new DHCP option, entitled "FooBar" (see 369 Section y), assigned a value of TBD1 from the DHCP Option space 370 [to be removed upon publication: 371 http://www.iana.org/assignments/bootp-dhcp-parameters] 372 [RFC2132] [RFC2939]: 373 Data 374 Tag Name Length Meaning 375 ---- ---- ------ ------- 376 TBD1 FooBar N FooBar server 378 The FooBar option also defines an 8-bit FooType field, for which 379 IANA is to create and maintain a new sub-registry entitled 380 "FooType values" under the FooBar option. Initial values for the 381 DHCP FooBar FooType registry are given below; future assignments 382 are to be made through Expert Review [BCP26]. 383 Assignments consist of a DHCP FooBar FooType name and its 384 associated value. 386 Value DHCP FooBar FooType Name Definition 387 ---- ------------------------ ---------- 388 0 Reserved 389 1 Frobnitz See Section y.1 390 2 NitzFrob See Section y.2 391 3-254 Unassigned 392 255 Reserved 393 --------------------------------------------------------------- 395 For examples of documents that establish registries, consult 396 [RFC3575], [RFC3968], and [RFC4520]. 398 2.3. Defining an Appropriate Registry Policy 400 There are several issues to consider when defining the policy for the 401 new assignments in a registry. 403 If the registry's namespace is limited, assignments will need to be 404 made carefully to prevent exhaustion. 406 Even when the space is essentially unlimited, however, it is usually 407 desirable to have at least a minimal review prior to assignment in 408 order to: 410 o prevent the hoarding of or unnecessary wasting of values. For 411 example, if the space consists of text strings, it may be 412 desirable to prevent entities from obtaining large sets of strings 413 that correspond to desirable names (existing company names, for 414 example). 416 o provide a sanity check that the request actually makes sense and 417 is necessary. Experience has shown that some level of minimal 418 review from a subject matter expert is useful to prevent 419 assignments in cases where the request is malformed or not 420 actually needed (for example, an existing assignment for an 421 essentially equivalent service already exists). 423 Perhaps most importantly, unreviewed extensions can impact 424 interoperability and security. See [RFC6709]. 426 When the namespace is essentially unlimited and there are no 427 potential interoperability or security issues, assigned numbers can 428 usually be given out to anyone without any subjective review. In 429 such cases, IANA can make assignments directly, provided that IANA is 430 given detailed instructions on what types of requests it should 431 grant, and it is able to do so without exercising subjective 432 judgement. 434 When this is not the case, some level of review is required. 435 However, it's important to balance adequate review and ease of 436 registration. In many cases, those making registrations will not be 437 IETF participants; requests often come from other standards 438 organizations, from organizations not directly involved in standards, 439 from ad-hoc community work (from an open-source project, for 440 example), and so on. Registration must not be unnecessarily 441 difficult, unnecessarily costly (in terms of time and other 442 resources), nor unnecessarily subject to denial. 444 While it is sometimes necessary to restrict what gets registered 445 (e.g., for limited resources such as bits in a byte, or for items for 446 which unsupported values can be damaging to protocol operation), in 447 many cases having what's in use represented in the registry is more 448 important. Overly strict review criteria and excessive cost (in time 449 and effort) discourage people from even attempting to make a 450 registration. If a registry fails to reflect the protocol elements 451 actually in use, it can adversely affect deployment of protocols on 452 the Internet, and the registry itself is devalued. 454 In particular, when a registry policy that requires involvement of 455 Working Groups, directorates, or other bodies to be actively involved 456 and to support the effort, requests frequently run into concerns that 457 "it's not worth doing a Standards-Track RFC for something this 458 trivial," when, in fact, that requirement was created by the Working 459 Group in the first place, by placing the bar that high. 461 Indeed, publishing any RFC is costly, and a Standards Track RFC is 462 especially so, requiring a great deal of community time for review 463 and discussion, IETF-wide last call, involvement of the entire IESG 464 as well as concentrated time and review from the sponsoring AD, 465 review and action by IANA, and RFC-Editor processing. 467 Therefore, Working Groups and other document developers should use 468 care in selecting appropriate registration policies when their 469 documents create registries. They should select the least strict 470 policy that suits a registry's needs, and look for specific 471 justification for policies that require significant community 472 involvement (Specification Required, in terms of the well-known 473 policies). 475 2.3.1. Using the Well-Known Registration Policies 477 This document defines a number of registration policies in Section 4. 478 Because they benefit from both community experience and wide 479 understanding, their use is encouraged when appropriate. 481 It is also acceptable to cite one of the well-known policies and 482 include additional guidelines for what kind of considerations should 483 be taken into account by the review process. 485 For example, RADIUS [RFC3575] specifies the use of a Designated 486 Expert, but includes specific additional criteria the Designated 487 Expert should follow. 489 The well-known policies from "First Come First Served" to "Standards 490 Action" specify a range of policies in increasing order of strictness 491 (using the numbering from the full list in Section 4): 493 4. First Come First Served 494 No review, minimal documentation. 496 5. Expert Review 497 Expert review, sufficient documentation for review. 499 6. Specification Required 500 Expert review, significant, stable public documentation. 502 7. RFC Required 503 Any RFC publication, IETF or a non-IETF Stream. 505 8. IETF Review 506 RFC publication, IETF Stream only, but need not be Standards 507 Track. 509 9. Standards Action 510 RFC publication, IETF Stream, Standards Track only. 512 Examples of situations that might merit RFC Required, IETF Review, or 513 Standards Action include the following: 515 o When a resource is limited, such as bits in a byte (or in two 516 bytes, or four), or numbers in a limited range. In these cases, 517 allowing registrations that haven't been carefully reviewed and 518 agreed by community consensus could too quickly deplete the 519 allowable values. 521 o When thorough community review is necessary to avoid extending or 522 modifying the protocol in ways that could be damaging. One 523 example is in defining new command codes, as opposed to options 524 that use existing command codes: the former might require a strict 525 policy, where a more relaxed policy could be adequate for the 526 latter. Another example is in defining protocol elements that 527 change the semantics of existing operations. 529 The description in Section 4.10 of "IESG Approval" suggests that the 530 IESG "can (and should) reject a request if another path for 531 registration is available that is more appropriate and there is no 532 compelling reason not to use that path." The IESG should give 533 similar consideration to any registration policy more stringent than 534 Specification Required, asking for justification and ensuring that 535 more relaxed policies have been considered, and the strict policy is 536 the right one. 538 Accordingly, document developers need to anticipate this and document 539 their considerations for selecting the specified policy (ideally, in 540 the document itself; failing that, in the shepherd writeup). 541 Likewise, the document shepherd should ensure that the selected 542 policies have been justified before sending the document to the IESG. 544 When specifications are revised, registration policies should be 545 reviewed in light of experience since the policies were set. 547 Note that the well-known policies are not exclusive; there are 548 situations where a different policy might be more appropriate. 550 2.3.2. Using Multiple Policies in Combination 552 In some situations, it is necessary to define multiple registration 553 policies. For example, registrations through the normal IETF process 554 might use one policy, while registrations from outside the process 555 would have a different policy applied. 557 Thus, a particular registry might want to use a policy such as "RFC 558 Required" or "IETF Review" sometimes, with a designated expert 559 checking a "Specification Required" policy at other times. 561 The alternative to using a combination requires either that all 562 requests come through RFCs or that requests in RFCs go through review 563 by the designated expert, even though they already have IETF review 564 and consensus. 566 This can be documented in the IANA Considerations section when the 567 registry is created: 569 IANA is asked to create the registry "Fruit Access Flags" as a 570 sub-registry of "Fruit Parameters". New registrations will be 571 permitted through either the IETF Review policy or the 572 Specification Required policy [BCP26]. 574 Such combinations will commonly use one of {Standards Action, IETF 575 Review, RFC Required} in combination with one of {Specification 576 Required, Expert Review}. 578 2.3.3. Specifying Change Control for a Registry 580 Registry definitions and registrations within registries often need 581 to be changed after they are created. The process of making such 582 changes is complicated when it is unclear who is authorized to make 583 the changes. For registries created by RFCs in the IETF stream, 584 change control for the registry lies by default with the IETF, via 585 the IESG. The same is true for value registrations made in IETF- 586 stream RFCs. 588 Because registries can be created and registrations can be made 589 outside the IETF stream, it can sometimes be desired to have change 590 control outside the IETF and IESG, and clear specification of change 591 control policies is always helpful. 593 It is advised, therefore, that all registries that are created 594 clearly specify a change control policy and a change controller. It 595 is also advised that registries that allow registrations from outside 596 the IETF stream include, for each value, the designation of a change 597 controller for that value. If the definition or reference for a 598 registered value ever needs to change, or if a registered value needs 599 to be deprecated, it is critical that IANA know who is authorized to 600 make the change. See also Section 9.5. 602 2.4. Revising Existing Registries 604 Updating the registration process or making changes to the format of 605 an already existing (previously created) registry (whether created 606 explicitly or implicitly) follows a process similar to that used when 607 creating a new registry. That is, a document is produced that makes 608 reference to the existing namespace and then provides detailed 609 guidance for handling assignments in the registry, or detailed 610 instructions about the changes required. 612 If a change requires a new column in the registry, the instructions 613 need to be clear about how to populate that column for the existing 614 entries. Other changes may require similar clarity. Remember to 615 check this, and give clear instructions to IANA. 617 Such documents are normally processed with the same document status 618 as the document that created the registry, or as Best Current 619 Practices (BCPs) [RFC2026]. 621 Example documents that updated the guidelines for assignments in pre- 622 existing registries include: [RFC6195], [RFC3228], and [RFC3575]. 624 3. Registering New Values in an Existing Registry 626 3.1. Documentation Requirements for Registrations 628 Often, documents request an assignment in an existing namespace (one 629 created by a previously published document). 631 Such documents should clearly identify the namespace into which each 632 value is to be registered. If the registration goes into a sub- 633 registry, the author should clearly explain that. Use the exact 634 namespace name as listed on the IANA web page, and cite the RFC where 635 the namespace is defined. 637 There is no need to mention what the assignment policy is when making 638 new assignments in existing registries, as that should be clear from 639 the references. 641 When referring to an existing registry, providing a URL to precisely 642 identify the registry is helpful. See Section 2.2 for details on 643 specifying the correct URL. 645 For example, a document could contain something like this: 647 This registration should be made in the Foobar Operational 648 Parameters registry, located at . 651 Normally, numeric values to be used are chosen by IANA when the 652 document is approved, and drafts should not specify final values. 653 Instead, placeholders such as "TBD1" and "TBD2" should be used 654 consistently throughout the document, giving each item to be 655 registered a different placeholder. The IANA Considerations should 656 ask the RFC Editor to replace the placeholder names with the IANA- 657 assigned values. When drafts need to specify numeric values for 658 testing or early implementations, they will either request early 659 allocation (see Section 3.4) or use values that have already been set 660 aside for testing or experimentation. It is important that drafts 661 not choose their own values, lest IANA assign one of those values to 662 another document in the meantime. A draft can request a specific 663 value in the IANA Considerations section, and IANA will accommodate 664 such requests when that's possible, but the proposed number might 665 have been assigned to some other use by the time the draft is 666 approved. 668 Normally, text-string values to be used are specified in the 669 document, as collisions are less likely with text strings. IANA will 670 consult with the authors if there is, in fact, a collision, and a 671 different value has to be used. When drafts need to specify string 672 values for testing or early implementations, they sometimes use the 673 expected final value. But it is often useful to use a draft value 674 instead, possibly including the draft version number. This allows 675 the early implementations to be distinguished from those implementing 676 the final version. A document that intends to use "foobar" in the 677 final version might use "foobar-testing-draft-05" for the -05 version 678 of the draft, for example. 680 For some registries, IANA has a long-standing policy prohibiting 681 assignment of names or codes on a vanity or organization-name basis. 682 For example, codes might always be assigned sequentially unless there 683 is a strong reason for making an exception. Nothing in this document 684 is intended to change those policies or prevent their future 685 application. 687 The IANA Considerations section should summarize all of the IANA 688 actions, with pointers to the relevant sections elsewhere in the 689 document as appropriate. When multiple values are requested, it is 690 generally helpful to include a summary table. It is also helpful for 691 this table to be in the same format as it appears or will appear on 692 the IANA web site. For example: 694 Value Description Reference 695 -------- ------------------- --------- 696 TBD1 Foobar [[this RFC]] 698 Note: In cases where authors feel that including the full table is 699 too verbose or repetitive, authors should still include the table in 700 the draft, but may include a note asking that the table be removed 701 prior to publication of the final RFC. 703 As an example, the following text could be used to request assignment 704 of a DHCPv6 option number: 706 IANA has assigned an option code value of TBD1 to the DNS 707 Recursive Name Server option and an option code value of TBD2 to 708 the Domain Search List option from the DHCP option code space 709 defined in Section 24.3 of RFC 3315. 711 3.2. Updating Existing Registrations 713 Even after a number has been assigned, some types of registrations 714 contain additional information that may need to be updated over time. 716 For example, MIME media types, character sets, and language tags 717 typically include more information than just the registered value 718 itself, and may need updates to items such as point-of-contact 719 information, security issues, pointers to updates, and literature 720 references. 722 In such cases, the document defining the namespace must clearly state 723 who is responsible for maintaining and updating a registration. 724 Depending on the registry, it may be appropriate to specify one or 725 more of: 727 o Letting registrants and/or nominated change controllers update 728 their own registrations, subject to the same constraints and 729 review as with new registrations. 731 o Allowing attachment of comments to the registration. This can be 732 useful in cases where others have significant objections to a 733 registration, but the author does not agree to change the 734 registration. 736 o Designating the IESG, a designated expert, or another entity as 737 having the right to change the registrant associated with a 738 registration and any requirements or conditions on doing so. This 739 is mainly to get around the problem when a registrant cannot be 740 reached in order to make necessary updates. 742 3.3. Overriding Registration Procedures 744 Experience has shown that the documented IANA considerations for 745 individual protocols do not always adequately cover the reality of 746 registry operation, or are not sufficiently clear. In addition, 747 documented IANA considerations are sometimes found to be too 748 stringent to allow even working group documents (for which there is 749 strong consensus) to perform a registration in advance of actual RFC 750 publication. 752 In order to allow assignments in such cases, the IESG is granted 753 authority to override registration procedures and approve assignments 754 on a case-by-case basis. 756 The intention here is not to overrule properly documented procedures, 757 or to obviate the need for protocols to properly document their IANA 758 considerations. Rather, it is to permit assignments in specific 759 cases where it is obvious that the assignment should just be made, 760 but updating the IANA process beforehand is too onerous. 762 When the IESG is required to take action as described in this 763 section, it is a strong indicator that the applicable registration 764 procedures should be updated, possibly in parallel with the work that 765 instigated it. 767 3.4. Early Allocations 768 IANA normally takes its actions when a document is approved for 769 publication. There are times, though, when early allocation of a 770 value is important for the development of a technology: for example, 771 when early implementations are created while the document is still 772 under development. 774 IANA has a mechanism for handling such early allocations in some 775 cases. See [RFC7120] for details. 777 4. Well-Known Registration Policies 779 The following are some defined policies, most of which are in use 780 today. These cover a range of typical policies that have been used 781 to describe the procedure for assigning new values in a namespace. 782 It is not strictly required that documents use these terms; the 783 actual requirement is that the instructions to IANA be clear and 784 unambiguous. However, use of these terms is strongly RECOMMENDED, 785 because their meanings are widely understood. The terms are fully 786 explained in the following subsections. 788 1. Private Use 789 2. Experimental Use 790 3. Hierarchical Allocation 791 4. First Come First Served 792 5. Expert Review 793 6. Specification Required 794 7. RFC Required 795 8. IETF Review 796 9. Standards Action 797 10. IESG Approval 799 It should be noted that it often makes sense to partition a namespace 800 into multiple categories, with assignments within each category 801 handled differently. Many protocols now partition namespaces into 802 two or more parts, with one range reserved for Private or 803 Experimental Use while other ranges are reserved for globally unique 804 assignments assigned following some review process. Dividing a 805 namespace into ranges makes it possible to have different policies in 806 place for different ranges and different use cases. 808 Similarly, it will often be useful to specify multiple policies in 809 parallel, with each policy being used under different circumstances. 811 For more discussion of that topic, see Section 2.3.2. 813 Examples of RFCs that specify multiple policies in parallel: 815 LDAP [RFC4520] 816 TLS ClientCertificateType Identifiers [RFC5246] (as detailed in 817 the subsections below) 818 Pseudowire Edge to Edge Emulation (PWE3) [RFC4446] 820 4.1. Private Use 822 For private or local use only, with the type and purpose defined by 823 the local site. No attempt is made to prevent multiple sites from 824 using the same value in different (and incompatible) ways. There is 825 no need for IANA to review such assignments (since IANA does not 826 record them) and assignments are not generally useful for broad 827 interoperability. It is the responsibility of the sites making use 828 of the Private Use range to ensure that no conflicts occur (within 829 the intended scope of use). 831 Examples: 833 Site-specific options in DHCP [RFC2939] 834 Fibre Channel Port Type Registry [RFC4044] 835 TLS ClientCertificateType Identifiers 224-255 [RFC5246] 837 4.2. Experimental Use 839 Experimental Use is similar to Private Use only, but with the purpose 840 being to facilitate experimentation. See [RFC3692] for details. 842 Example: 844 Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP 845 Headers [RFC4727] 847 4.3. Hierarchical Allocation 849 With Hierarchical Allocation, delegated administrators are given 850 control over part of the namespace, and can assign values in that 851 part of the namespace. IANA makes allocations in the higher levels 852 of the namespace according to one of the other policies. 854 Examples: 856 DNS names 857 Object Identifiers 858 IP addresses 860 4.4. First Come First Served 861 For the First Come First Served policy, assignments are made to 862 anyone on a first come, first served basis. There is no substantive 863 review of the request, other than to ensure that it is well-formed 864 and doesn't duplicate an existing assignment. However, requests must 865 include a minimal amount of clerical information, such as a point of 866 contact (including an email address, and sometimes a postal address) 867 and a brief description of how the value will be used. Additional 868 information specific to the type of value requested may also need to 869 be provided, as defined by the namespace. For numbers, the exact 870 value is generally assigned by IANA; with names, specific text 871 strings can usually be requested. 873 When creating a new registry with First Come First Served as the 874 registration policy, in addition to the contact person field or 875 reference, the registry should contain a field for change controller. 876 Having a change controller for each entry for these types of 877 registrations makes authorization of future modifications more clear. 878 See Section 2.3.3 880 Examples: 882 SASL mechanism names [RFC4422] 883 LDAP Protocol Mechanisms and LDAP Syntax [RFC4520] 885 4.5. Expert Review 887 (Also called "Designated Expert" in earlier editions of this 888 document.) For the Expert Review policy, review and approval by a 889 designated expert (see Section 5) is required. The required 890 documentation and review criteria for use by the designated expert 891 should be provided when defining the registry. For example, see 892 Sections 6 and 7.2 in [RFC3748]. 894 It is particularly important, when using a designated expert, to give 895 clear guidance to the expert, laying out criteria for performing an 896 evaluation and reasons for rejecting a request. When specifying a 897 policy that involves a designated expert, the IANA Considerations 898 SHOULD contain such guidance. It is also a good idea to include, 899 when possible, a sense of whether many registrations are expected 900 over time, or if the registry is expected to be updated infrequently 901 or in exceptional circumstances only. 903 When creating a new registry with Expert Review as the registration 904 policy, in addition to the contact person field or reference, the 905 registry should contain a field for change controller. Having a 906 change controller for each entry for these types of registrations 907 makes authorization of future modifications more clear. See Section 908 2.3.3 910 Examples: 912 EAP Method Types [RFC3748] 913 HTTP Digest AKA algorithm versions [RFC4169] 914 URI schemes [RFC4395] 915 GEOPRIV Location Types [RFC4589] 917 4.6. Specification Required 919 For the Specification Required policy, review and approval by a 920 designated expert (see Section 5) is required, and the values and 921 their meanings must be documented in a permanent and readily 922 available public specification, in sufficient detail so that 923 interoperability between independent implementations is possible. 924 The designated expert will review the public specification and 925 evaluate whether it is sufficiently clear to allow interoperable 926 implementations. The intention behind "permanent and readily 927 available" is that a document can reasonably be expected to be 928 findable and retrievable long after IANA assignment of the requested 929 value. Publication of an RFC is an ideal means of achieving this 930 requirement, but Specification Required is intended to also cover the 931 case of a document published outside of the RFC path. For RFC 932 publication, the normal RFC review process is expected to provide the 933 necessary review for interoperability, though the designated expert 934 may be a particularly well-qualified person to perform such a review. 936 When specifying this policy, just use the term "Specification 937 Required". Some specifications have chosen to refer to it as "Expert 938 Review with Specification Required", and that only causes confusion. 940 Examples: 942 Diffserv-aware TE Bandwidth Constraints Model Identifiers 943 [RFC4124] 944 TLS ClientCertificateType Identifiers 64-223 [RFC5246] 945 ROHC Profile Identifiers [RFC5795] 947 4.7. RFC Required 949 With the RFC Required policy, the registration request, along with 950 associated documentation, must be published in an RFC. The RFC need 951 not be in the IETF stream, but may be in any RFC stream (currently an 952 RFC may be in the IETF, IRTF, or IAB stream, or an RFC Editor 953 Independent Submission [RFC5742]). Unless otherwise specified, any 954 type of RFC is sufficient (currently Standards Track, BCP, 955 Informational, Experimental, or Historic). 957 4.8. IETF Review 959 (Formerly called "IETF Consensus" in the first edition of this 960 document.) With the IETF Review policy, new values are assigned only 961 through RFCs in the IETF Stream -- those that have been shepherded 962 through the IESG as AD-Sponsored or IETF working group Documents 964 [RFC2026] [RFC5378]. 966 The intent is that the document and proposed assignment will be 967 reviewed by the IETF community (including appropriate IETF working 968 groups, directorates, and other experts) and by the IESG, to ensure 969 that the proposed assignment will not negatively affect 970 interoperability or otherwise extend IETF protocols in an 971 inappropriate or damaging manner. To ensure adequate community 972 review, such documents will always undergo an IETF Last Call. 974 Examples: 976 IPSECKEY Algorithm Types [RFC4025] 977 Accounting-Auth-Method AVP values in DIAMETER [RFC4005] 978 TLS Extension Types [RFC5246] 980 4.9. Standards Action 982 For the Standards Action policy, values are assigned only through 983 Standards Track RFCs approved by the IESG. 985 Examples: 987 BGP message types [RFC4271] 988 Mobile Node Identifier option types [RFC4283] 989 TLS ClientCertificateType Identifiers 0-63 [RFC5246] 990 DCCP Packet Types [RFC4340] 992 4.10. IESG Approval 994 New assignments may be approved by the IESG. Although there is no 995 requirement that the request be documented in an RFC, the IESG has 996 discretion to request documents or other supporting materials on a 997 case-by-case basis. 999 IESG Approval is not intended to be used often or as a "common case"; 1000 indeed, it has seldom been used in practice during the period RFC 1001 2434 was in effect. Rather, it is intended to be available in 1002 conjunction with other policies as a fall-back mechanism in the case 1003 where one of the other allowable approval mechanisms cannot be 1004 employed in a timely fashion or for some other compelling reason. 1005 IESG Approval is not intended to circumvent the public review 1006 processes implied by other policies that could have been employed for 1007 a particular assignment. IESG Approval would be appropriate, 1008 however, in cases where expediency is desired and there is strong 1009 consensus (such as from a working group) for making the assignment. 1011 The following guidelines are suggested for any evaluation under IESG 1012 Approval: 1014 o The IESG can (and should) reject a request if another path for 1015 registration is available that is more appropriate and there is no 1016 compelling reason not to use that path. 1018 o Before approving a request, the community should be consulted, via 1019 a "call for comments" that provides as much information as is 1020 reasonably possible about the request. 1022 Examples: 1024 IPv4 Multicast address assignments [RFC5771] 1025 IPv4 IGMP Type and Code values [RFC3228] 1026 Mobile IPv6 Mobility Header Type and Option values [RFC6275] 1028 5. Designated Experts 1030 5.1. The Motivation for Designated Experts 1032 IANA does not define registry policy itself; rather, it carries out 1033 policies that have been defined by others and published in RFCs. As 1034 part of that process, review of proposed registrations is often 1035 appropriate. 1037 A common way to ensure such review is for a proposed registration to 1038 be published as an RFC, as this ensures that the specification is 1039 publicly and permanently available. It is particularly important if 1040 any potential interoperability issues might arise. For example, some 1041 assignments are not just assignments, but also involve an element of 1042 protocol specification. A new option may define fields that need to 1043 be parsed and acted on, which (if specified poorly) may not fit 1044 cleanly with the architecture of other options or the base protocols 1045 on which they are built. 1047 In some cases, however, the burden of publishing an RFC in order to 1048 register a protocol element is excessive. 1050 However, it is generally still useful (and sometimes necessary) to 1051 discuss proposed registrations within the community, on a mailing 1052 list. Such a mailing list provides opportunity for public review 1053 prior to assignment, and allows for a consultative process when 1054 registrants want help in understanding what a proper registration 1055 should contain. 1057 While discussion on a mailing list can provide valuable technical 1058 feedback, opinions may vary and discussions may continue for some 1059 time without clear resolution. In addition, IANA cannot participate 1060 in all of these mailing lists and cannot determine if or when such 1061 discussions reach consensus. Therefore, IANA relies on a "designated 1062 expert" for advice regarding the specific question of whether an 1063 assignment should be made. The designated expert is an individual 1064 who is responsible for carrying out an appropriate evaluation and 1065 returning a recommendation to IANA. 1067 It should be noted that a key motivation for having designated 1068 experts is for the IETF to provide IANA with a subject matter expert 1069 to whom the evaluation process can be delegated. IANA forwards 1070 requests for an assignment to the expert for evaluation, and the 1071 expert (after performing the evaluation) informs IANA as to whether 1072 or not to make the assignment or registration. 1074 It will often be useful to use a designated expert only some of the 1075 time, as a supplement to other processes. For more discussion of 1076 that topic, see Section 2.3.2. 1078 5.2. The Role of the Designated Expert 1080 The designated expert is responsible for coordinating the appropriate 1081 review of an assignment request. The review may be wide or narrow, 1082 depending on the situation and the judgment of the designated expert. 1083 This may involve consultation with a set of technology experts, 1084 discussion on a public mailing list, consultation with a working 1085 group (or its mailing list if the working group has disbanded), etc. 1086 Ideally, the designated expert follows specific review criteria as 1087 documented with the protocol that creates or uses the namespace. See 1088 the IANA Considerations sections of [RFC3748] and [RFC3575] for 1089 specific examples. 1091 Designated experts are expected to be able to defend their decisions 1092 to the IETF community, and the evaluation process is not intended to 1093 be secretive or bestow unquestioned power on the expert. Experts are 1094 expected to apply applicable documented review or vetting procedures, 1095 or in the absence of documented criteria, follow generally accepted 1096 norms such as those in Section 5.3. 1098 In registries where a pool of experts evaluates requests, the pool 1099 should have a single chair responsible for defining how requests are 1100 to be assigned to and reviewed by experts. In some cases, the expert 1101 pool may consist of a primary and backups, with the backups involved 1102 only when the primary expert is unavailable. In other cases, IANA 1103 might assign requests to individual members in sequential or 1104 approximate random order. In the event that IANA finds itself having 1105 received conflicting advice from its experts, it is the 1106 responsibility of the pool's chair to resolve the issue and provide 1107 IANA with clear instructions. 1109 If a designated expert is conflicted for a particular review (is, for 1110 example, an author or significant proponent of a specification 1111 related to the registration under review), that expert should recuse 1112 himself. In the event that all the designated experts are 1113 conflicted, they should ask that a temporary expert be designated for 1114 the conflicted review. 1116 It has proven useful to have multiple designated experts for some 1117 registries. Sometimes those experts work together in evaluating a 1118 request, while in other cases additional experts serve as backups. 1119 In cases of disagreement among those experts, it is the 1120 responsibility of those experts to make a single clear recommendation 1121 to IANA. It is not appropriate for IANA to resolve disputes among 1122 experts. In extreme situations, such as deadlock, the designating 1123 body may need to step in to resolve the problem. 1125 This document defines the designated expert mechanism with respect to 1126 documents in the IETF stream only. Documents in other streams may 1127 only use a registration policy that requires a designated expert if 1128 those streams (or those documents) specify how designated experts are 1129 appointed and managed. What is described below, with management by 1130 the IESG, is only appropriate for the IETF stream. 1132 5.2.1. Managing Designated Experts in the IETF 1134 Designated experts for registries created by the IETF are appointed 1135 by the IESG, normally upon recommendation by the relevant Area 1136 Director. They may be appointed at the time a document creating or 1137 updating a namespace is approved by the IESG, or subsequently, when 1138 the first registration request is received. Because experts 1139 originally appointed may later become unavailable, the IESG will 1140 appoint replacements as necessary. The IESG may remove any 1141 designated expert that it appointed, at its discretion. 1143 The normal appeals process, as described in [RFC2026], Section 6.5.1, 1144 applies to issues that arise with the designated expert team. For 1145 this purpose, the designated expert team takes the place of the 1146 working group in that description. 1148 5.3. Designated Expert Reviews 1150 In the years since RFC 2434 was published and has been put to use, 1151 experience has led to the following observations: 1153 o A designated expert must respond in a timely fashion, normally 1154 within a week for simple requests to a few weeks for more complex 1155 ones. Unreasonable delays can cause significant problems for 1156 those needing assignments, such as when products need code points 1157 to ship. This is not to say that all reviews can be completed 1158 under a firm deadline, but they must be started, and the requester 1159 and IANA should have some transparency into the process if an 1160 answer cannot be given quickly. 1162 o If a designated expert does not respond to IANA's requests within 1163 a reasonable period of time, either with a response or with a 1164 reasonable explanation for the delay (some requests may be 1165 particularly complex), and if this is a recurring event, IANA must 1166 raise the issue with the IESG. Because of the problems caused by 1167 delayed evaluations and assignments, the IESG should take 1168 appropriate actions to ensure that the expert understands and 1169 accepts his or her responsibilities, or appoint a new expert. 1171 o The designated expert is not required to personally bear the 1172 burden of evaluating and deciding all requests, but acts as a 1173 shepherd for the request, enlisting the help of others as 1174 appropriate. In the case that a request is denied, and rejecting 1175 the request is likely to be controversial, the expert should have 1176 the support of other subject matter experts. That is, the expert 1177 must be able to defend a decision to the community as a whole. 1179 When a designated expert is used, the documentation should give clear 1180 guidance to the designated expert, laying out criteria for performing 1181 an evaluation and reasons for rejecting a request. In the case where 1182 there are no specific documented criteria, the presumption should be 1183 that a code point should be granted unless there is a compelling 1184 reason to the contrary. Possible reasons to deny a request include 1185 these: 1187 o Scarcity of code points, where the finite remaining code points 1188 should be prudently managed, or where a request for a large number 1189 of code points is made and a single code point is the norm. 1191 o Documentation is not of sufficient clarity to evaluate or ensure 1192 interoperability. 1194 o The code point is needed for a protocol extension, but the 1195 extension is not consistent with the documented (or generally 1196 understood) architecture of the base protocol being extended, and 1197 would be harmful to the protocol if widely deployed. It is not 1198 the intent that "inconsistencies" refer to minor differences "of a 1199 personal preference nature". Instead, they refer to significant 1200 differences such as inconsistencies with the underlying security 1201 model, implying a change to the semantics of an existing message 1202 type or operation, requiring unwarranted changes in deployed 1203 systems (compared with alternate ways of achieving a similar 1204 result), etc. 1206 o The extension would cause problems with existing deployed systems. 1208 o The extension would conflict with one under active development by 1209 the IETF, and having both would harm rather than foster 1210 interoperability. 1212 When a designated expert is used, documents MUST NOT name the 1213 designated expert in the document itself; instead, any suggested 1214 names should be relayed to the appropriate Area Director at the time 1215 the document is sent to the IESG for approval. This is usually done 1216 in the document shepherd writeup. 1218 If the request should also be reviewed on a specific public mailing 1219 list, its address should be specified. 1221 5.4. Expert Reviews and the Document Lifecycle 1223 Review by the designated expert is necessarily done at a particular 1224 point in time, and represents review of a particular version of the 1225 document. Deciding when the review should take place is a question 1226 of good judgment. And while re-reviews might be done when it's 1227 acknowledged that the documentation of the registered item has 1228 changed substantially, making sure that re-review happens requires 1229 attention and care. 1231 It is possible, through carelessness, accident, inattentiveness, or 1232 even willful disregard, that changes might be made after the 1233 designated expert's review and approval that would, if the document 1234 were re-reviewed, cause the expert not to approve the registration. 1235 It is up to the IESG, with the token held by the responsible Area 1236 Director, to be alert to such situations and to recognize that such 1237 changes need to be checked. 1239 6. Well-Known Registration Status Terminology 1241 The following labels describe the status of an assignment or range of 1242 assignments: 1244 Private Use: Private use only (not assigned), as described in 1245 Section 4.1. 1247 Experimental: Available for general experimental use as described 1248 in [RFC3692]. IANA does not record specific assignments for 1249 any particular use. 1251 Unassigned: Not currently assigned, and available for assignment 1252 via documented procedures. While it's generally clear that 1253 any values that are not registered are unassigned and 1254 available for assignment, it is sometimes useful to 1255 explicitly specify that situation. Note that this is 1256 distinctly different from "Reserved". 1258 Reserved: Not assigned and not available for assignment. Reserved 1259 values are held for special uses, such as to extend the 1260 namespace when it becomes exhausted. Note that this is 1261 distinctly different from "Unassigned". 1263 Reserved values can be released for assignment by the change 1264 controller for the registry (this is often the IESG, for 1265 registries created by RFCs in the IETF stream). 1267 7. Documentation References in IANA Registries 1269 Usually, registries and registry entries include references to 1270 documentation (RFCs or other documents). The purpose of these 1271 references is to provide pointers for implementors to find details 1272 necessary for implementation, NOT to simply note what document 1273 created the registry or entry. Therefore: 1275 o If a document registers an item that is defined and explained 1276 elsewhere, the registered reference should be to that document, 1277 and not to the document that is merely performing the 1278 registration. 1280 o If the registered item is defined and explained in the current 1281 document, it is important to include sufficient information to 1282 enable implementors to understand the item and to create a proper 1283 implementation. 1285 o If the registered item is explained primarily in a specific 1286 section of the reference document, it is useful to include a 1287 section reference. For example, "[RFC9876], Section 3.2", rather 1288 than just "[RFC9876]". 1290 o For documentation of a new registry, the reference should provide 1291 information about the registry itself, not just a pointer to the 1292 creation of it. Useful information includes the purpose of the 1293 registry, a rationale for its creation, documentation of the 1294 process and policy for new registrations, guidelines for new 1295 registrants or designated experts, and other such related 1296 information. But note that, while it's important to include this 1297 information in the document, it needn't (and shouldn't) all be in 1298 the IANA Considerations section. See Section 1.1. 1300 8. What to Do in "bis" Documents 1302 On occasion, an RFC is issued that obsoletes a previous edition of 1303 the same document. We sometimes call these "bis" documents, such as 1304 when RFC 9876 is updated by draft-ietf-foo-rfc9876bis. When the 1305 original document created registries and/or registered entries, there 1306 is a question of how to handle the IANA Considerations section in the 1307 "bis" document. 1309 If the registrations specify the original document as a reference, 1310 those registrations should be updated to point to the current (not 1311 obsolete) documentation for those items. Usually, that will mean 1312 changing the reference to be the "bis" document. There will, though, 1313 be times when a document updates another, and changes the definitive 1314 reference for some items, but not for others. Be sure that the 1315 references are always set to point to the correct, current 1316 documentation for each item. 1318 For example, suppose RFC 9876 registered the "BANANA" flag in the 1319 "Fruit Access Flags" registry, and the documentation for that flag is 1320 in Section 3.2. 1322 The current registry might look, in part, like this: 1324 Name Description Reference 1325 -------- ------------------- --------- 1326 BANANA Flag for bananas [RFC9876], Section 3.2 1328 If draft-ietf-foo-rfc9876bis obsoletes RFC 9876 and, because of some 1329 rearrangement, now documents the flag in Section 4.1.2, the IANA 1330 Considerations of the bis document might contain text such as this: 1332 IANA is asked to change the registration information for the 1333 BANANA flag in the "Fruit Access Flags" registry to the following: 1335 Name Description Reference 1336 -------- ------------------- --------- 1337 BANANA Flag for bananas [[this RFC]], Section 4.2.1 1339 In many cases, if there are a number of registered references to the 1340 original RFC and the document organization has not changed the 1341 registered section numbering much, it may simply be reasonable to do 1342 this: 1344 Because this document obsoletes RFC 9876, IANA is asked to change 1345 all registration information that references [RFC9876] to instead 1346 reference [[this RFC]]. 1348 If information for registered items has been or is being moved to 1349 other documents, then, of course, the registration information should 1350 be changed to point to those other documents. In no case is it 1351 reasonable to leave documentation pointers to the obsoleted document 1352 for any registries or registered items that are still in current use. 1354 It is extremely important to be clear in your instructions regarding 1355 updating references, especially in cases where some references need 1356 to be updated and others do not. 1358 9. Miscellaneous Issues 1360 9.1. When There Are No IANA Actions 1361 Before an Internet-Draft can be published as an RFC, IANA needs to 1362 know what actions (if any) it needs to perform. Experience has shown 1363 that it is not always immediately obvious whether a document has no 1364 IANA actions, without reviewing the document in some detail. In 1365 order to make it clear to IANA that it has no actions to perform (and 1366 that the author has consciously made such a determination), such 1367 documents should include an IANA Considerations section that states: 1369 This document has no IANA actions. 1371 This statement, or an equivalent, must only be inserted after the 1372 working group or individual submitter has carefully verified it to be 1373 true. Using such wording as a matter of "boilerplate" or without 1374 careful consideration can lead to incomplete or incorrect IANA 1375 actions being performed. 1377 If a specification makes use of values from a namespace in which 1378 assignments are not made by IANA, it may be useful to note this fact, 1379 with wording such as this: 1381 The values of the Foobar parameter are assigned by the Barfoo 1382 registry on behalf of the Rabfoo Forum. Therefore, this document 1383 has no IANA actions. 1385 IANA prefers that these "empty" IANA Considerations sections be left 1386 in the document for the record. This is a change from the prior 1387 practice of requesting that such sections be removed by the RFC 1388 Editor, and authors are asked to accommodate this change. 1390 9.2. Namespaces Lacking Documented Guidance 1392 For all existing RFCs that either explicitly or implicitly rely on 1393 IANA to make assignments without specifying a precise assignment 1394 policy, IANA (in consultation with the IESG) will continue to decide 1395 what policy is appropriate. Changes to existing policies can always 1396 be initiated through the normal IETF consensus process, or through 1397 the IESG when appropriate. 1399 All future RFCs that either explicitly or implicitly rely on IANA to 1400 register or otherwise administer namespace assignments MUST provide 1401 guidelines for administration of the namespace. 1403 9.3. After-the-Fact Registrations 1404 Occasionally, the IETF becomes aware that an unassigned value from a 1405 namespace is in use on the Internet or that an assigned value is 1406 being used for a different purpose than it was registered for. The 1407 IETF does not condone such misuse; procedures of the type described 1408 in this document MUST be applied to such cases. In the absence of 1409 specifications to the contrary, values may only be reassigned for a 1410 different purpose with the consent of the original assignee (when 1411 possible) and with due consideration of the impact of such a 1412 reassignment. In cases of likely controversy, consultation with the 1413 IESG is advised. 1415 9.4. Reclaiming Assigned Values 1417 Reclaiming previously assigned values for reuse is tricky, because 1418 doing so can lead to interoperability problems with deployed systems 1419 still using the assigned values. Moreover, it can be extremely 1420 difficult to determine the extent of deployment of systems making use 1421 of a particular value. However, in cases where the namespace is 1422 running out of unassigned values and additional ones are needed, it 1423 may be desirable to attempt to reclaim unused values. When 1424 reclaiming unused values, the following (at a minimum) should be 1425 considered: 1427 o Attempts should be made to contact the original party to which a 1428 value is assigned, to determine if the value was ever used, and if 1429 so, the extent of deployment. (In some cases, products were never 1430 shipped or have long ceased being used. In other cases, it may be 1431 known that a value was never actually used at all.) 1433 o Reassignments should not normally be made without the concurrence 1434 of the original requester. Reclamation under such conditions 1435 should only take place where there is strong evidence that a value 1436 is not widely used, and the need to reclaim the value outweighs 1437 the cost of a hostile reclamation. In any case, IESG Approval is 1438 needed in this case. 1440 o It may be appropriate to write up the proposed action and solicit 1441 comments from relevant user communities. In some cases, it may be 1442 appropriate to write an RFC that goes through a formal IETF 1443 process (including IETF Last Call) as was done when DHCP reclaimed 1444 some of its "Private Use" options [RFC3942]. 1446 9.5. Contact Person vs Assignee or Owner 1448 Many registries include designation of a technical or administrative 1449 contact associated with each entry. Often, this is recorded as 1450 contact information for an individual. It is unclear, though, what 1451 role the individual has with respect to the registration: is this 1452 item registered on behalf of the individual, the company the 1453 individual worked for, or perhaps another organization the individual 1454 was acting for? 1455 This matters because some time later, when the individual has changed 1456 jobs or roles, and perhaps can no longer be contacted, someone might 1457 want to update the registration. IANA has no way to know what 1458 company, organization, or individual should be allowed to take the 1459 registration over. For registrations rooted in RFCs, the stream 1460 owner (such as the IESG or the IAB) can make an overriding decision. 1461 But in other cases, there is no recourse. 1463 Registries can include, in addition to a "Contact" field, an 1464 "Assignee" or "Owner" field that can be used to address this 1465 situation, giving IANA clear guidance as to the actual owner of the 1466 registration. This is strongly advised especially for registries 1467 that do not require RFCs to manage their information (registries with 1468 policies such as First Come First Served Section 4.4, Expert Review 1469 Section 4.5, and Specification Required Section 4.6). Alternatively, 1470 organizations can put an organizational role into the "Contact" field 1471 in order to make their ownership clear. 1473 9.6. Closing or Obsoleting a Registry 1475 Sometimes there is a request to "close" a registry to further 1476 registrations. When a registry is closed, no further registrations 1477 will be accepted. The information in the registry will still be 1478 valid and registrations already in the registry can still be updated. 1480 A closed registry can also be marked as "obsolete", as an indication 1481 that the information in the registry is no longer in current use. 1483 Specific entries in a registry can be marked as "obsolete" (no longer 1484 in use) or "deprecated" (use is not recommended). 1486 Such changes to registries and registered values are subject to 1487 normal change controls (see Section 2.3.3). Any closure, 1488 obsolescence, or deprecation serves to annotate the registry 1489 involved; the information in the registry remains there for 1490 informational and historic purposes. 1492 10. Appeals 1494 Appeals of protocol parameter registration decisions can be made 1495 using the normal IETF appeals process as described in [RFC2026], 1496 Section 6.5. That is, an initial appeal should be directed to the 1497 IESG, followed (if necessary) by an appeal to the IAB. 1499 11. Mailing Lists 1501 All IETF mailing lists associated with evaluating or discussing 1502 assignment requests as described in this document are subject to 1503 whatever rules of conduct and methods of list management are 1504 currently defined by Best Current Practices or by IESG decision. 1506 12. Security Considerations 1507 Information that creates or updates a registration needs to be 1508 authenticated and authorized. IANA updates registries according to 1509 instructions in published RFCs and from the IESG. It also may accept 1510 clarifications from document authors, relevant working group chairs, 1511 Designated Experts, and mail list participants, too. 1513 Information concerning possible security vulnerabilities of a 1514 protocol may change over time. Likewise, security vulnerabilities 1515 related to how an assigned number is used may change as well. As new 1516 vulnerabilities are discovered, information about such 1517 vulnerabilities may need to be attached to existing registrations, so 1518 that users are not misled as to the true security issues surrounding 1519 the use of a registered number. 1521 An analysis of security issues is generally required for all 1522 protocols that make use of parameters (data types, operation codes, 1523 keywords, etc.) used in IETF protocols or registered by IANA. Such 1524 security considerations are usually included in the protocol document 1525 [RFC3552]. It is the responsibility of the IANA considerations 1526 associated with a particular registry to specify what (if any) 1527 security considerations must be provided when assigning new values, 1528 and the process for reviewing such claims. 1530 13. Changes Relative to Earlier Editions of BCP 26 1532 13.1. 2014: Changes in This Document Relative to RFC 5226 1534 Significant additions: 1536 o Added Section 1.1, Keep IANA Considerations for IANA 1538 o Added Section 1.2, For More Information 1540 o Added Section 2.1, Hierarchical Registry Structure 1542 o Added Section 2.3, Best Practice for Selecting an Appropriate 1543 Policy. 1545 o Added Section 2.3.2, Using Multiple Policies in Combination. 1547 o Added Section 2.3.3, Specifying Change Control for a Registry 1549 o Added Section 3.4, Early Allocations 1551 o Moved well-known policies into a separate section for each, 1552 subsections of Section 4. 1554 o Added Section 5.4, Expert Reviews and the Document Lifecycle 1556 o Added Section 7, Documentation References in IANA Registries 1558 o Added Section 8, What to Do in "bis" Documents 1559 o Added Section 9.5, Contact Person vs Assignee or Owner 1561 o Added Section 9.6, Closing or Obsoleting a Registry 1563 Clarifications and such: 1565 o Some reorganization -- moved text around for clarity and easier 1566 reading. 1568 o Made clarifications about identification of IANA registries and 1569 use of URLs for them. 1571 o Clarified the distinction between "Unassigned" and "Reserved". 1573 o Made some clarifications in "Expert Review" about instructions to 1574 the designated expert. 1576 o Made some clarifications in "Specification Required" about how to 1577 declare this policy. 1579 o Assorted minor clarifications and editorial changes throughout. 1581 13.2. 2008: Changes in RFC 5226 Relative to RFC 2434 1583 Changes include: 1585 o Major reordering of text to expand descriptions and to better 1586 group topics such as "updating registries" vs. "creating new 1587 registries", in order to make it easier for authors to find the 1588 text most applicable to their needs. 1590 o Numerous editorial changes to improve readability. 1592 o Changed the term "IETF Consensus" to "IETF Review" and added more 1593 clarifications. History has shown that people see the words "IETF 1594 Consensus" (without consulting the actual definition) and are 1595 quick to make incorrect assumptions about what the term means in 1596 the context of IANA Considerations. 1598 o Added "RFC Required" to list of defined policies. 1600 o Much more explicit directions and examples of "what to put in 1601 RFCs". 1603 o "Specification Required" now implies use of a Designated Expert to 1604 evaluate specs for sufficient clarity. 1606 o Significantly changed the wording in the Designated Experts 1607 section. Main purpose is to make clear that Expert Reviewers are 1608 accountable to the community, and to provide some guidance for 1609 review criteria in the default case. 1611 o Changed wording to remove any special appeals path. The normal 1612 RFC 2026 appeals path is used. 1614 o Added a section about reclaiming unused values. 1616 o Added a section on after-the-fact registrations. 1618 o Added a section indicating that mailing lists used to evaluate 1619 possible assignments (such as by a Designated Expert) are subject 1620 to normal IETF rules. 1622 14. Acknowledgments 1624 14.1. Acknowledgments for This Document (2014) 1626 Thomas Narten and Harald Tveit Alvestrand edited the two earlier 1627 editions of this document (RFCs 2434 and 5226), and Thomas continues 1628 his role in this third edition. Much of the text from RFC 5226 1629 remains in this edition. 1631 Thank you to Amanda Baber and Pearl Liang for their multiple reviews 1632 and suggestions for making this document as thorough as possible. 1634 This document has benefited from thorough review and comments by Tony 1635 Hansen, John Klensin, and Mark Nottingham. 1637 Special thanks to Mark Nottingham for reorganizing some of the text 1638 for better organization and readability, and to Tony Hansen for 1639 acting as document shepherd. 1641 14.2. Acknowledgments from the second edition (2008) 1643 The original acknowledgments section in RFC 5226 was: 1645 This document has benefited from specific feedback from Jari Arkko, 1646 Marcelo Bagnulo Braun, Brian Carpenter, Michelle Cotton, Spencer 1647 Dawkins, Barbara Denny, Miguel Garcia, Paul Hoffman, Russ Housley, 1648 John Klensin, Allison Mankin, Blake Ramsdell, Mark Townsley, Magnus 1649 Westerlund, and Bert Wijnen. 1651 14.3. Acknowledgments from the first edition (1998) 1653 The original acknowledgments section in RFC 2434 was: 1655 Jon Postel and Joyce Reynolds provided a detailed explanation on what 1656 IANA needs in order to manage assignments efficiently, and patiently 1657 provided comments on multiple versions of this document. Brian 1658 Carpenter provided helpful comments on earlier versions of the 1659 document. One paragraph in the Security Considerations section was 1660 borrowed from [RFC4288]. 1662 15. References 1663 15.1. Normative References 1665 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1666 3", BCP 9, RFC 2026, October 1996. 1668 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1669 Requirement Levels", BCP 14, RFC 2119, March 1997. 1671 15.2. Informative References 1673 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1674 1981. 1676 [RFC2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of 1677 Understanding Concerning the Technical Work of the 1678 Internet Assigned Numbers Authority", RFC 2860, June 2000. 1680 [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition 1681 of New DHCP Options and Message Types", BCP 43, RFC 2939, 1682 September 2000. 1684 [RFC3228] Fenner, B., "IANA Considerations for IPv4 Internet Group 1685 Management Protocol (IGMP)", BCP 57, RFC 3228, February 1686 2002. 1688 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1689 Text on Security Considerations", BCP 72, RFC 3552, July 1690 2003. 1692 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1693 Authentication Dial In User Service)", RFC 3575, July 1694 2003. 1696 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1697 Considered Useful", BCP 82, RFC 3692, January 2004. 1699 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 1700 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1701 3748, June 2004. 1703 [RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration 1704 Protocol version 4 (DHCPv4) Options", RFC 3942, November 1705 2004. 1707 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 1708 (IANA) Header Field Parameter Registry for the Session 1709 Initiation Protocol (SIP)", BCP 98, RFC 3968, December 1710 2004. 1712 [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 1713 Network Access Server Application", RFC 4005, August 2005. 1715 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 1716 Material in DNS", RFC 4025, March 2005. 1718 [RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, 1719 May 2005. 1721 [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of 1722 Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 1723 2005. 1725 [RFC4169] Torvinen, V., Arkko, J. and M. Naslund, "Hypertext 1726 Transfer Protocol (HTTP) Digest Authentication Using 1727 Authentication and Key Agreement (AKA) Version-2", RFC 1728 4169, November 2005. 1730 [RFC4271] Rekhter, Y., Li, T. and S. Hares, "A Border Gateway 1731 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1733 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H. and K. 1734 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 1735 (MIPv6)", RFC 4283, November 2005. 1737 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1738 Registration Procedures", BCP 13, RFC 4288, December 2005. 1740 [RFC4340] Kohler, E., Handley, M. and S. Floyd, "Datagram Congestion 1741 Control Protocol (DCCP)", RFC 4340, March 2006. 1743 [RFC4395] Hansen, T., Hardie, T. and L. Masinter, "Guidelines and 1744 Registration Procedures for New URI Schemes", BCP 35, RFC 1745 4395, February 2006. 1747 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1748 Security Layer (SASL)", RFC 4422, June 2006. 1750 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 1751 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 1753 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 1754 Considerations for the Lightweight Directory Access 1755 Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 1757 [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types 1758 Registry", RFC 4589, July 2006. 1760 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1761 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 1763 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1764 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1766 [RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide 1767 to the IETF Trust", BCP 78, RFC 5378, November 2008. 1769 [RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for 1770 Handling of Independent and IRTF Stream Submissions", BCP 1771 92, RFC 5742, December 2009. 1773 [RFC5771] Cotton, M., Vegoda, L. and D. Meyer, "IANA Guidelines for 1774 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 1775 March 2010. 1777 [RFC5795] Sandlund, K., Pelletier, G. and L-E. Jonsson, "The RObust 1778 Header Compression (ROHC) Framework", RFC 5795, March 1779 2010. 1781 [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA 1782 Considerations", BCP 42, RFC 6195, March 2011. 1784 [RFC6275] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support 1785 in IPv6", RFC 6275, July 2011. 1787 [RFC6709] Carpenter, B., Aboba, B. and S. Cheshire, "Design 1788 Considerations for Protocol Extensions", RFC 6709, 1789 September 2012. 1791 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 1792 Points", BCP 100, RFC 7120, January 2014. 1794 Authors' Addresses 1796 Michelle Cotton 1797 Internet Corporation for Assigned Names and Numbers 1798 12025 Waterfront Drive, Suite 300 1799 Los Angeles, CA 90094-2536 1800 US 1802 Phone: +1 310 823 9358 1803 Email: michelle.cotton@icann.org 1804 URI: http://www.icann.org/ 1806 Barry Leiba 1807 Huawei Technologies 1809 Phone: +1 646 827 0648 1810 Email: barryleiba@computer.org 1811 URI: http://internetmessagingtechnology.org/ 1812 Thomas Narten 1813 IBM Corporation 1814 3039 Cornwallis Ave., PO Box 12195 - BRQA/502 1815 Research Triangle Park, NC 27709-2195 1816 US 1818 Phone: +1 919 254 7798 1819 Email: narten@us.ibm.com