idnits 2.17.00 (12 Aug 2021) /tmp/idnits49379/draft-narten-iana-considerations-rfc2434bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1073. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1034. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1041. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1047. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** Missing revision: the document name given in the document, 'draft-narten-iana-considerations-rfc2434bis', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-narten-iana-considerations-rfc2434bis', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-narten-iana-considerations-rfc2434bis', but the file name used is 'draft-narten-iana-considerations-rfc2434bis-05' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 15, 2006) is 5726 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DHCP' is mentioned on line 371, but not defined == Missing Reference: 'RFCXXX' is mentioned on line 546, but not defined == Missing Reference: 'RFC 1602' is mentioned on line 893, but not defined ** Obsolete undefined reference: RFC 1602 (Obsoleted by RFC 2026) == Unused Reference: 'DHCP-OPTIONS' is defined on line 928, but no explicit reference was found in the text == Unused Reference: 'MIME-LANG' is defined on line 955, but no explicit reference was found in the text == Unused Reference: 'RFC3968' is defined on line 1004, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1700 (ref. 'ASSIGNED') (Obsoleted by RFC 3232) -- Obsolete informational reference (is this intentional?): RFC 2283 (ref. 'BGP4-EXT') (Obsoleted by RFC 2858) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 1825 (ref. 'IPSEC') (Obsoleted by RFC 2401) -- Obsolete informational reference (is this intentional?): RFC 2184 (ref. 'MIME-LANG') (Obsoleted by RFC 2231) -- Obsolete informational reference (is this intentional?): RFC 2048 (ref. 'MIME-REG') (Obsoleted by RFC 4288, RFC 4289) -- Obsolete informational reference (is this intentional?): RFC 1869 (ref. 'SMTP-EXT') (Obsoleted by RFC 2821) == Outdated reference: draft-carpenter-protocol-extensions has been published as RFC 4775 -- Obsolete informational reference (is this intentional?): RFC 2929 (Obsoleted by RFC 5395) -- Obsolete informational reference (is this intentional?): RFC 3978 (Obsoleted by RFC 5378) -- Obsolete informational reference (is this intentional?): RFC 3932 (Obsoleted by RFC 5742) Summary: 6 errors (**), 1 flaw (~~), 11 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Thomas Narten 3 IBM 4 Harald Tveit Alvestrand 5 Google 6 September 15, 2006 8 Guidelines for Writing an IANA Considerations Section in RFCs 10 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft expires in six months. 37 Abstract 39 Many protocols make use of identifiers consisting of constants and 40 other well-known values. Even after a protocol has been defined and 41 deployment has begun, new values may need to be assigned (e.g., for a 42 new option type in DHCP, or a new encryption or authentication 43 transform for IPsec). To ensure that such quantities have consistent 44 values and interpretations in different implementations, their 45 assignment must be administered by a central authority. For IETF 46 protocols, that role is provided by the Internet Assigned Numbers 47 Authority (IANA). 49 In order for IANA to manage a given name space prudently, it needs 50 guidelines describing the conditions under which new values can be 51 assigned, or when modifications to existing values can be made. If 52 IANA is expected to play a role in the management of a name space, 53 the IANA must be given clear and concise instructions describing that 54 role. This document discusses issues that should be considered in 55 formulating a policy for assigning values to a name space and 56 provides guidelines to document authors on the specific text that 57 must be included in documents that place demands on IANA. 59 Contents 61 Status of this Memo.......................................... 1 63 1. Introduction............................................. 4 65 2. Why Management of a Name Space May be Necessary.......... 5 67 3. Designated Experts....................................... 5 68 3.1. The Motivation For Designated Experts............... 6 69 3.2. The Role of the Designated Expert................... 7 70 3.3. Designated Expert Reviews........................... 7 72 4. Creating A Registry...................................... 9 73 4.1. Well-Known IANA Policy Definitions.................. 9 74 4.2. What To Put In Documents That Create A Registry..... 12 75 4.3. Updating IANA Guidelines For Existing Registries.... 13 77 5. Registering New Values In An Existing Registry........... 14 78 5.1. What to Put In Documents When Registering Values.... 14 79 5.2. Updating Registrations.............................. 15 80 5.3. Overriding Registration Procedures.................. 15 82 6. Miscellaneous Issues..................................... 16 83 6.1. When There Are No IANA Actions...................... 16 84 6.2. Appeals............................................. 17 85 6.3. Namespaces Lacking Documented Guidance.............. 17 86 6.4. After-The-Fact Registrations........................ 17 87 6.5. Reclaiming Assigned Values.......................... 18 89 7. Mailing Lists............................................ 18 91 8. Security Considerations.................................. 19 93 9. Open Issues.............................................. 19 95 10. Changes Relative to RFC 2434............................ 19 96 10.1. Changes Relative to -00............................ 20 97 10.2. Changes Relative to -02............................ 20 99 11. IANA Considerations..................................... 21 101 12. Acknowledgments......................................... 21 103 13. Normative References.................................... 21 105 14. Informative References.................................. 21 106 15. Authors' Addresses...................................... 23 108 1. Introduction 110 Many protocols make use of fields that contain constants and other 111 well-known values (e.g., the Protocol field in the IP header [IP] or 112 MIME types in mail messages [MIME-REG]). Even after a protocol has 113 been defined and deployment has begun, new values may need to be 114 assigned (e.g., a new option type in DHCP [DHCP] or a new encryption 115 or authentication transform for IPsec [IPSEC]). To ensure that such 116 fields have consistent values and interpretations in different 117 implementations, their assignment must be administered by a central 118 authority. For IETF protocols, that role is provided by the Internet 119 Assigned Numbers Authority (IANA) [IANA-MOU]. 121 In this document, we call the set of possible values for such a field 122 a "name space"; its actual value may be a text string, a number or 123 another kind of value. The binding or association of a specific value 124 with a particular purpose within a name space is called an assigned 125 number (or assigned value, or sometimes a "code point" or "protocol 126 constant"). Each assignment of a value in a name space is called a 127 registration. 129 In order for IANA to manage a given name space prudently, it needs 130 guidelines describing the conditions under which new values should be 131 assigned, or when (and how) modifications to existing values can be 132 made. This document provides guidelines to authors on what sort of 133 text should be added to their documents in order to provide IANA 134 clear guidelines and reviews issues that should be considered in 135 formulating an appropriate policy for assigning numbers to name 136 spaces. 138 Not all name spaces require centralized administration. In some 139 cases, it is possible to delegate a name space in such a way that 140 further assignments can be made independently and with no further 141 (central) coordination. In the Domain Name System, for example, the 142 IANA only deals with assignments at the higher-levels, while 143 subdomains are administered by the organization to which the space 144 has been delegated. As another example, Object Identifiers (OIDs) as 145 defined by the ITU are also delegated [ASSIGNED]; IANA manages the 146 subtree rooted at "iso.org.dod.internet" (1.3.6.1) . When a name 147 space is delegated, the scope of IANA is limited to the parts of the 148 namespace where IANA has authority. 150 This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their 151 negatives, in the way described in RFC 2119 [KEYWORDS]. In this case, 152 "the specification" as used by RFC 2119 refers to the processing of 153 protocol documents within the IETF standards process. 155 2. Why Management of a Name Space May be Necessary 157 One issue to consider in managing a name space is its size. If the 158 space is small and limited in size, assignments must be made 159 carefully to prevent exhaustion of the space. If the space is 160 essentially unlimited, on the other hand, potential exhaustion will 161 probably not be a practical concern at all. Even when the space is 162 essentially unlimited, however, it is usually desirable to have at 163 least a minimal review prior to assignment in order to: 165 - prevent the hoarding of or unnecessary wasting of values. For 166 example, if the space consists of text strings, it may be 167 desirable to prevent entities from obtaining large sets of strings 168 that correspond to desirable names (e.g., existing company names). 170 - provide a sanity check that the request actually makes sense and 171 is necessary. Experience has shown that some level of minimal 172 review from a subject matter expert is useful to prevent 173 assignments in cases where the request is malformed or not 174 actually needed (i.e., an existing assignment for an essentially 175 equivalent service already exists). 177 A second consideration is whether it makes sense to delegate the name 178 space in some manner. This route should be pursued when appropriate, 179 as it lessens the burden on IANA for dealing with assignments. 181 A third, and perhaps most important consideration, concerns potential 182 impact on interoperability of unreviewed extensions. Proposed 183 protocol extensions generally benefit from community review; indeed, 184 review is often essential to avoid future interoperability problems 185 [PROTOCOL-EXT]. 187 In some cases, the name space is essentially unlimited and there are 188 no potential interoperability issues; in such cases assigned numbers 189 can safely be given out to anyone. When no subjective review is 190 needed, IANA can make assignments directly, provided that IANA is 191 given specific instructions on what types of requests it should 192 grant, and what information must be provided as part of a well-formed 193 request for an assigned number. 195 3. Designated Experts 196 3.1. The Motivation For Designated Experts 198 It should be noted that IANA does not create or define assignment 199 policy itself; rather, it carries out policies that have been defined 200 by others, i.e., in RFCs. IANA must be given a set of guidelines 201 that allow it to make allocation decisions with minimal subjectivity 202 and without requiring any technical expertise with respect to the 203 protocols that make use of a registry. 205 In most cases, some review of prospective allocations is appropriate, 206 and the question becomes who should perform the review and what is 207 the purpose of the review. In many cases, one might think that an 208 IETF Working Group (WG) familiar with the name space at hand should 209 be consulted. In practice, however, WGs eventually disband, so they 210 cannot be considered a permanent evaluator. It is also possible for 211 name spaces to be created through individual submission documents, 212 for which no WG is ever formed. 214 One way to ensure community review of prospective assignments is to 215 have the requester submit a document for publication as an RFC. Such 216 an action helps ensure that the specification is publicly and 217 permanently available, and allows some review of the specification 218 prior to publication and assignment of the requested code points. 219 This is the preferred way of ensuring review, and is particularly 220 important if any potential interoperability issues can arise. For 221 example, some assignments are not just assignments, but also involve 222 an element of protocol specification. A new option may define fields 223 that need to be parsed and acted on, which (if specified poorly) may 224 not fit cleanly with the architecture of other options or the base 225 protocols on which they are built. 227 In some cases, however, the burden of publishing an RFC in order to 228 get an assignment is excessive. However, it is generally still useful 229 (and sometimes necessary) to discuss proposed additions on a mailing 230 list dedicated to the purpose (e.g., the ietf-types@iana.org for 231 media types) or on a more general mailing list (e.g., that of a 232 current or former IETF WG). Such a mailing list provides a way for 233 new registrations to be publicly reviewed prior to getting assigned, 234 or to give advice to persons wanting help in understanding what a 235 proper registration should contain. 237 While discussion on a mailing list can provide valuable technical 238 feedback, opinions may vary and discussions may continue for some 239 time without clear resolution. In addition, IANA cannot participate 240 in all of these mailing lists and cannot determine if or when such 241 discussions reach consensus. Therefore, IANA relies on a "designated 242 expert" to advise it in the specific question of whether an 243 assignment should be made. The designated expert is a single 244 individual who is responsible for carrying out an appropriate 245 evaluation and returning a recommendation to IANA. 247 It should be noted that a key motivation for having designated 248 experts is for the IETF to provide IANA with a single-person subject 249 matter expert to whom the evaluation process can be delegated. IANA 250 forwards requests for an assignment to the expert for evaluation, and 251 the expert (after performing the evaluation) informs IANA whether or 252 not to make the assignment. 254 3.2. The Role of the Designated Expert 256 The designated expert is responsible for initiating and coordinating 257 as wide a review of an assignment request as appropriate to evaluate 258 it properly. This may involve consultation with a set of technology 259 experts, discussion on a public mailing list, or consultation with a 260 working group (or its mailing list if the working group has 261 disbanded), etc. Ideally, the designated expert follows specific 262 review criteria as documented with the protocol that creates or uses 263 the namespace. (See the IANA Considerations sections of 264 [RFC3748,RFC3575] for examples that have been done for specific name 265 spaces). 267 Designated experts are expected to be able to defend their decisions 268 to the IETF community and the evaluation process is not intended to 269 be secretive or bestow unquestioned power on the expert. Experts are 270 expected to apply applicable documented review or vetting procedures, 271 or in the absence of documented criteria, follow generally-accepted 272 norms, e.g., those in section 3.3. 274 Section 5.2 discusses disputes and appeals in more detail. 276 Designated experts are appointed by the IESG (normally upon 277 recommendation by the relevant Area Director). They are typically 278 named at the time a document creating or updating a name space is 279 approved by the IESG, but as experts originally appointed may later 280 become unavailable, the IESG will appoint replacements if necessary. 282 Since the designated experts are appointed by the IESG, they may be 283 removed by the IESG. 285 3.3. Designated Expert Reviews 287 In the eight years since RFC 2434 was published and has been put to 288 use, experience has led to the following observations: 290 - a designated expert must respond in a timely fashion, normally 291 within a week for simple requests to a few weeks for more complex 292 ones. Unreasonable delays can cause significant problems for those 293 needing assignments, such as when products need code points to 294 ship. This is not to say that all reviews can be completed under a 295 firm deadline, but they must be started, and the requester and 296 IANA should have some transparency into the process if an answer 297 cannot be given quickly. 299 - if a designated expert does not respond to IANA's requests within 300 a reasonable period of time, either with a response, or with a 301 reasonable explanation for a delay (e.g., some requests may be 302 particularly complex), and if this is a recurring event, IANA must 303 raise the issue with the IESG. Because of the problems caused by 304 delayed evaluations and assignments, the IESG should take 305 appropriate actions, such as ensuring that the expert understands 306 and accepts their responsibilities, or appointing a new expert. 308 - The designated expert is not required to personally bear the 309 burden of evaluating and deciding all requests, but acts as a sort 310 of shepherd for the request, enlisting the help of others as 311 appropriate. In the case that a request is denied, and rejecting 312 the request is likely to be controversial, the expert should have 313 the support of other subject matter experts. That is, the expert 314 must be able to defend a decision to the community as a whole. 316 In the case where a designated expert is used, but there are no 317 specific documented criteria for performing an evaluation, the 318 presumption should be that a code point should be granted, unless 319 there is a compelling reason not to. Possible reasons to deny a 320 request include: 322 - scarcity of codepoints, where the finite remaining codepoints 323 should be prudently managed, or when a request for a large number 324 of codepoints is made, when a single codepoint is the norm. 326 - documentation is not of sufficient clarity to evaluate or ensure 327 interoperability 329 - the code point is needed for a protocol extension, but the 330 extension is not consistent with the documented (or generally 331 understood) architecture of the base protocol being extended, and 332 would be harmful to the protocol if widely deployed. It is not the 333 intent that "inconsistencies" refer to minor differences "of a 334 personal preference nature;" instead, they refer to significant 335 differences such as inconsistencies with the underlying security 336 model, implying a change to the semantics of an existing message 337 type or operation, requiring unwarranted changes in deployed 338 systems (compared with alternate ways of achieving a similar 339 result), etc. 341 - the extension would cause problems with existing deployed systems. 343 - the extension would conflict with one under active development by 344 the IETF, and having both would harm rather than foster 345 interoperability. 347 4. Creating A Registry 349 Creating a registry involves describing the name spaces to be 350 created, an initial set of assignments (if appropriate) and 351 guidelines on how future assignments are to be made. 353 4.1. Well-Known IANA Policy Definitions 355 The following are some defined policies, some of which are in use 356 today. These cover a range of typical policies that have been used to 357 date to describe the procedure for assigning new values in a name 358 space. It is not required that documents use these terms; the actual 359 requirement is that the instructions to IANA are clear and 360 unambiguous. However, use of these terms is RECOMMENDED where 361 possible, since their meaning is widely understood. 363 Private Use - For private or local use only, with the type and 364 purpose defined by the local site. No attempt is made to 365 prevent multiple sites from using the same value in 366 different (and incompatible) ways. There is no need for 367 IANA to review such assignments (since IANA does not record 368 them) and assignments are not generally useful for broad 369 interoperability. 371 Examples: Site-specific options in DHCP [DHCP] have 372 significance only within a single site. "X-foo:" header 373 lines in email messages. 375 Experimental Use - Similar to private or local use only, with the 376 purpose being to facilitate experimentation. See 377 [EXPERIMENTATION] for details. 379 Hierarchical allocation - Delegated managers can assign values 380 provided they have been given control over that part of the 381 name space. IANA controls the higher levels of the 382 namespace according to one of the other policies. 384 Examples: DNS names, Object Identifiers, IP addresses 386 First Come First Served - Assignments are made to anyone on a 387 first come, first served bases. There is no substantive 388 review of the request, other than to ensure that it is 389 well-formed and doesn't duplicate an existing assignment. 390 However, requests must include a minimal amount of clerical 391 information, such as a a point of contact and a brief 392 description of what the value would be used for. Additional 393 information specific to the type of value requested may 394 also need to be provided, as defined by the name space. For 395 numbers, the exact value is generally assigned by IANA; 396 with names, specific text strings can usually be requested. 398 Examples: vnd. (vendor assigned) MIME types [MIME-REG]. 400 Expert Review (or Designated Expert) - approval by a Designated 401 Expert is required. The required documentation and review 402 criteria to be used by the Designated Expert should be 403 provided when defining the registry. For example, see 404 Sections 6 and 7.2 in [RFC3748]. 406 Specification required - Values and their meaning must be 407 documented in an RFC or other permanent and readily 408 available public specification, in sufficient detail so 409 that interoperability between independent implementations 410 is possible. When used, Specification Required also implies 411 usage of a Designated Expert, who will review the public 412 specification and evaluate whether it is sufficiently clear 413 to allow interoperable implementations. The intention 414 behind "permanent and readily available" is that a document 415 can be reasonably be expected to easily be found long after 416 RFC publication. 418 Examples: SCSP [SCSP] 420 RFC Required - RFC publication (either as IETF Submission or as an 421 RFC Editor submission [RFC3932]) suffices. 423 IETF Review - (Formerly called "IETF Consensus" in [IANA- 424 CONSIDERATIONS]) New values are assigned only through RFCs 425 that have been shepherded through the IESG as AD-Sponsored 426 IETF (or WG) Documents [RFC3932,RFC3978]. The intention is 427 that the document and proposed assignment will be reviewed 428 by the IESG and appropriate IETF WGs (or experts, if 429 suitable working groups no longer exist) to ensure that the 430 proposed assignment will not negatively impact 431 interoperability or otherwise extend IETF protocols in an 432 inappropriate or damaging manner. 434 To ensure adequate community review, such documents are 435 shepherded through the IESG as AD-sponsored documents with 436 an IETF Last Call. 438 Examples: SMTP extensions [SMTP-EXT], BGP Subsequent 439 Address Family Identifiers [BGP4-EXT]. 441 Standards Action - Values are assigned only for Standards Track 442 RFCs approved by the IESG. 444 Examples: MIME top level types [MIME-REG] 446 IESG Approval - New assignments may be approved by the IESG. 447 Although there is no requirement that the request be 448 documented in an RFC, the IESG has discretion to request 449 documents or other supporting materials on a case-by-case 450 basis. 452 IESG Approval is not intended to be used often or as a 453 "common case;" indeed, it has seldom been used in practice 454 during the period RFC 2434 was in effect. Rather, it is 455 intended to be available in conjunction with other policies 456 as a fall-back mechanism in the case where one of the other 457 allowable approval mechanisms cannot be employed in a 458 timely fashion or for some other compelling reason. IESG 459 Approval is not intended to circumvent the public review 460 processes implied by other policies that could have been 461 employed for a particular assignment. IESG Approval would 462 be appropriate, however, in cases where expediency is 463 desired and there is strong consensus for making the 464 assignment (e.g., WG consensus). 466 The following guidelines are suggested for any evaluation 467 under IESG Approval: 469 - The IESG can (and should) reject a request if another 470 path is available that is more appropriate and there is 471 no compelling reason to bypass normal community review 473 - before approving a request, the community should be 474 consulted, via a "call for comments" that provides as 475 much information as is reasonably possible about the 476 request. 478 It should be noted that it often makes sense to partition a name 479 space into multiple categories, with assignments within each category 480 handled differently. For example, many protocols now partition name 481 spaces into two (or even more) parts, where one range is reserved for 482 Private or Experimental Use, while other ranges are reserved for 483 globally unique assignments assigned following some review process. 484 Dividing a name space into ranges makes it possible to have different 485 policies in place for different ranges. 487 4.2. What To Put In Documents That Create A Registry 489 The previous sections presented some issues that should be considered 490 in formulating a policy for assigning values in name spaces. It is 491 the Working Group and/or document author's job to formulate an 492 appropriate policy and specify it in the appropriate document. In 493 almost all cases, having an explicit "IANA Considerations" section is 494 appropriate. The following subsections define what is needed for the 495 different types of IANA actions. 497 Documents that create a new name space (or modify the definition of 498 an existing space) and that expect IANA to play a role in maintaining 499 that space (e.g., serving as a repository for registered values) MUST 500 provide clear instructions on details of the name space. In 501 particular, instructions MUST include: 503 1) The name of the registry being created and/or maintained. The 504 name will appear on the IANA web page and will be referred to in 505 future documents that need to allocate a value from the new 506 space. The full name (and abbreviation, if appropriate) should 507 be provided. It is highly desirable that the chosen name not be 508 easily confusable with the name of another registry. 510 2) What information must be provided as part of a request in order 511 to assign a new value. 513 3) The review process that will apply to all future requests for a 514 value from the namespace. 516 Note: When a Designated Expert is used, documents MUST NOT name 517 the Designated Expert in the document itself; instead, the name 518 should be relayed to the appropriate IESG Area Director at the 519 time the document is sent to the IESG for approval. 521 If the request should also be reviewed on a specific public 522 mailing list (such as the ietf-types@iana.org for media types), 523 that mailing address should be specified. Note, however, that 524 when mailing lists are specified, a Designated Expert MUST also 525 be specified (see Section 3). 527 If IANA is expected to make assignments without requiring an 528 outside review, sufficient guidance MUST be provided so that the 529 requests can be evaluated with minimal subjectivity. 531 When specifying the process for making future assignments, it is 532 quite acceptable to pick one (ore more) of the example policies 533 listed in Section 4.1 and refer to it by name. Indeed, this is the 534 preferred mechanism in those cases where the sample policies provide 535 the desired level of review. It is also acceptable to cite one of the 536 above policies and include additional guidelines for what kind of 537 considerations should be taken into account by the review process. 538 For example, RADIUS [RFC3575] specifies the use of a Designated 539 Expert, but includes specific additional criteria the Designated 540 Expert should follow. 542 For example, a document could say something like: 544 This document defines a new DHCP option, entitled "FooBar" (see 545 Section y), assigned a value of TBD1 from the DCHP Option space 546 [RFCXXX]. The FooBar option also defines an 8-bit FooType field, 547 for which IANA is to create and maintain a registry entitled 548 "FooType values". Initial values for the FooType registry are 549 given below; future assignments are to be made through Expert 550 Review [IANA-CONSIDERATIONS]. Assignments consist of a FooType 551 name and its associated value. 553 FooType Name Value Definition 554 ---- ----- ---------- 555 Frobnitz 1 See Section y.1 556 NitzFrob 2 See Section y.2 558 For examples of documents that provide good and detailed guidance to 559 IANA on the issue of assigning numbers, consult [MIME-LANG, RFC3757, 560 RFC3749, RFC3575, RFC3968]. 562 4.3. Updating IANA Guidelines For Existing Registries 564 Updating the registration process for an already existing (i.e., 565 previously created) name space (whether created explicitly or 566 implicitly) follows a process similar to that used when creating a 567 new namespace. That is, a document is produced that makes reference 568 to the existing namespace and then provides detailed guidelines for 569 handling assignments in each individual name space. Such documents 570 are normally processed as BCPs [IETF-PROCESS]. 572 Example documents that updated the guidelines for managing (then) 573 pre-existing registries include: [RFC2929,RFC3228,RFC3575]. 575 5. Registering New Values In An Existing Registry 577 5.1. What to Put In Documents When Registering Values 579 Often, documents request an assignment from an already existing name 580 space (i.e., one created by a previously-published RFC). In such 581 cases documents should make clear: 583 - From what name space is a value is being requested? It is helpful 584 to use the exact name space name as listed on the IANA web page 585 (and defining RFC), and cite the RFC where the name space is 586 defined. (Note: There is no need to mention what the assignment 587 policy for new assignments is, as that should be clear from the 588 references.) 590 - For each value being requested, give it a unique reference. When 591 the value is numeric, use the notation: TBD1, TBD2, etc. Through- 592 out the document where an actual IANA-assigned value should be 593 filled in, use the "TBDx" notation. This helps ensure that the 594 final RFC has the correct assigned values inserted in in all of 595 the relevant places where the value is expected to appear in the 596 final document. For values that are text strings, a specific name 597 can be suggested. IANA will normally assign the name, unless it 598 conflicts with a name already in use. 600 - Normally, the values to be used are chosen by IANA; documents 601 shouldn't pick values themselves. However, in some cases a value 602 may have been used for testing or in early implementations. In 603 such cases, it is acceptable to include text suggesting what spe- 604 cific value should be used (together with the reason for the 605 choice). For example, one might include the text "the value XXX is 606 suggested as it is used in implementations". However, it should be 607 noted that suggested values are just that; IANA will attempt to 608 assign them, but may find that impossible, if the proposed number 609 has already been assigned for some other use. 611 For some registries, IANA has a longstanding policy prohibiting 612 assignment of names or codes on a vanity or organization name 613 basis, e.g., codes are always assigned sequentially unless there 614 is a strong reason for making an exception. Nothing in this docu- 615 ment is intended to change those policies or prevent their future 616 application. 618 - The IANA Considerations section should summarize all of the IANA 619 actions, with pointers to the relevant sections elsewhere in the 620 document as appropriate. When multiple values are requested, it is 621 generally helpful to include a summary table. It is also often 622 useful for this table to be in the format of a registry data as it 623 should appear on the IANA web site 625 As an example, the following text could be used to request assignment 626 of a DHCPv6 option number: 628 IANA has assigned an option code value of TBD1 to the DNS Recur- 629 sive Name Server option and an option code value of TBD2 to the 630 Domain Search List option from the DHCP option code space defined 631 in section 24.3 of RFC 3315. 633 5.2. Updating Registrations 635 Registrations are a request for an assigned number, including the 636 related information needed to evaluate and document the request. Even 637 after a number has been assigned, some types of registrations contain 638 additional information that may need to be updated over time. For 639 example, MIME types, character sets, language tags, etc. typically 640 include more information than just the registered value itself. 641 Example information can include point of contact information, 642 security issues, pointers to updates, literature references, etc. In 643 such cases, the document defining the namespace must clearly state 644 who is responsible for maintaining and updating a registration. In 645 different cases, it may be appropriate to specify one or more of the 646 following: 648 - Let the author update the registration, subject to the same 649 constraints and review as with new registrations. 651 - Allow some mechanism to attach comments to the registration, for 652 cases where others have significant objections to claims in a 653 registration, but the author does not agree to change the 654 registration. 656 - Designate the IESG or another entity as having the right to 657 change the registrant associated with a registration and any 658 requirements or conditions on doing so. This is mainly to get 659 around the problem when a registrant cannot be reached in order 660 to make necessary updates. 662 5.3. Overriding Registration Procedures 664 Since RFC 2434 was published, experience has shown that the 665 documented IANA considerations for individual protocols do not always 666 adequately cover the reality on the ground. For example, many older 667 routing protocols do not have documented, detailed IANA 668 considerations. In addition, documented IANA considerations are 669 sometimes found to be too stringent to allow even working group 670 documents (for which there is strong consensus) to obtain code points 671 from IANA in advance of actual RFC publication. In other cases, the 672 documented procedures are unclear or neglected to cover all the 673 cases. In order to allow assignments in individual cases where there 674 is strong IETF consensus that an allocation should go forward, but 675 the documented procedures do not support such an assignment, the IESG 676 is granted authority to approve assignments in such cases. The 677 intention is not to overrule properly documented procedures, or to 678 obviate the need for protocols to properly document their IANA 679 Considerations. Instead, the intention is to permit assignments in 680 individual cases where it is obvious that the assignment should just 681 be made, but updating the IANA process just to assign a particular 682 code point is viewed as too heavy a burden. 684 In general, the IETF would like to see deficient IANA registration 685 procedures for a namespace revised through the IETF standards 686 process, but not at the cost of unreasonable delay for needed 687 assignments. If the IESG has had to take the action in this section, 688 it is a strong indicator that the IANA registration procedures should 689 be updated, possibly in parallel with ongoing protocol work. 691 6. Miscellaneous Issues 693 6.1. When There Are No IANA Actions 695 Before an Internet-Draft can be published as an RFC, IANA needs to 696 know what actions (if any) it needs to perform. Experience has shown 697 that it is not always immediately obvious whether a document has no 698 IANA actions, without reviewing a document in some detail. In order 699 to make it clear to IANA that it has no actions to perform (and that 700 the author has consciously made such a determination!), such 701 documents should include an IANA Considerations section that states: 703 This document has no IANA Actions. 705 This statement, or an equivalent form of words, must only be inserted 706 after the WG or individual submitter has carefully verified it to be 707 true. Using such wording as a matter of "boilerplate" or without 708 careful consideration can lead to incomplete or incorrect IANA 709 actions being performed. 711 If a specification makes use of values from a name space that is not 712 managed by IANA, it may be useful to note this fact, e.g., with 713 wording such as: 715 The values of the Foobar parameter are assigned by the Barfoo 716 registry on behalf of the Rabfoo Forum. Therefore, this document 717 has no IANA Actions. 719 In some cases, the absence of IANA-assigned values may be considered 720 valuable information for future readers; in other cases it may be 721 considered of no value once the document has been approved, and may 722 be removed before archival publication. This choice should be made 723 clear in the draft, for example by including a sentence such as 725 [RFC Editor: please remove this section prior to publication.] 727 or 729 [RFC Editor: please do not remove this section.] 731 6.2. Appeals 733 Appeals on registration decisions made by IANA can be appealed using 734 the normal IETF appeals process as described in Section 6.5 of 735 [IETF-PROCESS]. Specifically, appeals should be directed to the IESG, 736 followed (if necessary) by an appeal to the IAB, etc. 738 6.3. Namespaces Lacking Documented Guidance 740 For all existing RFCs that either explicitly or implicitly rely on 741 IANA to evaluate assignments without specifying a precise evaluation 742 policy, IANA (in consultation with the IESG) will continue to decide 743 what policy is appropriate. Changes to existing policies can always 744 be initiated through the normal IETF consensus process. 746 All future RFCs that either explicitly or implicitly rely on IANA to 747 register or otherwise manage name space assignments MUST provide 748 guidelines for managing the name space. 750 6.4. After-The-Fact Registrations 752 Occasionally, IANA becomes aware that an unassigned value from a 753 managed name space is in use on the Internet, or that an assigned 754 value is being used for a different purpose than originally 755 registered. IANA will not condone such misuse, i.e., procedures of 756 the type described in this document MUST be applied to such cases. In 757 the absence of specifications to the contrary, values may only be 758 reassigned for a different purpose with the consent of the original 759 assignee (when possible) and with due consideration of the impact of 760 such a reassignment. 762 6.5. Reclaiming Assigned Values 764 Reclaiming previously-assigned values for reuse is tricky, because 765 doing so can lead to interoperability problems with deployed systems 766 still using the assigned values. Moreover, it can be extremely 767 difficult to determine the extent of deployment of systems making use 768 of a particular value. However, in cases where the name space is 769 running out of unassigned values and additional ones are needed, it 770 may be desirable to attempt to reclaim unused values. When reclaiming 771 unused values, the following (at a minimum) should be considered: 773 - attempts should be made to contact the original party to which a 774 value is assigned, to determine how widely used a value is. (In 775 some cases, products were never shipped or have long ceased being 776 used. In other cases, it may be known that a value was never 777 actually used at all.) 779 - reassignments should not normally be made without the concurrence 780 of the original requester. Reclamation under such conditions 781 should only take place where there is strong evidence that a value 782 is not widely used, and the need to reclaim the value outweighs 783 the cost of a hostile reclamation. In any case, IESG approval is 784 needed in this case. 786 - it may be appropriate to write up the proposed action and solicit 787 comments from relevant user communities. In some cases, it may be 788 appropriate to write an RFC that goes through a formal IETF 789 process (including IETF Last Call) as was done when DHCP reclaimed 790 some of its "Private Use" options [RFC3942] 792 7. Mailing Lists 794 All IETF mailing lists associated with evaluating or discussing 795 assignment requests as described in this document are subject to 796 whatever rules of conduct and methods of list management are 797 currently defined by Best Current Practices or by IESG decision. 799 8. Security Considerations 801 Information that creates or updates a registration needs to be 802 authenticated and authorized. IANA updates registries according to 803 instructions in published RFCs and from the IESG. It also may accept 804 clarifications from document authors and relevant WG chairs. 806 Information concerning possible security vulnerabilities of a 807 protocol may change over time. Likewise, security vulnerabilities 808 related to how an assigned number is used (e.g., if it identifies a 809 protocol) may change as well. As new vulnerabilities are discovered, 810 information about such vulnerabilities may need to be attached to 811 existing registrations, so that users are not mislead as to the true 812 security issues surrounding the use of a registered number. 814 An analysis of security issues is required for all parameters (data 815 types, operation codes, keywords, etc.) used in IETF protocols or 816 registered by IANA. All descriptions of security issues must be as 817 accurate as possible regardless of level of registration. In 818 particular, a statement that there are "no security issues associated 819 with this type" must not given when it would be more accurate to 820 state that "the security issues associated with this type have not 821 been assessed". 823 9. Open Issues 825 - the security considerations section seems out of whack with 826 reality and existing practice. Which registries actually talk 827 about security implications? Is this a common thing to do? Should 828 security issues be discussed in published RFCs instead? 830 - Added text to "Specification Required" stating that an Expert will 831 be used to evaluate a spec for adequate "implementability". Is 832 this reasonable? [IANA can't do the evaluation, as they lack the 833 necessary time/expertise. So someone has to do it...] Note: 834 Consensus seems to be yes. 836 - It would be good to get additional feedback on whether the 837 examples of "good IANA Considerations" that are cited are actually 838 good, or whether better ones are available. 840 10. Changes Relative to RFC 2434 842 Changes include: 844 - Major reordering of text to group the "creation of registries" 845 text in same section, etc. 847 - Numerous editorial changes to improve readability. 849 - Change "IETF Consensus" term to "IETF Review" and added more 850 clarifications. (History has shown that people see the words "IETF 851 Consensus" and know what that means; in contrast, the term has a 852 specific definition within this document.) 854 - Added "RFC Required" to list of defined policies. 856 - Much more explicit directions and examples of "what to put in 857 RFCs". 859 - "Specification Required" now implies use of Designated Expert to 860 evaluate specs for sufficient clarity. 862 - Significantly changed the wording in Section 3. Main purpose is to 863 make clear that Expert Reviewers are accountable to the community, 864 and to provide some guidance for review criteria in the default 865 case. 867 - removed wording: "By virtue of the IAB's role as overseer of IANA 868 administration [RFC 1602], the IAB's decision is final [IETF- 869 PROCESS]." This document now makes no changes to existing appeal 870 mechanisms relative to RFC 2026. 872 - Added section about reclaiming unused value. 874 - Added a section on after-the-fact registrations. 876 - no doubt other things... 878 [RFC Editor: please remove the "changes relative to individual 879 drafts" below upon publication.] 881 10.1. Changes Relative to -00 883 - Revised Section 5.3 to try and make it even more clear. 885 10.2. Changes Relative to -02 887 - Significantly changed the wording in Section 3. Main purpose is 888 to make clear the Expert Reviewers are accountable to the 889 community, and to provide some guidance for review criteria in 890 the default case. 892 - removed wording: "By virtue of the IAB's role as overseer of 893 IANA administration [RFC 1602], the IAB's decision is final 894 [IETF-PROCESS]." This document now makes no changes to existing 895 appeal mechanisms relative to RFC 2026. 897 11. IANA Considerations 899 This document is all about IANA Considerations. 901 12. Acknowledgments 903 This document has benefited from specific feedback from Marcelo 904 Bagnulo Braun, Brian Carpenter, Barbara Denny, Spencer Dawkins, Paul 905 Hoffman, John Klensin, Allison Mankin, Mark Townsley and Bert Wijnen. 907 The original acknowledgments section in RFC 2434 was: 909 Jon Postel and Joyce Reynolds provided a detailed explanation on what 910 IANA needs in order to manage assignments efficiently, and patiently 911 provided comments on multiple versions of this document. Brian 912 Carpenter provided helpful comments on earlier versions of the 913 document. One paragraph in the Security Considerations section was 914 borrowed from [MIME-REG]. 916 13. Normative References 918 14. Informative References 920 [ASSIGNED] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, 921 RFC 1700, October 1994. See also: 922 http://www.iana.org/numbers.html 924 [BGP4-EXT] Bates. T., Chandra, R., Katz, D. and Y. Rekhter, 925 "Multiprotocol Extensions for BGP-4", RFC 2283, 926 February 1998. 928 [DHCP-OPTIONS] Alexander, S. and R. Droms, "DHCP Options and BOOTP 929 Vendor Extensions", RFC 2132, March 1997. 931 [EXPERIMENTATION] "Assigning Experimental and Testing Numbers 932 Considered Useful". T. Narten, RFC 3692, January 933 2004. 935 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 936 Writing an IANA Considerations Section in RFCs", BCP 937 26, RFC 2434, October 1998. 939 [IANA-MOU] Memorandum of Understanding Concerning the Technical Work 940 of the Internet Assigned Numbers Authority. B. 941 Carpenter, F. Baker, M. Roberts, RFC 2860, June 942 2000. 944 [IETF-PROCESS] Bradner, S., "The Internet Standards Process -- 945 Revision 3", BCP 9, RFC 2026, October 1996. 947 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 949 [IPSEC] Atkinson, R., "Security Architecture for the Internet 950 Protocol", RFC 1825, August 1995. 952 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 953 Requirement Levels", BCP 14, RFC 2119, March 1997. 955 [MIME-LANG] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 956 Word Extensions: Character Sets, Languages, and 957 Continuations", RFC 2184, August 1997. 959 [MIME-REG] Freed, N., Klensin, J. and J. Postel, "Multipurpose 960 Internet Mail Extension (MIME) Part Four: 961 Registration Procedures", RFC 2048, November 1996. 963 [SCSP] Luciani, J., Armitage, G. and J. Halpern, "Server Cache 964 Synchronization Protocol (SCSP)", RFC 2334, April 965 1998. 967 [SMTP-EXT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. 968 Crocker, "SMTP Service Extensions", RFC 1869, 969 November 1995. 971 [PROTOCOL-EXT] "Procedures for protocol extensions and variations", 972 draft-carpenter-protocol-extensions-01.txt 974 [RFC2929] Domain Name System (DNS) IANA Considerations. D. Eastlake 975 3rd, E. Brunner-Williams, B. Manning. September 976 2000. 978 [RFC3228] IANA Considerations for IPv4 Internet Group Management 979 Protocol (IGMP). B. Fenner. February 2002. 981 [RFC3575] IANA Considerations for RADIUS (Remote Authentication Dial 982 In User Service). B. Aboba. RFC 3575, July 2003. 984 [RFC3748] Extensible Authentication Protocol (EAP), B. Aboba, L. 985 Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, 986 Ed., RFC 3748, June, 2004. 988 [RFC3978] IETF Rights in Contributions. S. Bradner, Ed.. March 2005. 990 [RFC3575] IANA Considerations for RADIUS (Remote Authentication Dial 991 In User Service). B. Aboba. July 2003. 993 [RFC3748] Extensible Authentication Protocol (EAP). B. Aboba, L. 994 Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, 995 Ed.. June 2004. 997 [RFC3932] The IESG and RFC Editor Documents: Procedures. H. 998 Alvestrand. October 2004. 1000 [RFC3942] "Reclassifying Dynamic Host Configuration Protocol version 1001 4 (DHCPv4) Options", B. Volz. RFC 3942, November 1002 2004 1004 [RFC3968] "The Internet Assigned Number Authority (IANA) Header Field 1005 Parameter Registry for the Session Initiation 1006 Protocol (SIP)," G. Camarillo. RFC 3968, December 1007 2004. 1009 15. Authors' Addresses 1011 Thomas Narten 1012 IBM Corporation 1013 3039 Cornwallis Ave. 1014 PO Box 12195 - BRQA/502 1015 Research Triangle Park, NC 27709-2195 1017 Phone: 919-254-7798 1018 EMail: narten@us.ibm.com 1020 Harald Tveit Alvestrand 1021 Google 1023 Email: Harald@Alvestrand.no 1025 Intellectual Property Statement 1027 The IETF takes no position regarding the validity or scope of any 1028 Intellectual Property Rights or other rights that might be claimed to 1029 pertain to the implementation or use of the technology described in 1030 this document or the extent to which any license under such rights 1031 might or might not be available; nor does it represent that it has 1032 made any independent effort to identify any such rights. Information 1033 on the procedures with respect to rights in RFC documents can be 1034 found in BCP 78 and BCP 79. 1036 Copies of IPR disclosures made to the IETF Secretariat and any 1037 assurances of licenses to be made available, or the result of an 1038 attempt made to obtain a general license or permission for the use of 1039 such proprietary rights by implementers or users of this 1040 specification can be obtained from the IETF on-line IPR repository at 1041 http://www.ietf.org/ipr. 1043 The IETF invites any interested party to bring to its attention any 1044 copyrights, patents or patent applications, or other proprietary 1045 rights that may cover technology that may be required to implement 1046 this standard. Please address the information to the IETF at ietf- 1047 ipr@ietf.org. 1049 Disclaimer of Validity 1051 This document and the information contained herein are provided on an 1052 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1053 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1054 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1055 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1056 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1057 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1059 Copyright Statement 1061 Copyright (C) The Internet Society (2006). 1063 This document is subject to the rights, licenses and restrictions 1064 contained in BCP 78, and except as set forth therein, the authors 1065 retain all their rights. 1067 This document and the information contained herein are provided on an 1068 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1069 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1070 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1071 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1072 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1073 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.