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