idnits 2.17.00 (12 Aug 2021) /tmp/idnits6759/draft-leiba-cotton-iana-5226bis-13.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 (May 25, 2016) is 2186 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 358, but not defined == Missing Reference: 'BCP26' is mentioned on line 1065, but not defined == Missing Reference: 'RFC4637' is mentioned on line 1377, 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 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6195 (Obsoleted by RFC 6895) -- Obsolete informational reference (is this intentional?): RFC 7564 (Obsoleted by RFC 8264) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Cotton 3 Internet-Draft ICANN 4 BCP: 26 B. Leiba 5 Obsoletes: 5226 (if approved) Huawei Technologies 6 Intended status: Best Current Practice T. Narten 7 Expires: November 24, 2016 IBM Corporation 8 May 25, 2016 10 Guidelines for Writing an IANA Considerations Section in RFCs 11 draft-leiba-cotton-iana-5226bis-13 13 Abstract 15 Many protocols make use of points of extensibility that use constants 16 to identify various protocol parameters. To ensure that the values 17 used in these fields do not have conflicting uses, and to promote 18 interoperability, their allocation is often coordinated by a central 19 record keeper. For IETF protocols, that role is filled by the 20 Internet Assigned Numbers Authority (IANA). 22 To make assignments in a given registry prudently, IANA needs 23 guidance describing the conditions under which new values should be 24 assigned, as well as when and how modifications to existing values 25 can be made. This document defines a framework for the documentation 26 of these guidelines by specification authors, in order to assure that 27 the guidance given to IANA is clear and addresses the various issues 28 that are likely in the operation of a registry. 30 This is the third edition of this document; it obsoletes RFC 5226. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on November 24, 2016. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Keep IANA Considerations for IANA . . . . . . . . . . . . 3 67 1.2. For More Information . . . . . . . . . . . . . . . . . . . 4 68 2. Creating and Revising Registries . . . . . . . . . . . . . . . 4 69 2.1. Organization of Registries . . . . . . . . . . . . . . . . 4 70 2.2. Documentation Requirements for Registries . . . . . . . . 6 71 2.3. Specifying Change Control for a Registry . . . . . . . . . 8 72 2.4. Revising Existing Registries . . . . . . . . . . . . . . . 9 73 3. Registering New Values in an Existing Registry . . . . . . . . 9 74 3.1. Documentation Requirements for Registrations . . . . . . . 9 75 3.2. Updating Existing Registrations . . . . . . . . . . . . . 11 76 3.3. Overriding Registration Procedures . . . . . . . . . . . . 12 77 3.4. Early Allocations . . . . . . . . . . . . . . . . . . . . 12 78 4. Choosing a Registration Policy, and Well-Known Policies . . . 13 79 4.1. Private Use . . . . . . . . . . . . . . . . . . . . . . . 15 80 4.2. Experimental Use . . . . . . . . . . . . . . . . . . . . . 15 81 4.3. Hierarchical Allocation . . . . . . . . . . . . . . . . . 16 82 4.4. First Come First Served . . . . . . . . . . . . . . . . . 16 83 4.5. Expert Review . . . . . . . . . . . . . . . . . . . . . . 17 84 4.6. Specification Required . . . . . . . . . . . . . . . . . . 18 85 4.7. RFC Required . . . . . . . . . . . . . . . . . . . . . . . 19 86 4.8. IETF Review . . . . . . . . . . . . . . . . . . . . . . . 19 87 4.9. Standards Action . . . . . . . . . . . . . . . . . . . . . 19 88 4.10. IESG Approval . . . . . . . . . . . . . . . . . . . . . . 20 89 4.11. Using the Well-Known Registration Policies . . . . . . . . 20 90 4.12. Using Multiple Policies in Combination . . . . . . . . . . 21 91 5. Designated Experts . . . . . . . . . . . . . . . . . . . . . . 22 92 5.1. The Motivation for Designated Experts . . . . . . . . . . 22 93 5.2. The Role of the Designated Expert . . . . . . . . . . . . 22 94 5.2.1. Managing Designated Experts in the IETF . . . . . . . 23 95 5.3. Designated Expert Reviews . . . . . . . . . . . . . . . . 24 96 5.4. Expert Reviews and the Document Lifecycle . . . . . . . . 25 97 6. Well-Known Registration Status Terminology . . . . . . . . . . 26 98 7. Documentation References in IANA Registries . . . . . . . . . 27 99 8. What to Do in "bis" Documents . . . . . . . . . . . . . . . . 27 100 9. Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . 28 101 9.1. When There Are No IANA Actions . . . . . . . . . . . . . . 28 102 9.2. Namespaces Lacking Documented Guidance . . . . . . . . . . 29 103 9.3. After-the-Fact Registrations . . . . . . . . . . . . . . . 29 104 9.4. Reclaiming Assigned Values . . . . . . . . . . . . . . . . 29 105 9.5. Contact Person vs Assignee or Owner . . . . . . . . . . . 30 106 9.6. Closing or Obsoleting a Registry/Registrations . . . . . . 31 108 10. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 109 11. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 31 110 12. Security Considerations . . . . . . . . . . . . . . . . . . . 31 111 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 112 14. Changes Relative to Earlier Editions of BCP 26 . . . . . . . . 32 113 14.1. 2016: Changes in This Document Relative to RFC 5226 . . . 32 114 14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 . . . . . 33 115 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 116 15.1. Acknowledgments for This Document (2016) . . . . . . . . 34 117 15.2. Acknowledgments from the second edition (2008) . . . . . 34 118 15.3. Acknowledgments from the first edition (1998) . . . . . . 34 119 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 120 16.1. Normative References . . . . . . . . . . . . . . . . . . 35 121 16.2. Informative References . . . . . . . . . . . . . . . . . 35 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 124 1. Introduction 126 Many protocols make use of points of extensibility that use constants 127 to identify various protocol parameters. To ensure that the values 128 used in these fields do not have conflicting uses, and to promote 129 interoperability, their allocation is often coordinated by a central 130 record keeper. For IETF protocols, that role is filled by the 131 Internet Assigned Numbers Authority (IANA) [RFC2860]. 133 The Protocol field in the IP header [RFC0791] and MIME media types 134 [RFC4288] are two examples of such coordinations. 136 In this document, we call the range of possible values for such a 137 field a "namespace". The binding or association of a specific value 138 with a particular purpose within a namespace is called an assignment 139 (or, variously: an assigned number, assigned value, code point, 140 protocol constant, or protocol parameter). The act of assignment is 141 called a registration, and it takes place in the context of a 142 registry. The terms "assignment" and "registration" are used 143 interchangably throughout this document. 145 To make assignments in a given namespace prudently, IANA needs 146 guidance describing the conditions under which new values should be 147 assigned, as well as when and how modifications to existing values 148 can be made. This document defines a framework for the documentation 149 of these guidelines by specification authors, in order to assure that 150 the guidance given to IANA is clear and addresses the various issues 151 that are likely in the operation of a registry. 153 Typically, this information is recorded in a dedicated section of the 154 specification with the title "IANA Considerations". 156 1.1. Keep IANA Considerations for IANA 157 The purpose of having a dedicated IANA Considerations section is to 158 provide a single place to collect clear and concise information and 159 instructions for IANA. Technical documentation should reside in 160 other parts of the document, and should be included by reference 161 only. Using the IANA Considerations section as primary technical 162 documentation both hides it from the target audience of the document 163 and interferes with IANA's review of the actions they need to take. 165 An ideal IANA Considerations section clearly enumerates and specifies 166 each requested IANA action; includes all information IANA needs, such 167 as the full names of all applicable registries; and includes clear 168 references to elsewhere in the document for other information. 170 1.2. For More Information 172 IANA maintains a web page that includes current important information 173 from IANA. Document authors should check that page for additional 174 information, beyond what is provided here. 176 . 178 [[(RFC Editor: Please remove this paragraph.) The initial version of 179 this should contain the bits that are salient to most document 180 authors -- perhaps a table of required elements to create a new 181 registry or update one, a bit about sub-registries, and the listing 182 of well-known registration policies. IANA has text for this, but 183 they need to work on their process to put the page up (transition 184 issues). We might host the first version on the IETF site, with the 185 URL above set to redirect to it. ]] 187 2. Creating and Revising Registries 189 Defining a registry involves describing the namespaces to be created, 190 listing an initial set of assignments (if applicable), and 191 documenting guidelines on how future assignments are to be made. 193 When defining a registry, consider structuring the namespace in such 194 a way that only top-level assignments need to be made with central 195 coordination, and those assignments can delegate lower-level 196 assignments so coordination for them can be distributed. This 197 lessens the burden on IANA for dealing with assignments, and is 198 particularly useful in situations where distributed coordinators have 199 better knowledge of their portion of the namespace and are better 200 suited to handling those assignments. 202 2.1. Organization of Registries 204 All registries are anchored from the IANA "Protocol Registries" page: 206 . 208 That page lists registries in protocol category groups, like this: 210 --------------------------------------------------------------- 211 Author Domain Signing Practices (ADSP) Parameters 213 ADSP Outbound Signing Practices RFC 5617 214 IETF Review 216 ADSP Specification Tags RFC 5617 217 IETF Review 219 Automatic Responses to Electronic Mail Parameters 221 Auto-Submitted Header Field RFC 5436 222 Keywords Specification Required 224 Auto-Submitted header field RFC 3834 225 optional parameters IETF Consensus 227 Autonomous System (AS) Numbers 229 16-bit Autonomous System Numbers RFC 1930, RFC 5398, RFC 6996 230 RIR request to the IANA 231 or IETF Review 233 32-bit Autonomous System Numbers RFC 1930, RFC 5398, RFC 6793, 234 RFC 6996 235 RIR request to the IANA 236 or IETF Review 237 --------------------------------------------------------------- 239 The grouping allows related registries to be placed together, making 240 it easier for users of the registries to find the necessary 241 information. In the example section above, all registries related to 242 the ADSP protocol are placed in the "ADSP Parameters" group. 244 Within the "ADSP Parameters" group are two registries: "ADSP Outbound 245 Signing Practices" and "ADSP Specification Tags". Clicking on the 246 title of one of these registries on the IANA Protocol Registries page 247 will take the reader to the details page for that registry. Often, 248 multiple registries are shown on the same details page. 250 Unfortunately, we have been inconsistent in how we refer to these 251 entities. The group names, as they are referred to here, have been 252 variously called "protocol category groups", "groups", "top-level 253 registries", or just "registries". The registries under them have 254 been called "registries" or "sub-registries". 256 Regardless of the terminology used, document authors should pay 257 attention to the registry groupings, should request that related 258 registries be grouped together to make related registries easier to 259 find, and, when creating a new registry, should check whether that 260 registry might best be included in an existing group. That grouping 261 information should be clearly communicated to IANA in the registry 262 creation request. 264 2.2. Documentation Requirements for Registries 266 Documents that create a new namespace (or modify the definition of an 267 existing space) and that expect IANA to play a role in maintaining 268 that space (serving as a repository for registered values) must 269 provide clear instructions on details of the namespace, either in the 270 IANA Considerations section, or referenced from it. 272 In particular, such instructions must include: 274 The name of the registry 275 This name will appear on the IANA web page and will be referred to 276 in future documents that need to allocate a value from the new 277 space. The full name (and abbreviation, if appropriate) should be 278 provided. It is highly desirable that the chosen name not be 279 easily confused with the name of another registry. 281 When creating a registry, the group that it is a part of must be 282 identified using its full name, exactly as it appears in the IANA 283 registry list. 285 Providing a URL to precisely identify the registry helps IANA 286 understand the request. Such URLs can be removed from the RFC 287 prior to final publication. If they are to be left in, it is 288 important that they be permanent links. IANA can answer questions 289 about the correct URLs to use. 291 For example, a document could contain something like this: 293 This registration should be made in the Foobar Operational 294 Parameters registry, located at . 297 It might be tempting to use the URL that appears in your web 298 browser's address bar, which might look something like this for 299 the example above: 301 https://www.iana.org/assignments/foobar-registry/foobar- 302 registry.xml 304 ...but that is not the permanent link to the registry. 306 Required information for registrations 307 This tells registrants what information they have to include in 308 their registration requests. Some registries require only the 309 requested value and a reference to a document where use of the 310 value is defined. Other registries require a more detailed 311 registration template that describes relevant security 312 considerations, internationalization considerations, and other 313 such information. 315 Applicable registration policy 317 The policy that will apply to all future requests for 318 registration. See Section 4. 320 Size, format and syntax of registry entries 322 What fields to record in the registry, any technical requirements 323 on registry entries (valid ranges for integers, length limitations 324 on strings, and such), and the exact format in which registry 325 values should be displayed. For numeric assignments, one should 326 specify whether values are to be recorded in decimal, in 327 hexadecimal, or in some other format. 329 Strings are expected to be ASCII, and it should be clearly 330 specified whether case matters, and whether, for example, strings 331 should be shown in the registry in upper case or lower case. 333 Strings that represent protocol parameters will rarely, if ever, 334 need to contain non-ASCII characters. If non-ASCII characters are 335 really necessary, instructions should make it very clear that they 336 are allowed and that the non-ASCII characters should be 337 represented as Unicode characters using the "(U+XXXX)" convention. 338 Anyone creating such a registry should think carefully about this 339 and consider internationalization advice such as that in [RFC7564] 340 Section 10. 342 Initial assignments and reservations 344 Any initial assignments or registrations to be included. In 345 addition, any ranges that are to be reserved for "Private Use", 346 "Reserved", "Unassigned", etc. (see Section 6) should be 347 indicated. 349 For example, a document might specify a new registry by including: 351 --------------------------------------------------------------- 353 X. IANA Considerations 355 This document defines a new DHCP option, entitled "FooBar" (see 356 Section y), assigned a value of TBD1 from the DHCP Option space 357 358 [RFC2132] [RFC2939]: 359 Data 360 Tag Name Length Meaning 361 ---- ---- ------ ------- 362 TBD1 FooBar N FooBar server 364 The FooBar option also defines an 8-bit FooType field, for which 365 IANA is to create and maintain a new registry entitled 366 "FooType values" used by the FooBar option. Initial values for the 367 DHCP FooBar FooType registry are given below; future assignments 368 are to be made through Expert Review [BCP26]. 369 Assignments consist of a DHCP FooBar FooType name and its 370 associated value. 372 Value DHCP FooBar FooType Name Definition 373 ---- ------------------------ ---------- 374 0 Reserved 375 1 Frobnitz RFCXXXX, Section y.1 376 2 NitzFrob RFCXXXX, Section y.2 377 3-254 Unassigned 378 255 Reserved 379 --------------------------------------------------------------- 381 For examples of documents that establish registries, consult 382 [RFC3575], [RFC3968], and [RFC4520]. 384 2.3. Specifying Change Control for a Registry 386 Registry definitions and registrations within registries often need 387 to be changed after they are created. The process of making such 388 changes is complicated when it is unclear who is authorized to make 389 the changes. For registries created by RFCs in the IETF stream, 390 change control for the registry lies by default with the IETF, via 391 the IESG. The same is true for value registrations made in IETF- 392 stream RFCs. 394 Because registries can be created and registrations can be made 395 outside the IETF stream, it can sometimes be desirable to have change 396 control outside the IETF and IESG, and clear specification of change 397 control policies is always helpful. 399 It is advised, therefore, that all registries that are created 400 clearly specify a change control policy and a change controller. It 401 is also advised that registries that allow registrations from outside 402 the IETF stream include, for each value, the designation of a change 403 controller for that value. If the definition or reference for a 404 registered value ever needs to change, or if a registered value needs 405 to be deprecated, it is critical that IANA know who is authorized to 406 make the change. See also Section 9.5. 408 While IANA normally includes information about change control in the 409 public registry, some change controllers might prefer that their 410 identities or contact information not be made public. In such cases, 411 arrangements can be made with IANA to keep the information private, 412 to use an alias or role-based contact address, or to otherwise 413 protect the change controller's privacy. 415 2.4. Revising Existing Registries 417 Updating the registration process or making changes to the format of 418 an already existing (previously created) registry (whether created 419 explicitly or implicitly) follows a process similar to that used when 420 creating a new registry. That is, a document is produced that makes 421 reference to the existing namespace and then provides detailed 422 guidance for handling assignments in the registry, or detailed 423 instructions about the changes required. 425 If a change requires a new column in the registry, the instructions 426 need to be clear about how to populate that column for the existing 427 entries. Other changes may require similar clarity. 429 Such documents are normally processed with the same document status 430 as the document that created the registry. Under some circumstances, 431 such as with a straightforward change that is clearly needed (such as 432 adding a "status" column), or when an earlier error needs to be 433 corrected, the IESG may approve an update to a registry without 434 requiring a new document. 436 Example documents that updated the guidelines for assignments in pre- 437 existing registries include: [RFC6195], [RFC3228], and [RFC3575]. 439 3. Registering New Values in an Existing Registry 441 3.1. Documentation Requirements for Registrations 443 Often, documents request an assignment in an existing registry (one 444 created by a previously published document). 446 Such documents should clearly identify the registry into which each 447 value is to be registered. Use the exact registry name as listed on 448 the IANA web page, and cite the RFC where the registry is defined. 450 There is no need to mention what the assignment policy is when making 451 new assignments in existing registries, as that should be clear from 452 the references. However, if multiple assignment policies might 453 apply, as in registries with different ranges that have different 454 policies, it is important to make it clear which range is being 455 requested, so that IANA will know which policy applies and can assign 456 a value in the correct range. 458 When referring to an existing registry, providing a URL to precisely 459 identify the registry is helpful. See Section 2.2 for details on 460 specifying the correct URL. 462 For example, a document could contain something like this: 464 This registration should be made in the Foobar Operational 465 Parameters registry, located at . 468 Normally, numeric values to be used are chosen by IANA when the 469 document is approved, and drafts should not specify final values. 470 Instead, placeholders such as "TBD1" and "TBD2" should be used 471 consistently throughout the document, giving each item to be 472 registered a different placeholder. The IANA Considerations should 473 ask the RFC Editor to replace the placeholder names with the IANA- 474 assigned values. When drafts need to specify numeric values for 475 testing or early implementations, they will either request early 476 allocation (see Section 3.4) or use values that have already been set 477 aside for testing or experimentation (if the registry in question 478 allows that without explicit assignment). It is important that 479 drafts not choose their own values, lest IANA assign one of those 480 values to another document in the meantime. A draft can request a 481 specific value in the IANA Considerations section, and IANA will 482 accommodate such requests when that's possible, but the proposed 483 number might have been assigned to some other use by the time the 484 draft is approved. 486 Normally, text-string values to be used are specified in the 487 document, as collisions are less likely with text strings. IANA will 488 consult with the authors if there is, in fact, a collision, and a 489 different value has to be used. When drafts need to specify string 490 values for testing or early implementations, they sometimes use the 491 expected final value. But it is often useful to use a draft value 492 instead, possibly including the draft version number. This allows 493 the early implementations to be distinguished from those implementing 494 the final version. A document that intends to use "foobar" in the 495 final version might use "foobar-testing-draft-05" for the -05 version 496 of the draft, for example. 498 For some registries, IANA has a long-standing policy prohibiting 499 assignment of names or codes on a vanity or organization-name basis. 500 For example, codes might always be assigned sequentially unless there 501 is a strong reason for making an exception. Nothing in this document 502 is intended to change those policies or prevent their future 503 application. 505 As an example, the following text could be used to request assignment 506 of a DHCPv6 option number: 508 IANA is asked to assign an option code value of TBD1 to the DNS 509 Recursive Name Server option and an option code value of TBD2 to 510 the Domain Search List option from the DHCP option code space 511 defined in Section 24.3 of RFC 3315. 513 The IANA Considerations section should summarize all of the IANA 514 actions, with pointers to the relevant sections elsewhere in the 515 document as appropriate. Including section numbers is especially 516 useful when the reference document is large; the section numbers will 517 make it easier for those searching the reference document to find the 518 relevant information. 520 When multiple values are requested, it is generally helpful to 521 include a summary table of the additions/changes. It is also helpful 522 for this table to be in the same format as it appears or will appear 523 on the IANA web site. For example: 525 Value Description Reference 526 -------- ------------------- --------- 527 TBD1 Foobar this RFC, Section 3.2 528 TBD2 Gumbo this RFC, Section 3.3 529 TBD3 Banana this RFC, Section 3.4 531 Note: In cases where authors feel that including the full table of 532 changes is too verbose or repetitive, authors should still include 533 the table in the draft, but may include a note asking that the table 534 be removed prior to publication of the final RFC. 536 3.2. Updating Existing Registrations 538 Even after a number has been assigned, some types of registrations 539 contain additional information that may need to be updated over time. 541 For example, MIME media types, character sets, and language tags 542 typically include more information than just the registered value 543 itself, and may need updates to items such as point-of-contact 544 information, security issues, pointers to updates, and literature 545 references. 547 In such cases, the document defining the namespace must clearly state 548 who is responsible for maintaining and updating a registration. 549 Depending on the registry, it may be appropriate to specify one or 550 more of: 552 o Letting registrants and/or nominated change controllers update 553 their own registrations, subject to the same constraints and 554 review as with new registrations. 556 o Allowing attachment of comments to the registration. This can be 557 useful in cases where others have significant objections to a 558 registration, but the author does not agree to change the 559 registration. 561 o Designating the IESG, a designated expert, or another entity as 562 having the right to change the registrant associated with a 563 registration and any requirements or conditions on doing so. This 564 is mainly to get around the problem when a registrant cannot be 565 reached in order to make necessary updates. 567 3.3. Overriding Registration Procedures 569 Experience has shown that the documented IANA considerations for 570 individual protocols do not always adequately cover the reality of 571 registry operation, or are not sufficiently clear. In addition, 572 documented IANA considerations are sometimes found to be too 573 stringent to allow even working group documents (for which there is 574 strong consensus) to perform a registration in advance of actual RFC 575 publication. 577 In order to allow assignments in such cases, the IESG is granted 578 authority to override registration procedures and approve assignments 579 on a case-by-case basis. 581 The intention here is not to overrule properly documented procedures, 582 or to obviate the need for protocols to properly document their IANA 583 considerations. Rather, it is to permit assignments in specific 584 cases where it is obvious that the assignment should just be made, 585 but updating the IANA process beforehand is too onerous. 587 When the IESG is required to take action as described above, it is a 588 strong indicator that the applicable registration procedures should 589 be updated, possibly in parallel with the work that instigated it. 591 IANA always has the discretion to ask the IESG for advice or 592 intervention when they feel it is needed, such as in cases where 593 policies or procedures are unclear to them, where they encounter 594 issues or questions they are unable to resolve, or where registration 595 requests or patterns of requests appear to be unusual or abusive. 597 3.4. Early Allocations 598 IANA normally takes its actions when a document is approved for 599 publication. There are times, though, when early allocation of a 600 value is important for the development of a technology: for example, 601 when early implementations are created while the document is still 602 under development. 604 IANA has a mechanism for handling such early allocations in some 605 cases. See [RFC7120] for details. It is usually not necessary to 606 explicitly mark a registry as allowing early allocation, because the 607 general rules will apply. 609 4. Choosing a Registration Policy, and Well-Known Policies 611 A registration policy is the policy that controls how new assignments 612 in a registry are accepted. There are several issues to consider 613 when defining the registration policy. 615 If the registry's namespace is limited, assignments will need to be 616 made carefully to prevent exhaustion. 618 Even when the space is essentially unlimited, it is still often 619 desirable to have at least a minimal review prior to assignment in 620 order to: 622 o prevent the hoarding of or unnecessary wasting of values. For 623 example, if the space consists of text strings, it may be 624 desirable to prevent entities from obtaining large sets of strings 625 that correspond to desirable names (existing company names, for 626 example). 628 o provide a sanity check that the request actually makes sense and 629 is necessary. Experience has shown that some level of minimal 630 review from a subject matter expert is useful to prevent 631 assignments in cases where the request is malformed or not 632 actually needed (for example, an existing assignment for an 633 essentially equivalent service already exists). 635 Perhaps most importantly, unreviewed extensions can impact 636 interoperability and security. See [RFC6709]. 638 When the namespace is essentially unlimited and there are no 639 potential interoperability or security issues, assigned numbers can 640 usually be given out to anyone without any subjective review. In 641 such cases, IANA can make assignments directly, provided that IANA is 642 given detailed instructions on what types of requests it should 643 grant, and it is able to do so without exercising subjective 644 judgement. 646 When this is not the case, some level of review is required. 647 However, it's important to balance adequate review and ease of 648 registration. In many cases, those making registrations will not be 649 IETF participants; requests often come from other standards 650 organizations, from organizations not directly involved in standards, 651 from ad-hoc community work (from an open-source project, for 652 example), and so on. Registration must not be unnecessarily 653 difficult, unnecessarily costly (in terms of time and other 654 resources), nor unnecessarily subject to denial. 656 While it is sometimes necessary to restrict what gets registered 657 (e.g., for limited resources such as bits in a byte, or for items for 658 which unsupported values can be damaging to protocol operation), in 659 many cases having what's in use represented in the registry is more 660 important. Overly strict review criteria and excessive cost (in time 661 and effort) discourage people from even attempting to make a 662 registration. If a registry fails to reflect the protocol elements 663 actually in use, it can adversely affect deployment of protocols on 664 the Internet, and the registry itself is devalued. 666 Therefore, working groups and other document developers should use 667 care in selecting appropriate registration policies when their 668 documents create registries. They should select the least strict 669 policy that suits a registry's needs, and look for specific 670 justification for policies that require significant community 671 involvement (those stricter than Expert Review or Specification 672 Required, in terms of the well-known policies). 674 The following policies are defined for common usage. These cover a 675 range of typical policies that have been used to describe the 676 procedures for assigning new values in a namespace. It is not 677 strictly required that documents use these terms; the actual 678 requirement is that the instructions to IANA be clear and 679 unambiguous. However, use of these terms is strongly recommended 680 because their meanings are widely understood, and newly minted 681 policies should not be used without good reason and explanation. The 682 terms are fully explained in the following subsections. 684 1. Private Use 685 2. Experimental Use 686 3. Hierarchical Allocation 687 4. First Come First Served 688 5. Expert Review 689 6. Specification Required 690 7. RFC Required 691 8. IETF Review 692 9. Standards Action 693 10. IESG Approval 695 It should be noted that it often makes sense to partition a namespace 696 into multiple categories, with assignments within each category 697 handled differently. Many protocols now partition namespaces into 698 two or more parts, with one range reserved for Private or 699 Experimental Use while other ranges are reserved for globally unique 700 assignments assigned following some review process. Dividing a 701 namespace into ranges makes it possible to have different policies in 702 place for different ranges and different use cases. 704 Similarly, it will often be useful to specify multiple policies in 705 parallel, with each policy being used under different circumstances. 706 For more discussion of that topic, see Section 4.12. 708 Examples of RFCs that specify multiple policies in parallel: 710 LDAP [RFC4520] 711 TLS ClientCertificateType Identifiers [RFC5246] (as detailed in 712 the subsections below) 713 MPLS Pseudowire Types Registry [RFC4446] 715 4.1. Private Use 717 For private or local use only, with the type and purpose defined by 718 the local site. No attempt is made to prevent multiple sites from 719 using the same value in different (and incompatible) ways. IANA does 720 not record assignments from registries or ranges with this policy 721 (and therefore there is no need for IANA to review them) and 722 assignments are not generally useful for broad interoperability. It 723 is the responsibility of the sites making use of the Private Use 724 range to ensure that no conflicts occur (within the intended scope of 725 use). 727 Examples: 729 Site-specific options in DHCP [RFC2939] 730 Fibre Channel Port Type Registry [RFC4044] 731 TLS ClientCertificateType Identifiers 224-255 [RFC5246] 733 4.2. Experimental Use 735 Experimental Use is similar to Private Use, but with the purpose 736 being to facilitate experimentation. See [RFC3692] for details. 737 IANA does not record assignments from registries or ranges with this 738 policy (and therefore there is no need for IANA to review them) and 739 assignments are not generally useful for broad interoperability. 740 Unless the registry explicitly allows it, it is not appropriate for 741 documents to select explicit values from registries or ranges with 742 this policy. Specific experiments will select a value to use during 743 the experiment. 745 Example: 747 Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP 748 Headers [RFC4727] 750 4.3. Hierarchical Allocation 752 With Hierarchical Allocation, delegated administrators are given 753 control over part of the namespace, and can assign values in that 754 part of the namespace. IANA makes allocations in the higher levels 755 of the namespace according to one of the other policies. 757 Examples: 759 - DNS names. IANA manages the top-level domains (TLDs), and, as 760 [RFC1591] says: 762 Under each TLD may be created a hierarchy of names. Generally, 763 under the generic TLDs the structure is very flat. That is, 764 many organizations are registered directly under the TLD, and 765 any further structure is up to the individual organizations. 767 - Object Identifiers, defined by ITU-T recommendation X.208. 768 According to , some registries 769 include 771 * IANA, which hands out OIDs the "Private Enterprises" branch, 772 * ANSI, which hands out OIDs under the "US Organizations" branch, 773 and 774 * BSI, which hands out OIDs under the "UK Organizations" branch. 776 - URN namespaces. IANA registers URN Namespace IDs (NIDs [RFC3406]), 777 and the organization registering an NID is responsible for 778 allocations of URNs within that namespace. 780 4.4. First Come First Served 782 For the First Come First Served policy, assignments are made to 783 anyone on a first come, first served basis. There is no substantive 784 review of the request, other than to ensure that it is well-formed 785 and doesn't duplicate an existing assignment. However, requests must 786 include a minimal amount of clerical information, such as a point of 787 contact (including an email address, and sometimes a postal address) 788 and a brief description of how the value will be used. Additional 789 information specific to the type of value requested may also need to 790 be provided, as defined by the namespace. For numbers, the exact 791 value is generally assigned by IANA; with names, specific text 792 strings can usually be requested. 794 When creating a new registry with First Come First Served as the 795 registration policy, in addition to the contact person field or 796 reference, the registry should contain a field for change controller. 797 Having a change controller for each entry for these types of 798 registrations makes authorization of future modifications more clear. 799 See Section 2.3. It is important that changes to the registration of 800 a First Come First Served code point retain compatibility with the 801 current usage of that code point, and so changes need to be made with 802 care. 804 It is also important to understand that First Come First Served 805 really has no filtering. Essentially, any well formed request is 806 accepted. 808 A working group or any other entity that is developing a protocol 809 based on a First Come First Served code point has to be extremely 810 careful that the protocol retains wire compatibility with current use 811 of the code point. Once that is no longer true, the new work needs 812 to change to a different code point (and register that use at the 813 appropriate time). 815 Examples: 817 SASL mechanism names [RFC4422] 818 LDAP Protocol Mechanisms and LDAP Syntax [RFC4520] 820 4.5. Expert Review 822 (Also called "Designated Expert" in earlier editions of this 823 document.) For the Expert Review policy, review and approval by a 824 designated expert (see Section 5) is required. 826 The required documentation and review criteria, giving clear guidance 827 to the designated expert, should be provided when defining the 828 registry. It is particularly important to lay out what should be 829 considered when performing an evaluation and reasons for rejecting a 830 request. It is also a good idea to include, when possible, a sense 831 of whether many registrations are expected over time, or if the 832 registry is expected to be updated infrequently or in exceptional 833 circumstances only. 835 Good examples of guidance to designated experts: 837 Extensible Authentication Protocol (EAP) [RFC3748], Sections 6 and 838 7.2 839 North-Bound Distribution of Link-State and TE Information using 840 BGP [RFC7752], Section 5.1 842 When creating a new registry with Expert Review as the registration 843 policy, in addition to the contact person field or reference, the 844 registry should contain a field for change controller. Having a 845 change controller for each entry for these types of registrations 846 makes authorization of future modifications more clear. See Section 847 2.3 849 Examples: 851 EAP Method Types [RFC3748] 852 HTTP Digest AKA algorithm versions [RFC4169] 853 URI schemes [RFC4395] 854 GEOPRIV Location Types [RFC4589] 856 4.6. Specification Required 858 For the Specification Required policy, review and approval by a 859 designated expert (see Section 5) is required, and the values and 860 their meanings must be documented in a permanent and readily 861 available public specification, in sufficient detail so that 862 interoperability between independent implementations is possible. 863 The designated expert will review the public specification and 864 evaluate whether it is sufficiently stable and permanent, and 865 sufficiently clear to allow interoperable implementations. 867 The intention behind "permanent and readily available" is that a 868 document can reasonably be expected to be findable and retrievable 869 long after IANA assignment of the requested value. Publication of an 870 RFC is an ideal means of achieving this requirement, but 871 Specification Required is intended to also cover the case of a 872 document published outside of the RFC path, including informal 873 documentation. 875 For RFC publication, formal review by the designated expert is still 876 requested, but the normal RFC review process is expected to provide 877 the necessary review for interoperability. The designated expert's 878 review is still important, but it's equally important to note that 879 when there is IETF consensus, the expert can sometimes be "in the 880 rough" (see also the last paragraph of Section 5.4). 882 As with Expert Review (Section 4.5), clear guidance to the designated 883 expert, should be provided when defining the registry. 885 When specifying this policy, just use the term "Specification 886 Required". Some specifications have chosen to refer to it as "Expert 887 Review with Specification Required", and that only causes confusion. 889 Examples: 891 Diffserv-aware TE Bandwidth Constraints Model Identifiers 892 [RFC4124] 893 TLS ClientCertificateType Identifiers 64-223 [RFC5246] 894 ROHC Profile Identifiers [RFC5795] 896 4.7. RFC Required 898 With the RFC Required policy, the registration request, along with 899 associated documentation, must be published in an RFC. The RFC need 900 not be in the IETF stream, but may be in any RFC stream (currently an 901 RFC may be in the IETF, IRTF, or IAB stream, or an RFC Editor 902 Independent Submission [RFC5742]). 904 Unless otherwise specified, any type of RFC is sufficient (currently 905 Standards Track, BCP, Informational, Experimental, or Historic). 907 4.8. IETF Review 909 (Formerly called "IETF Consensus" in the first edition of this 910 document.) With the IETF Review policy, new values are assigned only 911 through RFCs in the IETF Stream -- those that have been shepherded 912 through the IESG as AD-Sponsored or IETF working group Documents 913 [RFC2026] [RFC5378], have gone through IETF last call, and that the 914 IESG has approved as having IETF consensus. 916 The intent is that the document and proposed assignment will be 917 reviewed by the IETF community (including appropriate IETF working 918 groups, directorates, and other experts) and by the IESG, to ensure 919 that the proposed assignment will not negatively affect 920 interoperability or otherwise extend IETF protocols in an 921 inappropriate or damaging manner. To ensure adequate community 922 review, such documents will always undergo an IETF Last Call. 924 Unless otherwise specified, any type of RFC is sufficient (currently 925 Standards Track, BCP, Informational, Experimental, or Historic). 927 Examples: 929 IPSECKEY Algorithm Types [RFC4025] 930 Accounting-Auth-Method AVP values in DIAMETER [RFC4005] 931 TLS Extension Types [RFC5246] 933 4.9. Standards Action 935 For the Standards Action policy, values are assigned only through 936 Standards Track or Best Current Practice RFCs in the IETF Stream. 938 Examples: 940 BGP message types [RFC4271] 941 Mobile Node Identifier option types [RFC4283] 942 TLS ClientCertificateType Identifiers 0-63 [RFC5246] 943 DCCP Packet Types [RFC4340] 945 4.10. IESG Approval 947 New assignments may be approved by the IESG. Although there is no 948 requirement that the request be documented in an RFC, the IESG has 949 discretion to request documents or other supporting materials on a 950 case-by-case basis. 952 IESG Approval is not intended to be used often or as a "common case"; 953 indeed, it has seldom been used in practice. Rather, it is intended 954 to be available in conjunction with other policies as a fall-back 955 mechanism in the case where one of the other allowable approval 956 mechanisms cannot be employed in a timely fashion or for some other 957 compelling reason. IESG Approval is not intended to circumvent the 958 public review processes implied by other policies that could have 959 been employed for a particular assignment. IESG Approval would be 960 appropriate, however, in cases where expediency is desired and there 961 is strong consensus (such as from a working group) for making the 962 assignment. 964 Before approving a request, the IESG might consider consulting the 965 community, via a "call for comments" that provides as much 966 information as is reasonably possible about the request. 968 Examples: 970 IPv4 Multicast address assignments [RFC5771] 971 IPv4 IGMP Type and Code values [RFC3228] 972 Mobile IPv6 Mobility Header Type and Option values [RFC6275] 974 4.11. Using the Well-Known Registration Policies 976 Because the well-known policies benefit from both community 977 experience and wide understanding, their use is encouraged, and the 978 making up of new policies needs to be accompanied by reasonable 979 justification. 981 It is also acceptable to cite one of the well-known policies and 982 include additional guidelines for what kind of considerations should 983 be taken into account by the review process. 985 For example, RADIUS [RFC3575] specifies the use of a Designated 986 Expert, but includes specific additional criteria the Designated 987 Expert should follow. 989 The well-known policies from "First Come First Served" to "Standards 990 Action" specify a range of policies in increasing order of strictness 991 (using the numbering from the full list in Section 4): 993 4. First Come First Served 994 No review, minimal documentation. 996 5/6. Expert Review / Specification Required 997 Expert review with sufficient documentation for review. / 998 Significant stable public documentation sufficient for 999 interoperability. 1001 7. RFC Required 1002 Any RFC publication, IETF or a non-IETF Stream. 1004 8. IETF Review 1005 RFC publication, IETF Stream only, but need not be Standards 1006 Track. 1008 9. Standards Action 1009 RFC publication, IETF Stream, Standards Track only. 1011 Examples of situations that might merit IETF Review or Standards 1012 Action include the following: 1014 o When a resource is limited, such as bits in a byte (or in two 1015 bytes, or four), or numbers in a limited range. In these cases, 1016 allowing registrations that haven't been carefully reviewed and 1017 agreed by community consensus could too quickly deplete the 1018 allowable values. 1020 o When thorough community review is necessary to avoid extending or 1021 modifying the protocol in ways that could be damaging. One 1022 example is in defining new command codes, as opposed to options 1023 that use existing command codes: the former might require a strict 1024 policy, where a more relaxed policy could be adequate for the 1025 latter. Another example is in defining protocol elements that 1026 change the semantics of existing operations. 1028 When reviewing a document that asks IANA to create a new registry or 1029 change a registration policy to any policy more stringent than Expert 1030 Review or Specification Required, the IESG should ask for 1031 justification to ensure that more relaxed policies have been 1032 considered and that the strict policy is the right one. 1034 Accordingly, document developers need to anticipate this and document 1035 their considerations for selecting the specified policy (ideally, in 1036 the document itself; failing that, in the shepherd writeup). 1037 Likewise, the document shepherd should ensure that the selected 1038 policies have been justified before sending the document to the IESG. 1040 When specifications are revised, registration policies should be 1041 reviewed in light of experience since the policies were set. 1043 4.12. Using Multiple Policies in Combination 1045 In some situations, it is necessary to define multiple registration 1046 policies. For example, registrations through the normal IETF process 1047 might use one policy, while registrations from outside the process 1048 would have a different policy applied. 1050 Thus, a particular registry might want to use a policy such as "RFC 1051 Required" or "IETF Review" sometimes, with a designated expert 1052 checking a "Specification Required" policy at other times. 1054 The alternative to using a combination requires either that all 1055 requests come through RFCs or that requests in RFCs go through review 1056 by the designated expert, even though they already have IETF review 1057 and consensus. 1059 This can be documented in the IANA Considerations section when the 1060 registry is created: 1062 IANA is asked to create the registry "Fruit Access Flags" under 1063 the "Fruit Parameters" group. New registrations will be permitted 1064 through either the IETF Review policy or the Specification 1065 Required policy [BCP26]. The latter should be used only for 1066 registrations requested by SDOs outside the IETF. Registrations 1067 requested in IETF documents will be subject to IETF review. 1069 Such combinations will commonly use one of {Standards Action, IETF 1070 Review, RFC Required} in combination with one of {Specification 1071 Required, Expert Review}. Guidance should be provided about when 1072 each policy is appropriate, as in the example above. 1074 5. Designated Experts 1076 5.1. The Motivation for Designated Experts 1078 Discussion on a mailing list can provide valuable technical feedback, 1079 but opinions often vary and discussions may continue for some time 1080 without clear resolution. In addition, IANA cannot participate in 1081 all of these mailing lists and cannot determine if or when such 1082 discussions reach consensus. Therefore, IANA relies on a "designated 1083 expert" for advice regarding the specific question of whether an 1084 assignment should be made. The designated expert is an individual 1085 who is responsible for carrying out an appropriate evaluation and 1086 returning a recommendation to IANA. 1088 It should be noted that a key motivation for having designated 1089 experts is for the IETF to provide IANA with a subject matter expert 1090 to whom the evaluation process can be delegated. IANA forwards 1091 requests for an assignment to the expert for evaluation, and the 1092 expert (after performing the evaluation) informs IANA as to whether 1093 or not to make the assignment or registration. In most cases, the 1094 registrants do not work directly with the designated experts. The 1095 list of designated experts for a registry is listed in the registry. 1097 It will often be useful to use a designated expert only some of the 1098 time, as a supplement to other processes. For more discussion of 1099 that topic, see Section 4.12. 1101 5.2. The Role of the Designated Expert 1102 The designated expert is responsible for coordinating the appropriate 1103 review of an assignment request. The review may be wide or narrow, 1104 depending on the situation and the judgment of the designated expert. 1105 This may involve consultation with a set of technology experts, 1106 discussion on a public mailing list, consultation with a working 1107 group (or its mailing list if the working group has disbanded), etc. 1108 Ideally, the designated expert follows specific review criteria as 1109 documented with the protocol that creates or uses the namespace. See 1110 the IANA Considerations sections of [RFC3748] and [RFC3575] for 1111 specific examples. 1113 Designated experts are expected to be able to defend their decisions 1114 to the IETF community, and the evaluation process is not intended to 1115 be secretive or bestow unquestioned power on the expert. Experts are 1116 expected to apply applicable documented review or vetting procedures, 1117 or in the absence of documented criteria, follow generally accepted 1118 norms such as those in Section 5.3. 1120 It has proven useful to have multiple designated experts for some 1121 registries. Sometimes those experts work together in evaluating a 1122 request, while in other cases additional experts serve as backups, 1123 acting only when the primary expert is unavailable. In registries 1124 with a pool of experts, the pool often has a single chair responsible 1125 for defining how requests are to be assigned to and reviewed by 1126 experts. In other cases, IANA might assign requests to individual 1127 members in sequential or approximate random order. 1129 In cases of disagreement among multiple experts, it is the 1130 responsibility of those experts to make a single clear recommendation 1131 to IANA. It is not appropriate for IANA to resolve disputes among 1132 experts. In extreme situations, such as deadlock, the designating 1133 body may need to step in to resolve the problem. 1135 If a designated expert is conflicted for a particular review (is, for 1136 example, an author or significant proponent of a specification 1137 related to the registration under review), that expert should recuse 1138 himself. In the event that all the designated experts are 1139 conflicted, they should ask that a temporary expert be designated for 1140 the conflicted review. 1142 This document defines the designated expert mechanism with respect to 1143 documents in the IETF stream only. Documents in other streams may 1144 use a registration policy that requires a designated expert only if 1145 those streams (or those documents) specify how designated experts are 1146 appointed and managed. What is described below, with management by 1147 the IESG, is only appropriate for the IETF stream. 1149 5.2.1. Managing Designated Experts in the IETF 1150 Designated experts for registries created by the IETF are appointed 1151 by the IESG, normally upon recommendation by the relevant Area 1152 Director. They may be appointed at the time a document creating or 1153 updating a namespace is approved by the IESG, or subsequently, when 1154 the first registration request is received. Because experts 1155 originally appointed may later become unavailable, the IESG will 1156 appoint replacements as necessary. The IESG may remove any 1157 designated expert that it appointed, at its discretion. 1159 The normal appeals process, as described in [RFC2026], Section 6.5.1, 1160 applies to issues that arise with the designated expert team. For 1161 this purpose, the designated expert team takes the place of the 1162 working group in that description. 1164 5.3. Designated Expert Reviews 1166 In the years since RFC 2434 was published and has been put to use, 1167 experience has led to the following observations: 1169 o A designated expert must respond in a timely fashion, normally 1170 within a week for simple requests to a few weeks for more complex 1171 ones. Unreasonable delays can cause significant problems for 1172 those needing assignments, such as when products need code points 1173 to ship. This is not to say that all reviews can be completed 1174 under a firm deadline, but they must be started, and the requester 1175 and IANA should have some transparency into the process if an 1176 answer cannot be given quickly. 1178 o If a designated expert does not respond to IANA's requests within 1179 a reasonable period of time, either with a response or with a 1180 reasonable explanation for the delay (some requests may be 1181 particularly complex), and if this is a recurring event, IANA must 1182 raise the issue with the IESG. Because of the problems caused by 1183 delayed evaluations and assignments, the IESG should take 1184 appropriate actions to ensure that the expert understands and 1185 accepts his or her responsibilities, or appoint a new expert. 1187 o The designated expert is not required to personally bear the 1188 burden of evaluating and deciding all requests, but acts as a 1189 shepherd for the request, enlisting the help of others as 1190 appropriate. In the case that a request is denied, and rejecting 1191 the request is likely to be controversial, the expert should have 1192 the support of other subject matter experts. That is, the expert 1193 must be able to defend a decision to the community as a whole. 1195 When a designated expert is used, the documentation should give clear 1196 guidance to the designated expert, laying out criteria for performing 1197 an evaluation and reasons for rejecting a request. In the case where 1198 there are no specific documented criteria, the presumption should be 1199 that a code point should be granted unless there is a compelling 1200 reason to the contrary. Reasons that have been used to deny requests 1201 have included these: 1203 o Scarcity of code points, where the finite remaining code points 1204 should be prudently managed, or where a request for a large number 1205 of code points is made and a single code point is the norm. 1207 o Documentation is not of sufficient clarity to evaluate or ensure 1208 interoperability. 1210 o The code point is needed for a protocol extension, but the 1211 extension is not consistent with the documented (or generally 1212 understood) architecture of the base protocol being extended, and 1213 would be harmful to the protocol if widely deployed. It is not 1214 the intent that "inconsistencies" refer to minor differences "of a 1215 personal preference nature". Instead, they refer to significant 1216 differences such as inconsistencies with the underlying security 1217 model, implying a change to the semantics of an existing message 1218 type or operation, requiring unwarranted changes in deployed 1219 systems (compared with alternate ways of achieving a similar 1220 result), etc. 1222 o The extension would cause problems with existing deployed systems. 1224 o The extension would conflict with one under active development by 1225 the IETF, and having both would harm rather than foster 1226 interoperability. 1228 When a designated expert is used, documents must not name the 1229 designated expert in the document itself; instead, any suggested 1230 names should be relayed to the appropriate Area Director at the time 1231 the document is sent to the IESG for approval. This is usually done 1232 in the document shepherd writeup. 1234 If the request should also be reviewed on a specific public mailing 1235 list, its address should be specified. 1237 5.4. Expert Reviews and the Document Lifecycle 1239 Review by the designated expert is necessarily done at a particular 1240 point in time, and represents review of a particular version of the 1241 document. While reviews are generally done around the time of IETF 1242 last call, deciding when the review should take place is a question 1243 of good judgment. And while re-reviews might be done when it's 1244 acknowledged that the documentation of the registered item has 1245 changed substantially, making sure that re-review happens requires 1246 attention and care. 1248 It is possible, through carelessness, accident, inattentiveness, or 1249 even willful disregard, that changes might be made after the 1250 designated expert's review and approval that would, if the document 1251 were re-reviewed, cause the expert not to approve the registration. 1252 It is up to the IESG, with the token held by the responsible Area 1253 Director, to be alert to such situations and to recognize that such 1254 changes need to be checked. 1256 For registrations made from documents on the Standards Track, there 1257 is often expert review required (by the registration policy) in 1258 addition to IETF consensus (for approval as a Standards Track RFC). 1259 In such cases, the review by the designated expert needs to be 1260 timely, submitted before the IESG evaluates the document. The IESG 1261 should generally not hold the document up waiting for late review. 1262 It is also not intended for the expert review to override IETF 1263 consensus: the IESG should consider the review in its own evaluation, 1264 as it would do for other last-call reviews. 1266 6. Well-Known Registration Status Terminology 1268 The following labels describe the status of an assignment or range of 1269 assignments: 1271 Private Use: Private use only (not assigned), as described in 1272 Section 4.1. 1274 Experimental: Available for general experimental use as described 1275 in [RFC3692]. IANA does not record specific assignments for 1276 any particular use. 1278 Unassigned: Not currently assigned, and available for assignment 1279 via documented procedures. While it's generally clear that 1280 any values that are not registered are unassigned and 1281 available for assignment, it is sometimes useful to 1282 explicitly specify that situation. Note that this is 1283 distinctly different from "Reserved". 1285 Reserved: Not assigned and not available for assignment. Reserved 1286 values are held for special uses, such as to extend the 1287 namespace when it becomes exhausted. "Reserved" is also 1288 sometimes used to designate values that had been assigned 1289 but are no longer in use, keeping them set aside as long as 1290 other unassigned values are available. Note that this is 1291 distinctly different from "Unassigned". 1293 Reserved values can be released for assignment by the change 1294 controller for the registry (this is often the IESG, for 1295 registries created by RFCs in the IETF stream). 1297 7. Documentation References in IANA Registries 1299 Usually, registries and registry entries include references to 1300 documentation (RFCs or other documents). The purpose of these 1301 references is to provide pointers for implementors to find details 1302 necessary for implementation, NOT to simply note what document 1303 created the registry or entry. Therefore: 1305 o If a document registers an item that is defined and explained 1306 elsewhere, the registered reference should be to the document 1307 containing the definition, not to the document that is merely 1308 performing the registration. 1310 o If the registered item is defined and explained in the current 1311 document, it is important to include sufficient information to 1312 enable implementors to understand the item and to create a proper 1313 implementation. 1315 o If the registered item is explained primarily in a specific 1316 section of the reference document, it is useful to include a 1317 section reference. For example, "[RFC4637], Section 3.2", rather 1318 than just "[RFC4637]". 1320 o For documentation of a new registry, the reference should provide 1321 information about the registry itself, not just a pointer to the 1322 creation of it. Useful information includes the purpose of the 1323 registry, a rationale for its creation, documentation of the 1324 process and policy for new registrations, guidelines for new 1325 registrants or designated experts, and other such related 1326 information. But note that, while it's important to include this 1327 information in the document, it needn't all be in the IANA 1328 Considerations section. See Section 1.1. 1330 8. What to Do in "bis" Documents 1332 On occasion, an RFC is issued that obsoletes a previous edition of 1333 the same document. We sometimes call these "bis" documents, such as 1334 when RFC 4637 is obsoleted by draft-ietf-foo-rfc4637bis. When the 1335 original document created registries and/or registered entries, there 1336 is a question of how to handle the IANA Considerations section in the 1337 "bis" document. 1339 If the registrations specify the original document as a reference, 1340 those registrations should be updated to point to the current (not 1341 obsolete) documentation for those items. Usually, that will mean 1342 changing the reference to be the "bis" document. 1344 There will, though, be times when a document updates another, but 1345 does not make it obsolete, and the definitive reference is changed 1346 for some items but not for others. Be sure that the references are 1347 always set to point to the correct, current documentation for each 1348 item. 1350 For example, suppose RFC 4637 registered the "BANANA" flag in the 1351 "Fruit Access Flags" registry, and the documentation for that flag is 1352 in Section 3.2. 1354 The current registry might look, in part, like this: 1356 Name Description Reference 1357 -------- ------------------- --------- 1358 BANANA Flag for bananas [RFC4637], Section 3.2 1360 If draft-ietf-foo-rfc4637bis obsoletes RFC 4637 and, because of some 1361 rearrangement, now documents the flag in Section 4.1.2, the IANA 1362 Considerations of the bis document might contain text such as this: 1364 IANA is asked to change the registration information for the 1365 BANANA flag in the "Fruit Access Flags" registry to the following: 1367 Name Description Reference 1368 -------- ------------------- --------- 1369 BANANA Flag for bananas [[this RFC]], Section 4.2.1 1371 In many cases, if there are a number of registered references to the 1372 original RFC and the document organization has not changed the 1373 registered section numbering much, it may simply be reasonable to do 1374 this: 1376 Because this document obsoletes RFC 4637, IANA is asked to change 1377 all registration information that references [RFC4637] to instead 1378 reference [[this RFC]]. 1380 If information for registered items has been or is being moved to 1381 other documents, then, of course, the registration information should 1382 be changed to point to those other documents. In no case is it 1383 reasonable to leave documentation pointers to the obsoleted document 1384 for any registries or registered items that are still in current use. 1386 It is extremely important to be clear in your instructions regarding 1387 updating references, especially in cases where some references need 1388 to be updated and others do not. 1390 9. Miscellaneous Issues 1392 9.1. When There Are No IANA Actions 1393 Before an Internet-Draft can be published as an RFC, IANA needs to 1394 know what actions (if any) it needs to perform. Experience has shown 1395 that it is not always immediately obvious whether a document has no 1396 IANA actions, without reviewing the document in some detail. In 1397 order to make it clear to IANA that it has no actions to perform (and 1398 that the author has consciously made such a determination), such 1399 documents should, after the authors confirm that this is the case, 1400 include an IANA Considerations section that states: 1402 This document has no IANA actions. 1404 IANA prefers that these "empty" IANA Considerations sections be left 1405 in the document for the record: it makes it clear later on that the 1406 document explicitly said that no IANA actions were needed (and that 1407 it wasn't just omitted). This is a change from the prior practice of 1408 requesting that such sections be removed by the RFC Editor, and 1409 authors are asked to accommodate this change. 1411 9.2. Namespaces Lacking Documented Guidance 1413 For all existing RFCs that either explicitly or implicitly rely on 1414 IANA to make assignments without specifying a precise assignment 1415 policy, IANA (in consultation with the IESG) will continue to decide 1416 what policy is appropriate. Changes to existing policies can always 1417 be initiated through the normal IETF consensus process, or through 1418 the IESG when appropriate. 1420 All future RFCs that either explicitly or implicitly rely on IANA to 1421 register or otherwise administer namespace assignments must provide 1422 guidelines for administration of the namespace. 1424 9.3. After-the-Fact Registrations 1426 Occasionally, the IETF becomes aware that an unassigned value from a 1427 namespace is in use on the Internet or that an assigned value is 1428 being used for a different purpose than it was registered for. The 1429 IETF does not condone such misuse; procedures of the type described 1430 in this document need to be applied to such cases. In the absence of 1431 specifications to the contrary, values may only be reassigned for a 1432 different purpose with the consent of the original assignee (when 1433 possible) and with due consideration of the impact of such a 1434 reassignment. In cases of likely controversy, consultation with the 1435 IESG is advised. 1437 9.4. Reclaiming Assigned Values 1438 Reclaiming previously assigned values for reuse is tricky, because 1439 doing so can lead to interoperability problems with deployed systems 1440 still using the assigned values. Moreover, it can be extremely 1441 difficult to determine the extent of deployment of systems making use 1442 of a particular value. However, in cases where the namespace is 1443 running out of unassigned values and additional ones are needed, it 1444 may be desirable to attempt to reclaim unused values. When 1445 reclaiming unused values, the following (at a minimum) should be 1446 considered: 1448 o Attempts should be made to contact the original party to which a 1449 value is assigned, to determine if the value was ever used, and if 1450 so, the extent of deployment. (In some cases, products were never 1451 shipped or have long ceased being used. In other cases, it may be 1452 known that a value was never actually used at all.) 1454 o Reassignments should not normally be made without the concurrence 1455 of the original requester. Reclamation under such conditions 1456 should only take place where there is strong evidence that a value 1457 is not widely used, and the need to reclaim the value outweighs 1458 the cost of a hostile reclamation. In any case, IESG Approval is 1459 needed in this case. 1461 o It may be appropriate to write up the proposed action and solicit 1462 comments from relevant user communities. In some cases, it may be 1463 appropriate to write an RFC that goes through a formal IETF 1464 process (including IETF Last Call) as was done when DHCP reclaimed 1465 some of its "Private Use" options [RFC3942]. 1467 9.5. Contact Person vs Assignee or Owner 1469 Many registries include designation of a technical or administrative 1470 contact associated with each entry. Often, this is recorded as 1471 contact information for an individual. It is unclear, though, what 1472 role the individual has with respect to the registration: is this 1473 item registered on behalf of the individual, the company the 1474 individual worked for, or perhaps another organization the individual 1475 was acting for? 1477 This matters because some time later, when the individual has changed 1478 jobs or roles, and perhaps can no longer be contacted, someone might 1479 want to update the registration. IANA has no way to know what 1480 company, organization, or individual should be allowed to take the 1481 registration over. For registrations rooted in RFCs, the stream 1482 owner (such as the IESG or the IAB) can make an overriding decision. 1483 But in other cases, there is no recourse. 1485 Registries can include, in addition to a "Contact" field, an 1486 "Assignee" or "Owner" field that can be used to address this 1487 situation, giving IANA clear guidance as to the actual owner of the 1488 registration. This is strongly advised especially for registries 1489 that do not require RFCs to manage their information (registries with 1490 policies such as First Come First Served Section 4.4, Expert Review 1491 Section 4.5, and Specification Required Section 4.6). Alternatively, 1492 organizations can put an organizational role into the "Contact" field 1493 in order to make their ownership clear. 1495 9.6. Closing or Obsoleting a Registry/Registrations 1497 Sometimes there is a request to "close" a registry to further 1498 registrations. When a registry is closed, no further registrations 1499 will be accepted. The information in the registry will still be 1500 valid and registrations already in the registry can still be updated. 1502 A closed registry can also be marked as "obsolete", as an indication 1503 that the information in the registry is no longer in current use. 1505 Specific entries in a registry can be marked as "obsolete" (no longer 1506 in use) or "deprecated" (use is not recommended). 1508 Such changes to registries and registered values are subject to 1509 normal change controls (see Section 2.3). Any closure, obsolescence, 1510 or deprecation serves to annotate the registry involved; the 1511 information in the registry remains there for informational and 1512 historic purposes. 1514 10. Appeals 1516 Appeals of protocol parameter registration decisions can be made 1517 using the normal IETF appeals process as described in [RFC2026], 1518 Section 6.5. That is, an initial appeal should be directed to the 1519 IESG, followed (if necessary) by an appeal to the IAB. 1521 11. Mailing Lists 1523 All IETF mailing lists associated with evaluating or discussing 1524 assignment requests as described in this document are subject to 1525 whatever rules of conduct and methods of list management are 1526 currently defined by Best Current Practices or by IESG decision. 1528 12. Security Considerations 1530 Information that creates or updates a registration needs to be 1531 authenticated and authorized. IANA updates registries according to 1532 instructions in published RFCs and from the IESG. It also may accept 1533 clarifications from document authors, relevant working group chairs, 1534 Designated Experts, and mail list participants, too. 1536 Information concerning possible security vulnerabilities of a 1537 protocol may change over time. Likewise, security vulnerabilities 1538 related to how an assigned number is used may change as well. As new 1539 vulnerabilities are discovered, information about such 1540 vulnerabilities may need to be attached to existing registrations, so 1541 that users are not misled as to the true security issues surrounding 1542 the use of a registered number. 1544 Security needs to be considered as part of the selection of a 1545 registration policy. For some protocols, registration of certain 1546 parameters will have security implications, and registration policies 1547 for the relevant registries must ensure that requests get appropriate 1548 review with those security implications in mind. 1550 An analysis of security issues is generally required for all 1551 protocols that make use of parameters (data types, operation codes, 1552 keywords, etc.) used in IETF protocols or registered by IANA. Such 1553 security considerations are usually included in the protocol document 1554 [RFC3552]. It is the responsibility of the IANA considerations 1555 associated with a particular registry to specify whether value- 1556 specific security considerations must be provided when assigning new 1557 values, and the process for reviewing such claims. 1559 13. IANA Considerations 1561 IANA is asked to update any references to RFC 5226 to now point to 1562 this document. 1564 14. Changes Relative to Earlier Editions of BCP 26 1566 14.1. 2016: Changes in This Document Relative to RFC 5226 1568 Significant additions: 1570 o Removed RFC 2119 key words, boilerplate, and reference, preferring 1571 plain English -- this is not a protocol specification. 1573 o Added Section 1.1, Keep IANA Considerations for IANA 1575 o Added Section 1.2, For More Information 1577 o Added Section 2.1, Hierarchical Registry Structure 1579 o Added best practice for selecting an appropriate policy into 1580 Section 4. 1582 o Added Section 4.12, Using Multiple Policies in Combination. 1584 o Added Section 2.3, Specifying Change Control for a Registry 1586 o Added Section 3.4, Early Allocations 1587 o Moved well-known policies into a separate section for each, 1588 subsections of Section 4. 1590 o Added Section 5.4, Expert Reviews and the Document Lifecycle 1592 o Added Section 7, Documentation References in IANA Registries 1594 o Added Section 8, What to Do in "bis" Documents 1596 o Added Section 9.5, Contact Person vs Assignee or Owner 1598 o Added Section 9.6, Closing or Obsoleting a Registry 1600 Clarifications and such: 1602 o Some reorganization -- moved text around for clarity and easier 1603 reading. 1605 o Made clarifications about identification of IANA registries and 1606 use of URLs for them. 1608 o Clarified the distinction between "Unassigned" and "Reserved". 1610 o Made some clarifications in "Expert Review" about instructions to 1611 the designated expert. 1613 o Made some clarifications in "Specification Required" about how to 1614 declare this policy. 1616 o Assorted minor clarifications and editorial changes throughout. 1618 14.2. 2008: Changes in RFC 5226 Relative to RFC 2434 1620 Changes include: 1622 o Major reordering of text to expand descriptions and to better 1623 group topics such as "updating registries" vs. "creating new 1624 registries", in order to make it easier for authors to find the 1625 text most applicable to their needs. 1627 o Numerous editorial changes to improve readability. 1629 o Changed the term "IETF Consensus" to "IETF Review" and added more 1630 clarifications. History has shown that people see the words "IETF 1631 Consensus" (without consulting the actual definition) and are 1632 quick to make incorrect assumptions about what the term means in 1633 the context of IANA Considerations. 1635 o Added "RFC Required" to list of defined policies. 1637 o Much more explicit directions and examples of "what to put in 1638 RFCs". 1640 o "Specification Required" now implies use of a Designated Expert to 1641 evaluate specs for sufficient clarity. 1643 o Significantly changed the wording in the Designated Experts 1644 section. Main purpose is to make clear that Expert Reviewers are 1645 accountable to the community, and to provide some guidance for 1646 review criteria in the default case. 1648 o Changed wording to remove any special appeals path. The normal 1649 RFC 2026 appeals path is used. 1651 o Added a section about reclaiming unused values. 1653 o Added a section on after-the-fact registrations. 1655 o Added a section indicating that mailing lists used to evaluate 1656 possible assignments (such as by a Designated Expert) are subject 1657 to normal IETF rules. 1659 15. Acknowledgments 1661 15.1. Acknowledgments for This Document (2016) 1663 Thomas Narten and Harald Tveit Alvestrand edited the two earlier 1664 editions of this document (RFCs 2434 and 5226), and Thomas continues 1665 his role in this third edition. Much of the text from RFC 5226 1666 remains in this edition. 1668 Thank you to Amanda Baber and Pearl Liang for their multiple reviews 1669 and suggestions for making this document as thorough as possible. 1671 This document has benefited from thorough review and comments by Tony 1672 Hansen, John Klensin, and Mark Nottingham. 1674 Special thanks to Mark Nottingham for reorganizing some of the text 1675 for better organization and readability, and to Tony Hansen for 1676 acting as document shepherd. 1678 15.2. Acknowledgments from the second edition (2008) 1680 The original acknowledgments section in RFC 5226 was: 1682 This document has benefited from specific feedback from Jari Arkko, 1683 Marcelo Bagnulo Braun, Brian Carpenter, Michelle Cotton, Spencer 1684 Dawkins, Barbara Denny, Miguel Garcia, Paul Hoffman, Russ Housley, 1685 John Klensin, Allison Mankin, Blake Ramsdell, Mark Townsley, Magnus 1686 Westerlund, and Bert Wijnen. 1688 15.3. Acknowledgments from the first edition (1998) 1690 The original acknowledgments section in RFC 2434 was: 1692 Jon Postel and Joyce Reynolds provided a detailed explanation on what 1693 IANA needs in order to manage assignments efficiently, and patiently 1694 provided comments on multiple versions of this document. Brian 1695 Carpenter provided helpful comments on earlier versions of the 1696 document. One paragraph in the Security Considerations section was 1697 borrowed from [RFC4288]. 1699 16. References 1701 16.1. Normative References 1703 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1704 3", BCP 9, RFC 2026, October 1996. 1706 16.2. Informative References 1708 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1709 1981. 1711 [RFC1591] Postel, J., "Domain Name System Structure and Delegation", 1712 RFC 1591, DOI 10.17487/RFC1591, March 1994, . 1715 [RFC2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of 1716 Understanding Concerning the Technical Work of the 1717 Internet Assigned Numbers Authority", RFC 2860, June 2000. 1719 [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition 1720 of New DHCP Options and Message Types", BCP 43, RFC 2939, 1721 September 2000. 1723 [RFC3228] Fenner, B., "IANA Considerations for IPv4 Internet Group 1724 Management Protocol (IGMP)", BCP 57, RFC 3228, February 1725 2002. 1727 [RFC3406] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, 1728 "Uniform Resource Names (URN) Namespace Definition 1729 Mechanisms", BCP 66, RFC 3406, DOI 10.17487/RFC3406, 1730 October 2002, . 1732 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1733 Text on Security Considerations", BCP 72, RFC 3552, July 1734 2003. 1736 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1737 Authentication Dial In User Service)", RFC 3575, July 1738 2003. 1740 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1741 Considered Useful", BCP 82, RFC 3692, January 2004. 1743 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 1744 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1745 3748, June 2004. 1747 [RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration 1748 Protocol version 4 (DHCPv4) Options", RFC 3942, November 1749 2004. 1751 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 1752 (IANA) Header Field Parameter Registry for the Session 1753 Initiation Protocol (SIP)", BCP 98, RFC 3968, December 1754 2004. 1756 [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 1757 Network Access Server Application", RFC 4005, August 2005. 1759 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 1760 Material in DNS", RFC 4025, March 2005. 1762 [RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, 1763 May 2005. 1765 [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of 1766 Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 1767 2005. 1769 [RFC4169] Torvinen, V., Arkko, J. and M. Naslund, "Hypertext 1770 Transfer Protocol (HTTP) Digest Authentication Using 1771 Authentication and Key Agreement (AKA) Version-2", RFC 1772 4169, November 2005. 1774 [RFC4271] Rekhter, Y., Li, T. and S. Hares, "A Border Gateway 1775 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1777 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H. and K. 1778 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 1779 (MIPv6)", RFC 4283, November 2005. 1781 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1782 Registration Procedures", BCP 13, RFC 4288, December 2005. 1784 [RFC4340] Kohler, E., Handley, M. and S. Floyd, "Datagram Congestion 1785 Control Protocol (DCCP)", RFC 4340, March 2006. 1787 [RFC4395] Hansen, T., Hardie, T. and L. Masinter, "Guidelines and 1788 Registration Procedures for New URI Schemes", BCP 35, RFC 1789 4395, February 2006. 1791 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1792 Security Layer (SASL)", RFC 4422, June 2006. 1794 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 1795 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 1797 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 1798 Considerations for the Lightweight Directory Access 1799 Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 1801 [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types 1802 Registry", RFC 4589, July 2006. 1804 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1805 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 1807 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1808 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1810 [RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide 1811 to the IETF Trust", BCP 78, RFC 5378, November 2008. 1813 [RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for 1814 Handling of Independent and IRTF Stream Submissions", BCP 1815 92, RFC 5742, December 2009. 1817 [RFC5771] Cotton, M., Vegoda, L. and D. Meyer, "IANA Guidelines for 1818 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 1819 March 2010. 1821 [RFC5795] Sandlund, K., Pelletier, G. and L-E. Jonsson, "The RObust 1822 Header Compression (ROHC) Framework", RFC 5795, March 1823 2010. 1825 [RFC6195] Eastlake, D., "Domain Name System (DNS) IANA 1826 Considerations", BCP 42, RFC 6195, March 2011. 1828 [RFC6275] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support 1829 in IPv6", RFC 6275, July 2011. 1831 [RFC6709] Carpenter, B., Aboba, B. and S. Cheshire, "Design 1832 Considerations for Protocol Extensions", RFC 6709, 1833 September 2012. 1835 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 1836 Points", BCP 100, RFC 7120, January 2014. 1838 [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: 1839 Preparation, Enforcement, and Comparison of 1840 Internationalized Strings in Application Protocols", RFC 1841 7564, DOI 10.17487/RFC7564, May 2015, . 1844 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A. and 1845 S. Ray, "North-Bound Distribution of Link-State and 1846 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1847 DOI 10.17487/RFC7752, March 2016, . 1850 Authors' Addresses 1852 Michelle Cotton 1853 Internet Corporation for Assigned Names and Numbers 1854 12025 Waterfront Drive, Suite 300 1855 Los Angeles, CA 90094-2536 1856 US 1858 Phone: +1 310 823 9358 1859 Email: michelle.cotton@icann.org 1860 URI: https://www.icann.org/ 1862 Barry Leiba 1863 Huawei Technologies 1865 Phone: +1 646 827 0648 1866 Email: barryleiba@computer.org 1867 URI: http://internetmessagingtechnology.org/ 1869 Thomas Narten 1870 IBM Corporation 1871 3039 Cornwallis Ave., PO Box 12195 - BRQA/502 1872 Research Triangle Park, NC 27709-2195 1873 US 1875 Phone: +1 919 254 7798 1876 Email: narten@us.ibm.com