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