idnits 2.17.1 draft-leiba-cotton-iana-5226bis-17.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 is 1 instance 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 (July 27, 2016) is 2820 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 417, but not defined == Missing Reference: 'BCP26' is mentioned on line 1162, but not defined == Missing Reference: 'RFC4637' is mentioned on line 1494, but not defined -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) -- 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) -- Obsolete informational reference (is this intentional?): RFC 7564 (Obsoleted by RFC 8264) -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 8 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: January 26, 2017 IBM Corporation 8 July 27, 2016 10 Guidelines for Writing an IANA Considerations Section in RFCs 11 draft-leiba-cotton-iana-5226bis-17 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 record keeper. For IETF protocols, that role is filled by the 20 Internet Assigned Numbers Authority (IANA). 22 To make assignments in a given registry 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 of this document; it 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 January 26, 2017. 49 Copyright Notice 51 Copyright (c) 2016 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 Updated Information . . . . . . . . . . . . . . . . . 4 68 1.3. A Quick Checklist Up Front . . . . . . . . . . . . . . . . 4 69 2. Creating and Revising Registries . . . . . . . . . . . . . . . 6 70 2.1. Organization of Registries . . . . . . . . . . . . . . . . 7 71 2.2. Documentation Requirements for Registries . . . . . . . . 7 72 2.3. Specifying Change Control for a Registry . . . . . . . . . 9 73 2.4. Revising Existing Registries . . . . . . . . . . . . . . . 10 74 3. Registering New Values in an Existing Registry . . . . . . . . 10 75 3.1. Documentation Requirements for Registrations . . . . . . . 10 76 3.2. Updating Existing Registrations . . . . . . . . . . . . . 12 77 3.3. Overriding Registration Procedures . . . . . . . . . . . . 13 78 3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 13 79 4. Choosing a Registration Policy, and Well-Known Policies . . . 14 80 4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 16 81 4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . . 16 82 4.3. Hierarchical Allocation . . . . . . . . . . . . . . . . . 17 83 4.4. First Come First Served . . . . . . . . . . . . . . . . . 17 84 4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 18 85 4.6. Specification Required . . . . . . . . . . . . . . . . . . 19 86 4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . . 20 87 4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 20 88 4.9. Standards Action . . . . . . . . . . . . . . . . . . . . . 21 89 4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 21 90 4.11. Using the Well-Known Registration Policies . . . . . . . . 22 91 4.12. Using Multiple Policies in Combination . . . . . . . . . . 23 92 5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 24 93 5.1. The Motivation for Designated Experts . . . . . . . . . . 24 94 5.2. The Role of the Designated Expert . . . . . . . . . . . . 24 95 5.2.1. Managing Designated Experts in the IETF . . . . . . . 26 96 5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 26 97 5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 27 98 6. Well-Known Registration Status Terminology . . . . . . . . . . 28 99 7. Documentation References in IANA Registries . . . . . . . . . 29 100 8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 29 101 9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 31 102 9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 31 103 9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 31 104 9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 31 105 9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 32 106 9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 33 107 9.6. Closing or Obsoleting a Registry/Registrations . . . . . . 33 108 10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 109 11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 34 110 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 111 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 112 14. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 35 113 14.1. 2016: Changes in This Document Relative to RFC 5226 . . . 35 114 14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 36 115 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 116 15.1. Acknowledgments for This Document (2016) . . . . . . . . 36 117 15.2. Acknowledgments from the second edition (2008) . . . . . 37 118 15.3. Acknowledgments from the first edition (1998) . . . . . . 37 119 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 120 16.1. Normative References . . . . . . . . . . . . . . . . . . 37 121 16.2. Informative References . . . . . . . . . . . . . . . . . 37 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 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 record keeper. For IETF protocols, that role is filled by the 131 Internet Assigned Numbers Authority (IANA) [RFC2860]. 133 The Protocol field in the IP header [RFC0791] and MIME media types 134 [RFC6838] 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 An ideal IANA Considerations section clearly enumerates and specifies 166 each requested IANA action; includes all information IANA needs, such 167 as the full names of all applicable registries; and includes clear 168 references to elsewhere in the document for other information. 170 The IANA actions are normally phrased as requests for IANA (such as, 171 "IANA is asked to assign the value TBD1 from the Frobozz 172 Registry..."); the RFC Editor will change those sentences to reflect 173 the actions taken ("IANA has assigned the value 83 from the Frobozz 174 Registry..."). 176 1.2. For Updated Information 178 IANA maintains a web page that includes current important information 179 from IANA. Document authors should check that page for additional 180 information, beyond what is provided here: current clarifications, 181 minor updates, and summary guidance. Any significant updates to the 182 best current practice will have to feed into updates to BCP 26 (this 183 document), which is definitive. 185 . 187 [[(RFC Editor: Please remove this paragraph.) The initial version of 188 this should contain the bits that are salient to most document 189 authors -- perhaps a table of required elements to create a new 190 registry or update one, a bit about sub-registries, and the listing 191 of well-known registration policies. IANA has text for this, but 192 they need to work on their process to put the page up (transition 193 issues). We might host the first version on the IETF site, with the 194 URL above set to redirect to it. ]] 196 1.3. A Quick Checklist Up Front 198 It's useful to be familiar with this document as a whole. But when 199 you return for quick reference, here are checklists for the most 200 common things you'll need to do, and references to help with the less 201 common ones. 203 In general... 205 1. Put all the information that IANA will need to know into the 206 "IANA Considerations" section of your document (see Section 1.1). 208 2. Try to keep that section only for information to IANA and to 209 designated expert reviewers, and put significant technical 210 information in the appropriate technical sections of the document 211 (see Section 1.1). 213 3. Note that the IESG has the authority to resolve issues with IANA 214 registrations, and if you have any questions or problems you 215 should consult an Area Director (see Section 3.3). 217 If you are creating a new registry... 219 1. Give the registry a descriptive name, and provide a brief 220 description of its use (see Section 2.2). 222 2. Identify any registry grouping that it should be part of (see 223 Section 2.1). 225 3. Clearly specify what information is required in order to register 226 new items (see Section 2.2). Be sure to specify data types, 227 lengths, and valid ranges for fields. 229 4. Specify the initial set of items for the registry, if applicable 230 (see Section 2.2). 232 5. Make sure it's clear to IANA what the change control policy is 233 for the registry, in case changes to the format or policies need 234 to be made later (see Section 2.3 and Section 9.5). 236 6. Select a registration policy -- or a set of policies -- to use 237 for future registrations (see Section 4, and especially note 238 Section 4.11 and Section 4.12). 240 7. If you're using a policy that requires a Designated Expert 241 (Expert Review or Specification Required), understand Section 5 242 Section 5, and provide review guidance to the Designated Expert 243 (see Section 5.3). 245 8. If any items or ranges in your registry need to be reserved for 246 special use or are otherwise unavailable for assignment, see 247 Section 6. 249 If you are registering into an existing registry... 251 1. Clearly identify the registry by its exact name, and optionally 252 by its URL (see Section 3.1). 254 2. If the registry has multiple ranges from which assignments can be 255 made, make it clear which range is requested (see Section 3.1). 257 3. Avoid using specific values for numeric or bit assignments, and 258 let IANA pick a suitable value at registration time (see Section 259 3.1). This will avoid registration conflicts among multiple 260 documents. 262 4. For "reference" fields, use the document that provides the best, 263 most current documentation for the item being registered, and 264 include section numbers to make it easier for readers to locate 265 the relevant documentation (see Section 3.1 and Section 7). 267 5. Look up (in the registry's reference document) what information 268 is required for the registry and accurately provide all the 269 necessary information (see Section 3.1). 271 6. Look up (in the registry's reference document) any special rules 272 or processes there may be for the registry, such as posting to a 273 particular mailing list for comment, and be sure to follow the 274 process (see Section 3.1). 276 7. Make sure it's clear to IANA what the change control policy is 277 for the item, in case changes to the registration need to be made 278 later (see Section 9.5). 280 If you're writing a "bis" document or otherwise making older 281 documents obsolete, see Section 8. 283 If you need to make an early registration, such as for supporting 284 test implementations during document development, rather than waiting 285 for your document to be finished and approved, see [RFC7120]. 287 If you need to change the format/contents or policies for an existing 288 registry, see Section 2.4. 290 If you need to update an existing registration, see Section 3.2. 292 If you need to close down a registry because it is no longer needed, 293 see Section 9.6. 295 2. Creating and Revising Registries 297 Defining a registry involves describing the namespaces to be created, 298 listing an initial set of assignments (if applicable), and 299 documenting guidelines on how future assignments are to be made. 301 When defining a registry, consider structuring the namespace in such 302 a way that only top-level assignments need to be made with central 303 coordination, and those assignments can delegate lower-level 304 assignments so coordination for them can be distributed. This 305 lessens the burden on IANA for dealing with assignments, and is 306 particularly useful in situations where distributed coordinators have 307 better knowledge of their portion of the namespace and are better 308 suited to handling those assignments. 310 2.1. Organization of Registries 312 All registries are anchored from the IANA "Protocol Registries" page: 314 . 316 That page lists registries in protocol category groups, placing 317 related registries together and making it easier for users of the 318 registries to find the necessary information. Clicking on the title 319 of one of the registries on the IANA Protocol Registries page will 320 take the reader to the details page for that registry. 322 Unfortunately, we have been inconsistent in how we refer to these 323 entities. The group names, as they are referred to here, have been 324 variously called "protocol category groups", "groups", "top-level 325 registries", or just "registries". The registries under them have 326 been called "registries" or "sub-registries". 328 Regardless of the terminology used, document authors should pay 329 attention to the registry groupings, should request that related 330 registries be grouped together to make related registries easier to 331 find, and, when creating a new registry, should check whether that 332 registry might best be included in an existing group. That grouping 333 information should be clearly communicated to IANA in the registry 334 creation request. 336 2.2. Documentation Requirements for Registries 338 Documents that create a new namespace (or modify the definition of an 339 existing space) and that expect IANA to play a role in maintaining 340 that space (serving as a repository for registered values) must 341 provide clear instructions on details of the namespace, either in the 342 IANA Considerations section, or referenced from it. 344 In particular, such instructions must include: 346 The name of the registry 348 This name will appear on the IANA web page and will be referred to 349 in future documents that need to allocate a value from the new 350 space. The full name (and abbreviation, if appropriate) should be 351 provided. It is highly desirable that the chosen name not be 352 easily confused with the name of another registry. 354 When creating a registry, the group that it is a part of must be 355 identified using its full name, exactly as it appears in the IANA 356 registry list. 358 Providing a URL to precisely identify the registry helps IANA 359 understand the request. Such URLs can be removed from the RFC 360 prior to final publication, or left in the document for reference. 361 If you include IANA URLs, IANA will provide corrections, if 362 necessary, during their review. 364 Required information for registrations 366 This tells registrants what information they have to include in 367 their registration requests. Some registries require only the 368 requested value and a reference to a document where use of the 369 value is defined. Other registries require a more detailed 370 registration template that describes relevant security 371 considerations, internationalization considerations, and other 372 such information. 374 Applicable registration policy 376 The policy that will apply to all future requests for 377 registration. See Section 4. 379 Size, format and syntax of registry entries 381 What fields to record in the registry, any technical requirements 382 on registry entries (valid ranges for integers, length limitations 383 on strings, and such), and the exact format in which registry 384 values should be displayed. For numeric assignments, one should 385 specify whether values are to be recorded in decimal, in 386 hexadecimal, or in some other format. 388 Strings are expected to be ASCII, and it should be clearly 389 specified whether case matters, and whether, for example, strings 390 should be shown in the registry in upper case or lower case. 392 Strings that represent protocol parameters will rarely, if ever, 393 need to contain non-ASCII characters. If non-ASCII characters are 394 really necessary, instructions should make it very clear that they 395 are allowed and that the non-ASCII characters should be 396 represented as Unicode characters using the "(U+XXXX)" convention. 397 Anyone creating such a registry should think carefully about this 398 and consider internationalization advice such as that in [RFC7564] 399 Section 10. 401 Initial assignments and reservations 403 Any initial assignments or registrations to be included. In 404 addition, any ranges that are to be reserved for "Private Use", 405 "Reserved", "Unassigned", etc. (see Section 6) should be 406 indicated. 408 For example, a document might specify a new registry by including: 410 --------------------------------------------------------------- 412 X. IANA Considerations 414 This document defines a new DHCP option, entitled "FooBar" (see 415 Section y), assigned a value of TBD1 from the DHCP Option space 416 417 [RFC2132] [RFC2939]: 418 Data 419 Tag Name Length Meaning 420 ---- ---- ------ ------- 421 TBD1 FooBar N FooBar server 423 The FooBar option also defines an 8-bit FooType field, for which 424 IANA is to create and maintain a new registry entitled 425 "FooType values" used by the FooBar option. Initial values for the 426 DHCP FooBar FooType registry are given below; future assignments 427 are to be made through Expert Review [BCP26]. 428 Assignments consist of a DHCP FooBar FooType name and its 429 associated value. 431 Value DHCP FooBar FooType Name Definition 432 ---- ------------------------ ---------- 433 0 Reserved 434 1 Frobnitz RFCXXXX, Section y.1 435 2 NitzFrob RFCXXXX, Section y.2 436 3-254 Unassigned 437 255 Reserved 438 --------------------------------------------------------------- 440 For examples of documents that establish registries, consult 441 [RFC3575], [RFC3968], and [RFC4520]. 443 Any time IANA includes names and contact information in the public 444 registry, some individuals might prefer that their contact 445 information not be made public. In such cases, arrangements can be 446 made with IANA to keep the contact information private. 448 2.3. Specifying Change Control for a Registry 450 Registry definitions and registrations within registries often need 451 to be changed after they are created. The process of making such 452 changes is complicated when it is unclear who is authorized to make 453 the changes. For registries created by RFCs in the IETF stream, 454 change control for the registry lies by default with the IETF, via 455 the IESG. The same is true for value registrations made in IETF- 456 stream RFCs. 458 Because registries can be created and registrations can be made 459 outside the IETF stream, it can sometimes be desirable to have change 460 control outside the IETF and IESG, and clear specification of change 461 control policies is always helpful. 463 It is advised, therefore, that all registries that are created 464 clearly specify a change control policy and a change controller. It 465 is also advised that registries that allow registrations from outside 466 the IETF stream include, for each value, the designation of a change 467 controller for that value. If the definition or reference for a 468 registered value ever needs to change, or if a registered value needs 469 to be deprecated, it is critical that IANA know who is authorized to 470 make the change. Example: the Media Types registry [RFC6838] 471 includes a "Change Controller" in its registration template. See 472 also Section 9.5. 474 2.4. Revising Existing Registries 476 Updating the registration process or making changes to the format of 477 an already existing (previously created) registry (whether created 478 explicitly or implicitly) follows a process similar to that used when 479 creating a new registry. That is, a document is produced that makes 480 reference to the existing namespace and then provides detailed 481 guidance for handling assignments in the registry, or detailed 482 instructions about the changes required. 484 If a change requires a new column in the registry, the instructions 485 need to be clear about how to populate that column for the existing 486 entries. Other changes may require similar clarity. 488 Such documents are normally processed with the same document status 489 as the document that created the registry. Under some circumstances, 490 such as with a straightforward change that is clearly needed (such as 491 adding a "status" column), or when an earlier error needs to be 492 corrected, the IESG may approve an update to a registry without 493 requiring a new document. 495 Example documents that updated the guidelines for assignments in pre- 496 existing registries include: [RFC6195], [RFC3228], and [RFC3575]. 498 3. Registering New Values in an Existing Registry 500 3.1. Documentation Requirements for Registrations 502 Often, documents request an assignment in an existing registry (one 503 created by a previously published document). 505 Such documents should clearly identify the registry into which each 506 value is to be registered. Use the exact registry name as listed on 507 the IANA web page, and cite the RFC where the registry is defined. 508 When referring to an existing registry, providing a URL to precisely 509 identify the registry is helpful (see Section 2.2). 511 There is no need to mention what the assignment policy is when making 512 new assignments in existing registries, as that should be clear from 513 the references. However, if multiple assignment policies might 514 apply, as in registries with different ranges that have different 515 policies, it is important to make it clear which range is being 516 requested, so that IANA will know which policy applies and can assign 517 a value in the correct range. 519 Be sure to provide all the information required for a registration, 520 and follow any special processes that are set out for the registry. 521 Registries sometimes require the completion of a registration 522 template for registration, or ask registrants to post their request 523 to a particular mailing list for discussion prior to registration. 524 Look up the registry's reference document: the required information 525 and special processes should be documented there. 527 Normally, numeric values to be used are chosen by IANA when the 528 document is approved, and drafts should not specify final values. 529 Instead, placeholders such as "TBD1" and "TBD2" should be used 530 consistently throughout the document, giving each item to be 531 registered a different placeholder. The IANA Considerations should 532 ask the RFC Editor to replace the placeholder names with the IANA- 533 assigned values. When drafts need to specify numeric values for 534 testing or early implementations, they will either request early 535 allocation (see Section 3.4) or use values that have already been set 536 aside for testing or experimentation (if the registry in question 537 allows that without explicit assignment). It is important that 538 drafts not choose their own values, lest IANA assign one of those 539 values to another document in the meantime. A draft can request a 540 specific value in the IANA Considerations section, and IANA will 541 accommodate such requests when that's possible, but the proposed 542 number might have been assigned to some other use by the time the 543 draft is approved. 545 Normally, text-string values to be used are specified in the 546 document, as collisions are less likely with text strings. IANA will 547 consult with the authors if there is, in fact, a collision, and a 548 different value has to be used. When drafts need to specify string 549 values for testing or early implementations, they sometimes use the 550 expected final value. But it is often useful to use a draft value 551 instead, possibly including the draft version number. This allows 552 the early implementations to be distinguished from those implementing 553 the final version. A document that intends to use "foobar" in the 554 final version might use "foobar-testing-draft-05" for the -05 version 555 of the draft, for example. 557 For some registries, there is a long-standing policy prohibiting 558 assignment of names or codes on a vanity or organization-name basis. 559 For example, codes might always be assigned sequentially unless there 560 is a strong reason for making an exception. Nothing in this document 561 is intended to change those policies or prevent their future 562 application. 564 As an example, the following text could be used to request assignment 565 of a DHCPv6 option number: 567 IANA is asked to assign an option code value of TBD1 to the DNS 568 Recursive Name Server option and an option code value of TBD2 to 569 the Domain Search List option from the DHCP option code space 570 defined in Section 24.3 of RFC 3315. 572 The IANA Considerations section should summarize all of the IANA 573 actions, with pointers to the relevant sections elsewhere in the 574 document as appropriate. Including section numbers is especially 575 useful when the reference document is large; the section numbers will 576 make it easier for those searching the reference document to find the 577 relevant information. 579 When multiple values are requested, it is generally helpful to 580 include a summary table of the additions/changes. It is also helpful 581 for this table to be in the same format as it appears or will appear 582 on the IANA web site. For example: 584 Value Description Reference 585 -------- ------------------- --------- 586 TBD1 Foobar this RFC, Section 3.2 587 TBD2 Gumbo this RFC, Section 3.3 588 TBD3 Banana this RFC, Section 3.4 590 Note: In cases where authors feel that including the full table of 591 changes is too verbose or repetitive, authors should still include 592 the table in the draft, but may include a note asking that the table 593 be removed prior to publication of the final RFC. 595 3.2. Updating Existing Registrations 597 Even after a number has been assigned, some types of registrations 598 contain additional information that may need to be updated over time. 600 For example, MIME media types, character sets, and language tags 601 typically include more information than just the registered value 602 itself, and may need updates to items such as point-of-contact 603 information, security issues, pointers to updates, and literature 604 references. 606 In such cases, the document defining the namespace must clearly state 607 who is responsible for maintaining and updating a registration. 608 Depending on the registry, it may be appropriate to specify one or 609 more of: 611 o Letting registrants and/or nominated change controllers update 612 their own registrations, subject to the same constraints and 613 review as with new registrations. 615 o Allowing attachment of comments to the registration. This can be 616 useful in cases where others have significant objections to a 617 registration, but the author does not agree to change the 618 registration. 620 o Designating the IESG, a designated expert, or another entity as 621 having the right to change the registrant associated with a 622 registration and any requirements or conditions on doing so. This 623 is mainly to get around the problem when a registrant cannot be 624 reached in order to make necessary updates. 626 3.3. Overriding Registration Procedures 628 Experience has shown that the documented IANA considerations for 629 individual protocols do not always adequately cover the reality of 630 registry operation, or are not sufficiently clear. In addition, 631 documented IANA considerations are sometimes found to be too 632 stringent to allow even working group documents (for which there is 633 strong consensus) to perform a registration in advance of actual RFC 634 publication. 636 In order to allow assignments in such cases, the IESG is granted 637 authority to override registration procedures and approve assignments 638 on a case-by-case basis. 640 The intention here is not to overrule properly documented procedures, 641 or to obviate the need for protocols to properly document their IANA 642 considerations. Rather, it is to permit assignments in specific 643 cases where it is obvious that the assignment should just be made, 644 but updating the IANA process beforehand is too onerous. 646 When the IESG is required to take action as described above, it is a 647 strong indicator that the applicable registration procedures should 648 be updated, possibly in parallel with the work that instigated it. 650 IANA always has the discretion to ask the IESG for advice or 651 intervention when they feel it is needed, such as in cases where 652 policies or procedures are unclear to them, where they encounter 653 issues or questions they are unable to resolve, or where registration 654 requests or patterns of requests appear to be unusual or abusive. 656 3.4. Early Allocations 658 IANA normally takes its actions when a document is approved for 659 publication. There are times, though, when early allocation of a 660 value is important for the development of a technology: for example, 661 when early implementations are created while the document is still 662 under development. 664 IANA has a mechanism for handling such early allocations in some 665 cases. See [RFC7120] for details. It is usually not necessary to 666 explicitly mark a registry as allowing early allocation, because the 667 general rules will apply. 669 4. Choosing a Registration Policy, and Well-Known Policies 671 A registration policy is the policy that controls how new assignments 672 in a registry are accepted. There are several issues to consider 673 when defining the registration policy. 675 If the registry's namespace is limited, assignments will need to be 676 made carefully to prevent exhaustion. 678 Even when the space is essentially unlimited, it is still often 679 desirable to have at least a minimal review prior to assignment in 680 order to: 682 o prevent the hoarding of or unnecessary wasting of values. For 683 example, if the space consists of text strings, it may be 684 desirable to prevent entities from obtaining large sets of strings 685 that correspond to desirable names (existing company names, for 686 example). 688 o provide a sanity check that the request actually makes sense and 689 is necessary. Experience has shown that some level of minimal 690 review from a subject matter expert is useful to prevent 691 assignments in cases where the request is malformed or not 692 actually needed (for example, an existing assignment for an 693 essentially equivalent service already exists). 695 Perhaps most importantly, unreviewed extensions can impact 696 interoperability and security. See [RFC6709]. 698 When the namespace is essentially unlimited and there are no 699 potential interoperability or security issues, assigned numbers can 700 usually be given out to anyone without any subjective review. In 701 such cases, IANA can make assignments directly, provided that IANA is 702 given detailed instructions on what types of requests it should 703 grant, and it is able to do so without exercising subjective 704 judgement. 706 When this is not the case, some level of review is required. 707 However, it's important to balance adequate review and ease of 708 registration. In many cases, those making registrations will not be 709 IETF participants; requests often come from other standards 710 organizations, from organizations not directly involved in standards, 711 from ad-hoc community work (from an open-source project, for 712 example), and so on. Registration must not be unnecessarily 713 difficult, unnecessarily costly (in terms of time and other 714 resources), nor unnecessarily subject to denial. 716 While it is sometimes necessary to restrict what gets registered 717 (e.g., for limited resources such as bits in a byte, or for items for 718 which unsupported values can be damaging to protocol operation), in 719 many cases having what's in use represented in the registry is more 720 important. Overly strict review criteria and excessive cost (in time 721 and effort) discourage people from even attempting to make a 722 registration. If a registry fails to reflect the protocol elements 723 actually in use, it can adversely affect deployment of protocols on 724 the Internet, and the registry itself is devalued. 726 Therefore, it is important to think specifically about the 727 registration policy, and not just pick one arbitrarily nor copy text 728 from another document. Working groups and other document developers 729 should use care in selecting appropriate registration policies when 730 their documents create registries. They should select the least 731 strict policy that suits a registry's needs, and look for specific 732 justification for policies that require significant community 733 involvement (those stricter than Expert Review or Specification 734 Required, in terms of the well-known policies). The needs here will 735 vary from registry to registry, and, indeed, over time, and this BCP 736 will not be the last word on the subject. 738 The following policies are defined for common usage. These cover a 739 range of typical policies that have been used to describe the 740 procedures for assigning new values in a namespace. It is not 741 strictly required that documents use these terms; the actual 742 requirement is that the instructions to IANA be clear and 743 unambiguous. However, use of these terms is strongly recommended 744 because their meanings are widely understood. Newly minted policies, 745 including ones that combine the elements of procedures associated 746 with these terms in novel ways, may be used if none of these policies 747 are suitable; it will help the review process if an explanation is 748 included as to why that is the case. The terms are fully explained 749 in the following subsections. 751 1. Private Use 752 2. Experimental Use 753 3. Hierarchical Allocation 754 4. First Come First Served 755 5. Expert Review 756 6. Specification Required 757 7. RFC Required 758 8. IETF Review 759 9. Standards Action 760 10. IESG Approval 762 It should be noted that it often makes sense to partition a namespace 763 into multiple categories, with assignments within each category 764 handled differently. Many protocols now partition namespaces into 765 two or more parts, with one range reserved for Private or 766 Experimental Use while other ranges are reserved for globally unique 767 assignments assigned following some review process. Dividing a 768 namespace into ranges makes it possible to have different policies in 769 place for different ranges and different use cases. 771 Similarly, it will often be useful to specify multiple policies in 772 parallel, with each policy being used under different circumstances. 773 For more discussion of that topic, see Section 4.12. 775 Examples of RFCs that specify multiple policies in parallel: 777 LDAP [RFC4520] 778 TLS ClientCertificateType Identifiers [RFC5246] (as detailed in 779 the subsections below) 780 MPLS Pseudowire Types Registry [RFC4446] 782 4.1. Private Use 784 For private or local use only, with the type and purpose defined by 785 the local site. No attempt is made to prevent multiple sites from 786 using the same value in different (and incompatible) ways. IANA does 787 not record assignments from registries or ranges with this policy 788 (and therefore there is no need for IANA to review them) and 789 assignments are not generally useful for broad interoperability. It 790 is the responsibility of the sites making use of the Private Use 791 range to ensure that no conflicts occur (within the intended scope of 792 use). 794 Examples: 796 Site-specific options in DHCP [RFC2939] 797 Fibre Channel Port Type Registry [RFC4044] 798 TLS ClientCertificateType Identifiers 224-255 [RFC5246] 800 4.2. Experimental Use 802 Experimental Use is similar to Private Use, but with the purpose 803 being to facilitate experimentation. See [RFC3692] for details. 804 IANA does not record assignments from registries or ranges with this 805 policy (and therefore there is no need for IANA to review them) and 806 assignments are not generally useful for broad interoperability. 807 Unless the registry explicitly allows it, it is not appropriate for 808 documents to select explicit values from registries or ranges with 809 this policy. Specific experiments will select a value to use during 810 the experiment. 812 When code points are set aside for experimental use, it's important 813 to make clear any expected restrictions on experimental scope. For 814 example, say whether it's acceptable to run experiments using those 815 code points over the open Internet, or whether such experiments 816 should be confined to more closed environments. See [RFC6994] for an 817 example of such considerations. 819 Example: 821 Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP 822 Headers [RFC4727] 824 4.3. Hierarchical Allocation 826 With Hierarchical Allocation, delegated administrators are given 827 control over part of the namespace, and can assign values in that 828 part of the namespace. IANA makes allocations in the higher levels 829 of the namespace according to one of the other policies. 831 Examples: 833 - DNS names. IANA manages the top-level domains (TLDs), and, as 834 [RFC1591] says: 836 Under each TLD may be created a hierarchy of names. Generally, 837 under the generic TLDs the structure is very flat. That is, 838 many organizations are registered directly under the TLD, and 839 any further structure is up to the individual organizations. 841 - Object Identifiers, defined by ITU-T recommendation X.208. 842 According to , some registries 843 include 845 * IANA, which hands out OIDs the "Private Enterprises" branch, 846 * ANSI, which hands out OIDs under the "US Organizations" branch, 847 and 848 * BSI, which hands out OIDs under the "UK Organizations" branch. 850 - URN namespaces. IANA registers URN Namespace IDs (NIDs [RFC3406]), 851 and the organization registering an NID is responsible for 852 allocations of URNs within that namespace. 854 4.4. First Come First Served 855 For the First Come First Served policy, assignments are made to 856 anyone on a first come, first served basis. There is no substantive 857 review of the request, other than to ensure that it is well-formed 858 and doesn't duplicate an existing assignment. However, requests must 859 include a minimal amount of clerical information, such as a point of 860 contact (including an email address, and sometimes a postal address) 861 and a brief description of how the value will be used. Additional 862 information specific to the type of value requested may also need to 863 be provided, as defined by the namespace. For numbers, IANA 864 generally assigns the next in-sequence unallocated value, but other 865 values may be requested and assigned if an extenuating circumstance 866 exists. With names, specific text strings can usually be requested. 868 When creating a new registry with First Come First Served as the 869 registration policy, in addition to the contact person field or 870 reference, the registry should contain a field for change controller. 871 Having a change controller for each entry for these types of 872 registrations makes authorization of future modifications more clear. 873 See Section 2.3. 875 It is important that changes to the registration of a First Come 876 First Served code point retain compatibility with the current usage 877 of that code point, and so changes need to be made with care. The 878 change controller should not, in most cases, be requesting 879 incompatible changes nor repurposing a registered code point. See 880 also Section 9.4 and Section 9.5. 882 A working group or any other entity that is developing a protocol 883 based on a First Come First Served code point has to be extremely 884 careful that the protocol retains wire compatibility with current use 885 of the code point. Once that is no longer true, the new work needs 886 to change to a different code point (and register that use at the 887 appropriate time). 889 It is also important to understand that First Come First Served 890 really has no filtering. Essentially, any well formed request is 891 accepted. 893 Examples: 895 SASL mechanism names [RFC4422] 896 LDAP Protocol Mechanisms and LDAP Syntax [RFC4520] 898 4.5. Expert Review 900 (Also called "Designated Expert" in earlier editions of this 901 document.) For the Expert Review policy, review and approval by a 902 designated expert (see Section 5) is required. 904 The required documentation and review criteria, giving clear guidance 905 to the designated expert, should be provided when defining the 906 registry. It is particularly important to lay out what should be 907 considered when performing an evaluation and reasons for rejecting a 908 request. It is also a good idea to include, when possible, a sense 909 of whether many registrations are expected over time, or if the 910 registry is expected to be updated infrequently or in exceptional 911 circumstances only. 913 Thorough understanding of Section 5 is important when deciding on an 914 Expert Review policy and designing the guidance to the designated 915 expert. 917 Good examples of guidance to designated experts: 919 Extensible Authentication Protocol (EAP) [RFC3748], Sections 6 and 920 7.2 921 North-Bound Distribution of Link-State and TE Information using 922 BGP [RFC7752], Section 5.1 924 When creating a new registry with Expert Review as the registration 925 policy, in addition to the contact person field or reference, the 926 registry should contain a field for change controller. Having a 927 change controller for each entry for these types of registrations 928 makes authorization of future modifications more clear. See Section 929 2.3 931 Examples: 933 EAP Method Types [RFC3748] 934 HTTP Digest AKA algorithm versions [RFC4169] 935 URI schemes [RFC4395] 936 GEOPRIV Location Types [RFC4589] 938 4.6. Specification Required 940 For the Specification Required policy, review and approval by a 941 designated expert (see Section 5) is required, and the values and 942 their meanings must be documented in a permanent and readily 943 available public specification, in sufficient detail so that 944 interoperability between independent implementations is possible. 945 The designated expert will review the public specification and 946 evaluate whether it is sufficiently stable and permanent, and 947 sufficiently clear to allow interoperable implementations. 949 The intention behind "permanent and readily available" is that a 950 document can reasonably be expected to be findable and retrievable 951 long after IANA assignment of the requested value. Publication of an 952 RFC is an ideal means of achieving this requirement, but 953 Specification Required is intended to also cover the case of a 954 document published outside of the RFC path, including informal 955 documentation. 957 For RFC publication, formal review by the designated expert is still 958 requested, but the normal RFC review process is expected to provide 959 the necessary review for interoperability. The designated expert's 960 review is still important, but it's equally important to note that 961 when there is IETF consensus, the expert can sometimes be "in the 962 rough" (see also the last paragraph of Section 5.4). 964 As with Expert Review (Section 4.5), clear guidance to the designated 965 expert, should be provided when defining the registry, and thorough 966 understanding of Section 5 is important. 968 When specifying this policy, just use the term "Specification 969 Required". Some specifications have chosen to refer to it as "Expert 970 Review with Specification Required", and that only causes confusion. 972 Examples: 974 Diffserv-aware TE Bandwidth Constraints Model Identifiers 975 [RFC4124] 976 TLS ClientCertificateType Identifiers 64-223 [RFC5246] 977 ROHC Profile Identifiers [RFC5795] 979 4.7. RFC Required 981 With the RFC Required policy, the registration request, along with 982 associated documentation, must be published in an RFC. The RFC need 983 not be in the IETF stream, but may be in any RFC stream (currently an 984 RFC may be in the IETF, IRTF, or IAB stream, or an RFC Editor 985 Independent Submission [RFC5742]). 987 Unless otherwise specified, any type of RFC is sufficient (currently 988 Standards Track, BCP, Informational, Experimental, or Historic). 990 Examples: 992 DNSSEC DNS Security Algorithm Numbers [RFC6014] 993 Media Control Channel Framework registries [RFC6230] 994 DANE TLSA Certificate Usages [RFC6698] 996 4.8. IETF Review 998 (Formerly called "IETF Consensus" in the first edition of this 999 document.) With the IETF Review policy, new values are assigned only 1000 through RFCs in the IETF Stream -- those that have been shepherded 1001 through the IESG as AD-Sponsored or IETF working group Documents 1002 [RFC2026] [RFC5378], have gone through IETF last call, and that the 1003 IESG has approved as having IETF consensus. 1005 The intent is that the document and proposed assignment will be 1006 reviewed by the IETF community (including appropriate IETF working 1007 groups, directorates, and other experts) and by the IESG, to ensure 1008 that the proposed assignment will not negatively affect 1009 interoperability or otherwise extend IETF protocols in an 1010 inappropriate or damaging manner. 1012 Unless otherwise specified, any type of RFC is sufficient (currently 1013 Standards Track, BCP, Informational, Experimental, or Historic). 1015 Examples: 1017 IPSECKEY Algorithm Types [RFC4025] 1018 Accounting-Auth-Method AVP values in DIAMETER [RFC4005] 1019 TLS Extension Types [RFC5246] 1021 4.9. Standards Action 1023 For the Standards Action policy, values are assigned only through 1024 Standards Track or Best Current Practice RFCs in the IETF Stream. 1026 Examples: 1028 BGP message types [RFC4271] 1029 Mobile Node Identifier option types [RFC4283] 1030 TLS ClientCertificateType Identifiers 0-63 [RFC5246] 1031 DCCP Packet Types [RFC4340] 1033 4.10. IESG Approval 1035 New assignments may be approved by the IESG. Although there is no 1036 requirement that the request be documented in an RFC, the IESG has 1037 discretion to request documents or other supporting materials on a 1038 case-by-case basis. 1040 IESG Approval is not intended to be used often or as a "common case"; 1041 indeed, it has seldom been used in practice. Rather, it is intended 1042 to be available in conjunction with other policies as a fall-back 1043 mechanism in the case where one of the other allowable approval 1044 mechanisms cannot be employed in a timely fashion or for some other 1045 compelling reason. IESG Approval is not intended to circumvent the 1046 public review processes implied by other policies that could have 1047 been employed for a particular assignment. IESG Approval would be 1048 appropriate, however, in cases where expediency is desired and there 1049 is strong consensus (such as from a working group) for making the 1050 assignment. 1052 Before approving a request, the IESG might consider consulting the 1053 community, via a "call for comments" that provides as much 1054 information as is reasonably possible about the request. 1056 Examples: 1058 IPv4 Multicast address assignments [RFC5771] 1059 IPv4 IGMP Type and Code values [RFC3228] 1060 Mobile IPv6 Mobility Header Type and Option values [RFC6275] 1062 4.11. Using the Well-Known Registration Policies 1064 Because the well-known policies benefit from both community 1065 experience and wide understanding, their use is encouraged, and the 1066 making up of new policies needs to be accompanied by reasonable 1067 justification. 1069 It is also acceptable to cite one or more well-known policies and 1070 include additional guidelines for what kind of considerations should 1071 be taken into account by the review process. 1073 For example, for media-type registrations [RFC6838], a number of 1074 different situations are covered that involve the use of IETF Review 1075 and Specification Required, while also including specific additional 1076 criteria the Designated Expert should follow. This is not meant to 1077 represent a registration procedures, but shows an example of what can 1078 be done when special circumstances need to be covered. 1080 The well-known policies from "First Come First Served" to "Standards 1081 Action" specify a range of policies in increasing order of strictness 1082 (using the numbering from the full list in Section 4): 1084 4. First Come First Served 1085 No review, minimal documentation. 1087 5/6. Expert Review / Specification Required 1088 Expert review with sufficient documentation for review. / 1089 Significant stable public documentation sufficient for 1090 interoperability. 1092 7. RFC Required 1093 Any RFC publication, IETF or a non-IETF Stream. 1095 8. IETF Review 1096 RFC publication, IETF Stream only, but need not be Standards 1097 Track. 1099 9. Standards Action 1100 RFC publication, IETF Stream, Standards Track or BCP only. 1102 Examples of situations that might merit IETF Review or Standards 1103 Action include the following: 1105 o When a resource is limited, such as bits in a byte (or in two 1106 bytes, or four), or numbers in a limited range. In these cases, 1107 allowing registrations that haven't been carefully reviewed and 1108 agreed by community consensus could too quickly deplete the 1109 allowable values. 1111 o When thorough community review is necessary to avoid extending or 1112 modifying the protocol in ways that could be damaging. One 1113 example is in defining new command codes, as opposed to options 1114 that use existing command codes: the former might require a strict 1115 policy, where a more relaxed policy could be adequate for the 1116 latter. Another example is in defining protocol elements that 1117 change the semantics of existing operations. 1119 o When there are security implications with respect to the resource, 1120 and thorough review is needed to ensure that the new usage is 1121 sound. Examples of this include lists of acceptable hashing and 1122 cryptographic algorithms, and assignment of transport ports in the 1123 system range. 1125 When reviewing a document that asks IANA to create a new registry or 1126 change a registration policy to any policy more stringent than Expert 1127 Review or Specification Required, the IESG should ask for 1128 justification to ensure that more relaxed policies have been 1129 considered and that the strict policy is the right one. 1131 Accordingly, document developers need to anticipate this and document 1132 their considerations for selecting the specified policy (ideally, in 1133 the document itself; failing that, in the shepherd writeup). 1134 Likewise, the document shepherd should ensure that the selected 1135 policies have been justified before sending the document to the IESG. 1137 When specifications are revised, registration policies should be 1138 reviewed in light of experience since the policies were set. 1140 4.12. Using Multiple Policies in Combination 1142 In some situations, it is necessary to define multiple registration 1143 policies. For example, registrations through the normal IETF process 1144 might use one policy, while registrations from outside the process 1145 would have a different policy applied. 1147 Thus, a particular registry might want to use a policy such as "RFC 1148 Required" or "IETF Review" sometimes, with a designated expert 1149 checking a "Specification Required" policy at other times. 1151 The alternative to using a combination requires either that all 1152 requests come through RFCs or that requests in RFCs go through review 1153 by the designated expert, even though they already have IETF review 1154 and consensus. 1156 This can be documented in the IANA Considerations section when the 1157 registry is created: 1159 IANA is asked to create the registry "Fruit Access Flags" under 1160 the "Fruit Parameters" group. New registrations will be permitted 1161 through either the IETF Review policy or the Specification 1162 Required policy [BCP26]. The latter should be used only for 1163 registrations requested by SDOs outside the IETF. Registrations 1164 requested in IETF documents will be subject to IETF review. 1166 Such combinations will commonly use one of {Standards Action, IETF 1167 Review, RFC Required} in combination with one of {Specification 1168 Required, Expert Review}. Guidance should be provided about when 1169 each policy is appropriate, as in the example above. 1171 5. Designated Experts 1173 5.1. The Motivation for Designated Experts 1175 Discussion on a mailing list can provide valuable technical feedback, 1176 but opinions often vary and discussions may continue for some time 1177 without clear resolution. In addition, IANA cannot participate in 1178 all of these mailing lists and cannot determine if or when such 1179 discussions reach consensus. Therefore, IANA relies on a "designated 1180 expert" for advice regarding the specific question of whether an 1181 assignment should be made. The designated expert is an individual 1182 who is responsible for carrying out an appropriate evaluation and 1183 returning a recommendation to IANA. 1185 It should be noted that a key motivation for having designated 1186 experts is for the IETF to provide IANA with a subject matter expert 1187 to whom the evaluation process can be delegated. IANA forwards 1188 requests for an assignment to the expert for evaluation, and the 1189 expert (after performing the evaluation) informs IANA as to whether 1190 or not to make the assignment or registration. In most cases, the 1191 registrants do not work directly with the designated experts. The 1192 list of designated experts for a registry is listed in the registry. 1194 It will often be useful to use a designated expert only some of the 1195 time, as a supplement to other processes. For more discussion of 1196 that topic, see Section 4.12. 1198 5.2. The Role of the Designated Expert 1199 The designated expert is responsible for coordinating the appropriate 1200 review of an assignment request. The review may be wide or narrow, 1201 depending on the situation and the judgment of the designated expert. 1202 This may involve consultation with a set of technology experts, 1203 discussion on a public mailing list, consultation with a working 1204 group (or its mailing list if the working group has disbanded), etc. 1205 Ideally, the designated expert follows specific review criteria as 1206 documented with the protocol that creates or uses the namespace. See 1207 the IANA Considerations sections of [RFC3748] and [RFC3575] for 1208 specific examples. 1210 Designated experts are expected to be able to defend their decisions 1211 to the IETF community, and the evaluation process is not intended to 1212 be secretive or bestow unquestioned power on the expert. Experts are 1213 expected to apply applicable documented review or vetting procedures, 1214 or in the absence of documented criteria, follow generally accepted 1215 norms such as those in Section 5.3. Designated experts are generally 1216 not expected to be "gatekeepers", setting out to make registrations 1217 difficult to obtain, unless the guidance in the defining document 1218 specifies that they should act as such. Absent stronger guidance, 1219 the experts should be evaluating registration requests for 1220 completeness, interoperability, and conflicts with existing protocols 1221 and options. 1223 It has proven useful to have multiple designated experts for some 1224 registries. Sometimes those experts work together in evaluating a 1225 request, while in other cases additional experts serve as backups, 1226 acting only when the primary expert is unavailable. In registries 1227 with a pool of experts, the pool often has a single chair responsible 1228 for defining how requests are to be assigned to and reviewed by 1229 experts. In other cases, IANA might assign requests to individual 1230 members in sequential or approximate random order. The document 1231 defining the registry can, if it's appropriate for the situation, 1232 specify how the group should work -- for example, it might be 1233 appropriate to specify rough consensus on a mailing list, within a 1234 related working group, or among a pool of designated experts. 1236 In cases of disagreement among multiple experts, it is the 1237 responsibility of those experts to make a single clear recommendation 1238 to IANA. It is not appropriate for IANA to resolve disputes among 1239 experts. In extreme situations, such as deadlock, the designating 1240 body may need to step in to resolve the problem. 1242 If a designated expert has a conflict of interest for a particular 1243 review (is, for example, an author or significant proponent of a 1244 specification related to the registration under review), that expert 1245 should recuse himself. In the event that all the designated experts 1246 are conflicted, they should ask that a temporary expert be designated 1247 for the conflicted review. The responsible AD may then appoint 1248 someone, or the AD may handle the review. 1250 This document defines the designated expert mechanism with respect to 1251 documents in the IETF stream only. If other streams want to use 1252 registration policies that require designated experts, it is up to 1253 those streams (or those documents) to specify how those designated 1254 experts are appointed and managed. What is described below, with 1255 management by the IESG, is only appropriate for the IETF stream. 1257 5.2.1. Managing Designated Experts in the IETF 1259 Designated experts for registries created by the IETF are appointed 1260 by the IESG, normally upon recommendation by the relevant Area 1261 Director. They may be appointed at the time a document creating or 1262 updating a namespace is approved by the IESG, or subsequently, when 1263 the first registration request is received. Because experts 1264 originally appointed may later become unavailable, the IESG will 1265 appoint replacements as necessary. The IESG may remove any 1266 designated expert that it appointed, at its discretion. 1268 The normal appeals process, as described in [RFC2026], Section 6.5.1, 1269 applies to issues that arise with the designated expert team. For 1270 this purpose, the designated expert team takes the place of the 1271 working group in that description. 1273 5.3. Designated Expert Reviews 1275 In the years since RFC 2434 was published and has been put to use, 1276 experience has led to the following observations: 1278 o A designated expert must respond in a timely fashion, normally 1279 within a week for simple requests to a few weeks for more complex 1280 ones. Unreasonable delays can cause significant problems for 1281 those needing assignments, such as when products need code points 1282 to ship. This is not to say that all reviews can be completed 1283 under a firm deadline, but they must be started, and the requester 1284 and IANA should have some transparency into the process if an 1285 answer cannot be given quickly. 1287 o If a designated expert does not respond to IANA's requests within 1288 a reasonable period of time, either with a response or with a 1289 reasonable explanation for the delay (some requests may be 1290 particularly complex), and if this is a recurring event, IANA must 1291 raise the issue with the IESG. Because of the problems caused by 1292 delayed evaluations and assignments, the IESG should take 1293 appropriate actions to ensure that the expert understands and 1294 accepts his or her responsibilities, or appoint a new expert. 1296 o The designated expert is not required to personally bear the 1297 burden of evaluating and deciding all requests, but acts as a 1298 shepherd for the request, enlisting the help of others as 1299 appropriate. In the case that a request is denied, and rejecting 1300 the request is likely to be controversial, the expert should have 1301 the support of other subject matter experts. That is, the expert 1302 must be able to defend a decision to the community as a whole. 1304 When a designated expert is used, the documentation should give clear 1305 guidance to the designated expert, laying out criteria for performing 1306 an evaluation and reasons for rejecting a request. In the case where 1307 there are no specific documented criteria, the presumption should be 1308 that a code point should be granted unless there is a compelling 1309 reason to the contrary (and see also Section 5.4). Reasons that have 1310 been used to deny requests have included these: 1312 o Scarcity of code points, where the finite remaining code points 1313 should be prudently managed, or where a request for a large number 1314 of code points is made and a single code point is the norm. 1316 o Documentation is not of sufficient clarity to evaluate or ensure 1317 interoperability. 1319 o The code point is needed for a protocol extension, but the 1320 extension is not consistent with the documented (or generally 1321 understood) architecture of the base protocol being extended, and 1322 would be harmful to the protocol if widely deployed. It is not 1323 the intent that "inconsistencies" refer to minor differences "of a 1324 personal preference nature". Instead, they refer to significant 1325 differences such as inconsistencies with the underlying security 1326 model, implying a change to the semantics of an existing message 1327 type or operation, requiring unwarranted changes in deployed 1328 systems (compared with alternate ways of achieving a similar 1329 result), etc. 1331 o The extension would cause problems with existing deployed systems. 1333 o The extension would conflict with one under active development by 1334 the IETF, and having both would harm rather than foster 1335 interoperability. 1337 Documents must not name the designated expert(s) in the document 1338 itself; instead, any suggested names should be relayed to the 1339 appropriate Area Director at the time the document is sent to the 1340 IESG for approval. This is usually done in the document shepherd 1341 writeup. 1343 If the request should also be reviewed on a specific public mailing 1344 list, its address should be specified. 1346 5.4. Expert Reviews and the Document Lifecycle 1348 Review by the designated expert is necessarily done at a particular 1349 point in time, and represents review of a particular version of the 1350 document. While reviews are generally done around the time of IETF 1351 last call, deciding when the review should take place is a question 1352 of good judgment. And while re-reviews might be done when it's 1353 acknowledged that the documentation of the registered item has 1354 changed substantially, making sure that re-review happens requires 1355 attention and care. 1357 It is possible, through carelessness, accident, inattentiveness, or 1358 even willful disregard, that changes might be made after the 1359 designated expert's review and approval that would, if the document 1360 were re-reviewed, cause the expert not to approve the registration. 1361 It is up to the IESG, with the token held by the responsible Area 1362 Director, to be alert to such situations and to recognize that such 1363 changes need to be checked. 1365 For registrations made from documents on the Standards Track, there 1366 is often expert review required (by the registration policy) in 1367 addition to IETF consensus (for approval as a Standards Track RFC). 1368 In such cases, the review by the designated expert needs to be 1369 timely, submitted before the IESG evaluates the document. The IESG 1370 should generally not hold the document up waiting for late review. 1371 It is also not intended for the expert review to override IETF 1372 consensus: the IESG should consider the review in its own evaluation, 1373 as it would do for other last-call reviews. 1375 6. Well-Known Registration Status Terminology 1377 The following labels describe the status of an assignment or range of 1378 assignments: 1380 Private Use: Private use only (not assigned), as described in 1381 Section 4.1. 1383 Experimental: Available for general experimental use as described 1384 in [RFC3692]. IANA does not record specific assignments for 1385 any particular use. 1387 Unassigned: Not currently assigned, and available for assignment 1388 via documented procedures. While it's generally clear that 1389 any values that are not registered are unassigned and 1390 available for assignment, it is sometimes useful to 1391 explicitly specify that situation. Note that this is 1392 distinctly different from "Reserved". 1394 Reserved: Not assigned and not available for assignment. Reserved 1395 values are held for special uses, such as to extend the 1396 namespace when it becomes exhausted. "Reserved" is also 1397 sometimes used to designate values that had been assigned 1398 but are no longer in use, keeping them set aside as long as 1399 other unassigned values are available. Note that this is 1400 distinctly different from "Unassigned". 1402 Reserved values can be released for assignment by the change 1403 controller for the registry (this is often the IESG, for 1404 registries created by RFCs in the IETF stream). 1406 Known Unregistered Use: It's known that the assignment or range is 1407 in use without having been defined in accordance with 1408 reasonable practice. Documentation for use of the 1409 assignment or range may be unavailable, inadequate, or 1410 conflicting. This is a warning against use, as well as an 1411 alert to network operators, who might see these values in 1412 use on their networks. 1414 7. Documentation References in IANA Registries 1416 Usually, registries and registry entries include references to 1417 documentation (RFCs or other documents). The purpose of these 1418 references is to provide pointers for implementors to find details 1419 necessary for implementation, NOT to simply note what document 1420 created the registry or entry. Therefore: 1422 o If a document registers an item that is defined and explained 1423 elsewhere, the registered reference should be to the document 1424 containing the definition, not to the document that is merely 1425 performing the registration. 1427 o If the registered item is defined and explained in the current 1428 document, it is important to include sufficient information to 1429 enable implementors to understand the item and to create a proper 1430 implementation. 1432 o If the registered item is explained primarily in a specific 1433 section of the reference document, it is useful to include a 1434 section reference. For example, "[RFC4637], Section 3.2", rather 1435 than just "[RFC4637]". 1437 o For documentation of a new registry, the reference should provide 1438 information about the registry itself, not just a pointer to the 1439 creation of it. Useful information includes the purpose of the 1440 registry, a rationale for its creation, documentation of the 1441 process and policy for new registrations, guidelines for new 1442 registrants or designated experts, and other such related 1443 information. But note that, while it's important to include this 1444 information in the document, it needn't all be in the IANA 1445 Considerations section. See Section 1.1. 1447 8. What to Do in "bis" Documents 1449 On occasion, an RFC is issued that obsoletes a previous edition of 1450 the same document. We sometimes call these "bis" documents, such as 1451 when RFC 4637 is obsoleted by draft-ietf-foo-rfc4637bis. When the 1452 original document created registries and/or registered entries, there 1453 is a question of how to handle the IANA Considerations section in the 1454 "bis" document. 1456 If the registrations specify the original document as a reference, 1457 those registrations should be updated to point to the current (not 1458 obsolete) documentation for those items. Usually, that will mean 1459 changing the reference to be the "bis" document. 1461 There will, though, be times when a document updates another, but 1462 does not make it obsolete, and the definitive reference is changed 1463 for some items but not for others. Be sure that the references are 1464 always set to point to the correct, current documentation for each 1465 item. 1467 For example, suppose RFC 4637 registered the "BANANA" flag in the 1468 "Fruit Access Flags" registry, and the documentation for that flag is 1469 in Section 3.2. 1471 The current registry might look, in part, like this: 1473 Name Description Reference 1474 -------- ------------------- --------- 1475 BANANA Flag for bananas [RFC4637], Section 3.2 1477 If draft-ietf-foo-rfc4637bis obsoletes RFC 4637 and, because of some 1478 rearrangement, now documents the flag in Section 4.1.2, the IANA 1479 Considerations of the bis document might contain text such as this: 1481 IANA is asked to change the registration information for the 1482 BANANA flag in the "Fruit Access Flags" registry to the following: 1484 Name Description Reference 1485 -------- ------------------- --------- 1486 BANANA Flag for bananas [[this RFC]], Section 4.2.1 1488 In many cases, if there are a number of registered references to the 1489 original RFC and the document organization has not changed the 1490 registered section numbering much, it may simply be reasonable to do 1491 this: 1493 Because this document obsoletes RFC 4637, IANA is asked to change 1494 all registration information that references [RFC4637] to instead 1495 reference [[this RFC]]. 1497 If information for registered items has been or is being moved to 1498 other documents, then the registration information should be changed 1499 to point to those other documents. In most cases, documentation 1500 references should not be left pointing to the obsoleted document for 1501 registries or registered items that are still in current use. For 1502 registries or registered items that are no longer in current use, it 1503 will usually make sense to leave the references pointing to the old 1504 document -- the last current reference for the obsolete items. The 1505 main point is to make sure that the reference pointers are as useful 1506 and current as is reasonable, and authors should consider that as 1507 they write the IANA Considerations for the new document. As always: 1508 do the right thing, and there is flexibility to allow for that. 1510 It is extremely important to be clear in your instructions regarding 1511 updating references, especially in cases where some references need 1512 to be updated and others do not. 1514 9. Miscellaneous Issues 1516 9.1. When There Are No IANA Actions 1518 Before an Internet-Draft can be published as an RFC, IANA needs to 1519 know what actions (if any) it needs to perform. Experience has shown 1520 that it is not always immediately obvious whether a document has no 1521 IANA actions, without reviewing the document in some detail. In 1522 order to make it clear to IANA that it has no actions to perform (and 1523 that the author has consciously made such a determination), such 1524 documents should, after the authors confirm that this is the case, 1525 include an IANA Considerations section that states: 1527 This document has no IANA actions. 1529 IANA prefers that these "empty" IANA Considerations sections be left 1530 in the document for the record: it makes it clear later on that the 1531 document explicitly said that no IANA actions were needed (and that 1532 it wasn't just omitted). This is a change from the prior practice of 1533 requesting that such sections be removed by the RFC Editor, and 1534 authors are asked to accommodate this change. 1536 9.2. Namespaces Lacking Documented Guidance 1538 For all existing RFCs that either explicitly or implicitly rely on 1539 IANA to make assignments without specifying a precise assignment 1540 policy, IANA will work with the IESG to decide what policy is 1541 appropriate. Changes to existing policies can always be initiated 1542 through the normal IETF consensus process, or through the IESG when 1543 appropriate. 1545 All future RFCs that either explicitly or implicitly rely on IANA to 1546 register or otherwise administer namespace assignments must provide 1547 guidelines for administration of the namespace. 1549 9.3. After-the-Fact Registrations 1550 Occasionally, the IETF becomes aware that an unassigned value from a 1551 namespace is in use on the Internet or that an assigned value is 1552 being used for a different purpose than it was registered for. The 1553 IETF does not condone such misuse; procedures of the type described 1554 in this document need to be applied to such cases, and it might not 1555 always be possible to formally assign the desired value. In the 1556 absence of specifications to the contrary, values may only be 1557 reassigned for a different purpose with the consent of the original 1558 assignee (when possible) and with due consideration of the impact of 1559 such a reassignment. In cases of likely controversy, consultation 1560 with the IESG is advised. 1562 This is part of the reason for the advice in Section 3.1 about using 1563 placeholder values, such as "TBD1", during document development: open 1564 use of unregistered values after results from well-meant, early 1565 implementations, where the implementations retained the use of 1566 developmental code points that never proceeded to a final IANA 1567 assignment. 1569 9.4. Reclaiming Assigned Values 1571 Reclaiming previously assigned values for reuse is tricky, because 1572 doing so can lead to interoperability problems with deployed systems 1573 still using the assigned values. Moreover, it can be extremely 1574 difficult to determine the extent of deployment of systems making use 1575 of a particular value. However, in cases where the namespace is 1576 running out of unassigned values and additional ones are needed, it 1577 may be desirable to attempt to reclaim unused values. When 1578 reclaiming unused values, the following (at a minimum) should be 1579 considered: 1581 o Attempts should be made to contact the original party to which a 1582 value is assigned, to determine if the value was ever used, and if 1583 so, the extent of deployment. (In some cases, products were never 1584 shipped or have long ceased being used. In other cases, it may be 1585 known that a value was never actually used at all.) 1587 o Reassignments should not normally be made without the concurrence 1588 of the original requester. Reclamation under such conditions 1589 should only take place where there is strong evidence that a value 1590 is not widely used, and the need to reclaim the value outweighs 1591 the cost of a hostile reclamation. In any case, IESG Approval is 1592 needed in this case. 1594 o It may be appropriate to write up the proposed action and solicit 1595 comments from relevant user communities. In some cases, it may be 1596 appropriate to write an RFC that goes through a formal IETF 1597 process (including IETF Last Call) as was done when DHCP reclaimed 1598 some of its "Private Use" options [RFC3942]. 1600 o It may be useful to differentiate between revocation, release, and 1601 transfer. Revocation occurs when IANA removes an assignment, 1602 release occurs when the assignee initiates that removal, and 1603 transfer occurs when either revocation or release is coupled with 1604 immediate reassignment. It may be useful to specify procedures 1605 for each of these, or to explicitly prohibit combinations that are 1606 not desired. 1608 9.5. Contact Person vs Assignee or Owner 1610 Many registries include designation of a technical or administrative 1611 contact associated with each entry. Often, this is recorded as 1612 contact information for an individual. It is unclear, though, what 1613 role the individual has with respect to the registration: is this 1614 item registered on behalf of the individual, the company the 1615 individual worked for, or perhaps another organization the individual 1616 was acting for? 1618 This matters because some time later, when the individual has changed 1619 jobs or roles, and perhaps can no longer be contacted, someone might 1620 want to update the registration. IANA has no way to know what 1621 company, organization, or individual should be allowed to take the 1622 registration over. For registrations rooted in RFCs, the stream 1623 owner (such as the IESG or the IAB) can make an overriding decision. 1624 But in other cases, there is no recourse. 1626 Registries can include, in addition to a "Contact" field, an 1627 "Assignee" or "Owner" field (also referred to as "Change Controller") 1628 that can be used to address this situation, giving IANA clear 1629 guidance as to the actual owner of the registration. This is 1630 strongly advised especially for registries that do not require RFCs 1631 to manage their information (registries with policies such as First 1632 Come First Served Section 4.4, Expert Review Section 4.5, and 1633 Specification Required Section 4.6). Alternatively, organizations 1634 can put an organizational role into the "Contact" field in order to 1635 make their ownership clear. 1637 9.6. Closing or Obsoleting a Registry/Registrations 1639 Sometimes there is a request to "close" a registry to further 1640 registrations. When a registry is closed, no further registrations 1641 will be accepted. The information in the registry will still be 1642 valid and registrations already in the registry can still be updated. 1644 A closed registry can also be marked as "obsolete", as an indication 1645 that the information in the registry is no longer in current use. 1647 Specific entries in a registry can be marked as "obsolete" (no longer 1648 in use) or "deprecated" (use is not recommended). 1650 Such changes to registries and registered values are subject to 1651 normal change controls (see Section 2.3). Any closure, obsolescence, 1652 or deprecation serves to annotate the registry involved; the 1653 information in the registry remains there for informational and 1654 historic purposes. 1656 10. Appeals 1658 Appeals of protocol parameter registration decisions can be made 1659 using the normal IETF appeals process as described in [RFC2026], 1660 Section 6.5. That is, an initial appeal should be directed to the 1661 IESG, followed (if necessary) by an appeal to the IAB. 1663 11. Mailing Lists 1665 All IETF mailing lists associated with evaluating or discussing 1666 assignment requests as described in this document are subject to 1667 whatever rules of conduct and methods of list management are 1668 currently defined by Best Current Practices or by IESG decision. 1670 12. Security Considerations 1672 Information that creates or updates a registration needs to be 1673 authenticated and authorized. IANA updates registries according to 1674 instructions in published RFCs and from the IESG. It also may accept 1675 clarifications from document authors, relevant working group chairs, 1676 Designated Experts, and mail list participants, too. 1678 Information concerning possible security vulnerabilities of a 1679 protocol may change over time. Likewise, security vulnerabilities 1680 related to how an assigned number is used may change as well. As new 1681 vulnerabilities are discovered, information about such 1682 vulnerabilities may need to be attached to existing registrations, so 1683 that users are not misled as to the true security issues surrounding 1684 the use of a registered number. 1686 Security needs to be considered as part of the selection of a 1687 registration policy. For some protocols, registration of certain 1688 parameters will have security implications, and registration policies 1689 for the relevant registries must ensure that requests get appropriate 1690 review with those security implications in mind. 1692 An analysis of security issues is generally required for all 1693 protocols that make use of parameters (data types, operation codes, 1694 keywords, etc.) used in IETF protocols or registered by IANA. Such 1695 security considerations are usually included in the protocol document 1696 [RFC3552]. It is the responsibility of the IANA considerations 1697 associated with a particular registry to specify whether value- 1698 specific security considerations must be provided when assigning new 1699 values, and the process for reviewing such claims. 1701 13. IANA Considerations 1702 IANA is asked to update any references to RFC 5226 to now point to 1703 this document. 1705 14. Changes Relative to Earlier Editions of BCP 26 1707 14.1. 2016: Changes in This Document Relative to RFC 5226 1709 Significant additions: 1711 o Removed RFC 2119 key words, boilerplate, and reference, preferring 1712 plain English -- this is not a protocol specification. 1714 o Added Section 1.1, Keep IANA Considerations for IANA 1716 o Added Section 1.2, For More Information 1718 o Added Section 2.1, Hierarchical Registry Structure 1720 o Added best practice for selecting an appropriate policy into 1721 Section 4. 1723 o Added Section 4.12, Using Multiple Policies in Combination. 1725 o Added Section 2.3, Specifying Change Control for a Registry 1727 o Added Section 3.4, Early Allocations 1729 o Moved well-known policies into a separate section for each, 1730 subsections of Section 4. 1732 o Added Section 5.4, Expert Reviews and the Document Lifecycle 1734 o Added Section 7, Documentation References in IANA Registries 1736 o Added Section 8, What to Do in "bis" Documents 1738 o Added Section 9.5, Contact Person vs Assignee or Owner 1740 o Added Section 9.6, Closing or Obsoleting a Registry 1742 Clarifications and such: 1744 o Some reorganization -- moved text around for clarity and easier 1745 reading. 1747 o Made clarifications about identification of IANA registries and 1748 use of URLs for them. 1750 o Clarified the distinction between "Unassigned" and "Reserved". 1752 o Made some clarifications in "Expert Review" about instructions to 1753 the designated expert. 1755 o Made some clarifications in "Specification Required" about how to 1756 declare this policy. 1758 o Assorted minor clarifications and editorial changes throughout. 1760 14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 1762 Changes include: 1764 o Major reordering of text to expand descriptions and to better 1765 group topics such as "updating registries" vs. "creating new 1766 registries", in order to make it easier for authors to find the 1767 text most applicable to their needs. 1769 o Numerous editorial changes to improve readability. 1771 o Changed the term "IETF Consensus" to "IETF Review" and added more 1772 clarifications. History has shown that people see the words "IETF 1773 Consensus" (without consulting the actual definition) and are 1774 quick to make incorrect assumptions about what the term means in 1775 the context of IANA Considerations. 1777 o Added "RFC Required" to list of defined policies. 1779 o Much more explicit directions and examples of "what to put in 1780 RFCs". 1782 o "Specification Required" now implies use of a Designated Expert to 1783 evaluate specs for sufficient clarity. 1785 o Significantly changed the wording in the Designated Experts 1786 section. Main purpose is to make clear that Expert Reviewers are 1787 accountable to the community, and to provide some guidance for 1788 review criteria in the default case. 1790 o Changed wording to remove any special appeals path. The normal 1791 RFC 2026 appeals path is used. 1793 o Added a section about reclaiming unused values. 1795 o Added a section on after-the-fact registrations. 1797 o Added a section indicating that mailing lists used to evaluate 1798 possible assignments (such as by a Designated Expert) are subject 1799 to normal IETF rules. 1801 15. Acknowledgments 1803 15.1. Acknowledgments for This Document (2016) 1804 Thomas Narten and Harald Tveit Alvestrand edited the two earlier 1805 editions of this document (RFCs 2434 and 5226), and Thomas continues 1806 his role in this third edition. Much of the text from RFC 5226 1807 remains in this edition. 1809 Thank you to Amanda Baber and Pearl Liang for their multiple reviews 1810 and suggestions for making this document as thorough as possible. 1812 This document has benefited from thorough review and comments by many 1813 people, including Benoit Claise, Alissa Cooper, Adrian Farrel, 1814 Stephen Farrell, Tony Hansen, John Klensin, Kathleen Moriarty, Mark 1815 Nottingham, Pete Resnick, and Joe Touch. 1817 Special thanks to Mark Nottingham for reorganizing some of the text 1818 for better organization and readability, to Tony Hansen for acting as 1819 document shepherd, and to Brian Haberman and Terry Manderson for 1820 acting as sponsoring ADs. 1822 15.2. Acknowledgments from the second edition (2008) 1824 The original acknowledgments section in RFC 5226 was: 1826 This document has benefited from specific feedback from Jari Arkko, 1827 Marcelo Bagnulo Braun, Brian Carpenter, Michelle Cotton, Spencer 1828 Dawkins, Barbara Denny, Miguel Garcia, Paul Hoffman, Russ Housley, 1829 John Klensin, Allison Mankin, Blake Ramsdell, Mark Townsley, Magnus 1830 Westerlund, and Bert Wijnen. 1832 15.3. Acknowledgments from the first edition (1998) 1834 The original acknowledgments section in RFC 2434 was: 1836 Jon Postel and Joyce Reynolds provided a detailed explanation on what 1837 IANA needs in order to manage assignments efficiently, and patiently 1838 provided comments on multiple versions of this document. Brian 1839 Carpenter provided helpful comments on earlier versions of the 1840 document. One paragraph in the Security Considerations section was 1841 borrowed from RFC 4288. 1843 16. References 1845 16.1. Normative References 1847 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1848 3", BCP 9, RFC 2026, October 1996. 1850 16.2. Informative References 1852 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1853 1981. 1855 [RFC1591] Postel, J., "Domain Name System Structure and Delegation", 1856 RFC 1591, DOI 10.17487/RFC1591, March 1994, . 1859 [RFC2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of 1860 Understanding Concerning the Technical Work of the 1861 Internet Assigned Numbers Authority", RFC 2860, June 2000. 1863 [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition 1864 of New DHCP Options and Message Types", BCP 43, RFC 2939, 1865 September 2000. 1867 [RFC3228] Fenner, B., "IANA Considerations for IPv4 Internet Group 1868 Management Protocol (IGMP)", BCP 57, RFC 3228, February 1869 2002. 1871 [RFC3406] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, 1872 "Uniform Resource Names (URN) Namespace Definition 1873 Mechanisms", BCP 66, RFC 3406, DOI 10.17487/RFC3406, 1874 October 2002, . 1876 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1877 Text on Security Considerations", BCP 72, RFC 3552, July 1878 2003. 1880 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1881 Authentication Dial In User Service)", RFC 3575, July 1882 2003. 1884 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1885 Considered Useful", BCP 82, RFC 3692, January 2004. 1887 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 1888 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1889 3748, June 2004. 1891 [RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration 1892 Protocol version 4 (DHCPv4) Options", RFC 3942, November 1893 2004. 1895 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 1896 (IANA) Header Field Parameter Registry for the Session 1897 Initiation Protocol (SIP)", BCP 98, RFC 3968, December 1898 2004. 1900 [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 1901 Network Access Server Application", RFC 4005, August 2005. 1903 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 1904 Material in DNS", RFC 4025, March 2005. 1906 [RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, 1907 May 2005. 1909 [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of 1910 Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 1911 2005. 1913 [RFC4169] Torvinen, V., Arkko, J. and M. Naslund, "Hypertext 1914 Transfer Protocol (HTTP) Digest Authentication Using 1915 Authentication and Key Agreement (AKA) Version-2", RFC 1916 4169, November 2005. 1918 [RFC4271] Rekhter, Y., Li, T. and S. Hares, "A Border Gateway 1919 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1921 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H. and K. 1922 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 1923 (MIPv6)", RFC 4283, November 2005. 1925 [RFC4340] Kohler, E., Handley, M. and S. Floyd, "Datagram Congestion 1926 Control Protocol (DCCP)", RFC 4340, March 2006. 1928 [RFC4395] Hansen, T., Hardie, T. and L. Masinter, "Guidelines and 1929 Registration Procedures for New URI Schemes", BCP 35, RFC 1930 4395, February 2006. 1932 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1933 Security Layer (SASL)", RFC 4422, June 2006. 1935 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 1936 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 1938 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 1939 Considerations for the Lightweight Directory Access 1940 Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 1942 [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types 1943 Registry", RFC 4589, July 2006. 1945 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1946 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 1948 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1949 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1951 [RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide 1952 to the IETF Trust", BCP 78, RFC 5378, November 2008. 1954 [RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for 1955 Handling of Independent and IRTF Stream Submissions", BCP 1956 92, RFC 5742, December 2009. 1958 [RFC5771] Cotton, M., Vegoda, L. and D. Meyer, "IANA Guidelines for 1959 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 1960 March 2010. 1962 [RFC5795] Sandlund, K., Pelletier, G. and L-E. Jonsson, "The RObust 1963 Header Compression (ROHC) Framework", RFC 5795, March 1964 2010. 1966 [RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier 1967 Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014, 1968 November 2010, . 1970 [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA 1971 Considerations", BCP 42, RFC 6195, March 2011. 1973 [RFC6230] Boulton, C., Melanchuk, T. and S. McGlashan, "Media 1974 Control Channel Framework", RFC 6230, DOI 10.17487/ 1975 RFC6230, May 2011, . 1978 [RFC6275] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support 1979 in IPv6", RFC 6275, July 2011. 1981 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1982 of Named Entities (DANE) Transport Layer Security (TLS) 1983 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 1984 2012, . 1986 [RFC6709] Carpenter, B., Aboba, B. and S. Cheshire, "Design 1987 Considerations for Protocol Extensions", RFC 6709, 1988 September 2012. 1990 [RFC6838] Freed, N., Klensin, J. and T. Hansen, "Media Type 1991 Specifications and Registration Procedures", BCP 13, RFC 1992 6838, DOI 10.17487/RFC6838, January 2013, . 1995 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 1996 6994, DOI 10.17487/RFC6994, August 2013, . 1999 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 2000 Points", BCP 100, RFC 7120, January 2014. 2002 [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: 2003 Preparation, Enforcement, and Comparison of 2004 Internationalized Strings in Application Protocols", RFC 2005 7564, DOI 10.17487/RFC7564, May 2015, . 2008 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A. and 2009 S. Ray, "North-Bound Distribution of Link-State and 2010 Traffic Engineering (TE) Information Using BGP", RFC 7752, 2011 DOI 10.17487/RFC7752, March 2016, . 2014 Authors' Addresses 2015 Michelle Cotton 2016 Internet Corporation for Assigned Names and Numbers 2017 12025 Waterfront Drive, Suite 300 2018 Los Angeles, CA 90094-2536 2019 US 2021 Phone: +1 310 823 9358 2022 Email: michelle.cotton@icann.org 2023 URI: https://www.icann.org/ 2025 Barry Leiba 2026 Huawei Technologies 2028 Phone: +1 646 827 0648 2029 Email: barryleiba@computer.org 2030 URI: http://internetmessagingtechnology.org/ 2032 Thomas Narten 2033 IBM Corporation 2034 3039 Cornwallis Ave., PO Box 12195 - BRQA/502 2035 Research Triangle Park, NC 27709-2195 2036 US 2038 Phone: +1 919 254 7798 2039 Email: narten@us.ibm.com