idnits 2.17.1 draft-narten-iana-considerations-rfc2434bis-02.txt: -(94): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(133): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(357): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(461): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(557): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 781. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 742. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 749. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 755. ** 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 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-02' == There are 7 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (June 27, 2005) is 6878 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 346, but not defined == Missing Reference: 'RFCXXX' is mentioned on line 410, but not defined == Missing Reference: 'RFC 1602' is mentioned on line 557, but not defined ** Obsolete undefined reference: RFC 1602 (Obsoleted by RFC 2026) == Unused Reference: 'DHCP-OPTIONS' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'MIME-LANG' is defined on line 670, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (ref. 'ASSIGNED') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2283 (ref. 'BGP4-EXT') (Obsoleted by RFC 2858) ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 2860 (ref. 'IANA-MOU') ** Obsolete normative reference: RFC 1825 (ref. 'IPSEC') (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 2184 (ref. 'MIME-LANG') (Obsoleted by RFC 2231) ** Obsolete normative reference: RFC 2048 (ref. 'MIME-REG') (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 1869 (ref. 'SMTP-EXT') (Obsoleted by RFC 2821) ** Downref: Normative reference to an Historic RFC: RFC 1818 ** Obsolete normative reference: RFC 2929 (Obsoleted by RFC 5395) ** Obsolete normative reference: RFC 3978 (Obsoleted by RFC 5378) ** Obsolete normative reference: RFC 3932 (Obsoleted by RFC 5742) Summary: 19 errors (**), 1 flaw (~~), 10 warnings (==), 7 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 Cisco 6 June 27, 2005 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 December 30, 2005. 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 the IANA to manage a given name space prudently, it 50 needs guidelines describing the conditions under which new values can 51 be assigned. If the IANA is expected to play a role in the management 52 of a name space, the IANA must be given clear and concise 53 instructions describing that role. This document discusses issues 54 that should be considered in formulating a policy for assigning 55 values to a name space and provides guidelines to document authors on 56 the specific text that must be included in documents that place 57 demands on the IANA. 59 Contents 61 Status of this Memo.......................................... 1 63 1. Introduction............................................. 3 65 2. Issues To Consider....................................... 4 66 2.1. The Motivation For Designated Experts............... 5 68 3. Creating A Registry...................................... 6 69 3.1. Well-Known IANA Policy Definitions.................. 7 70 3.2. What To Put In Documents That Create A Registry..... 9 71 3.3. Updating Guidelines In Existing Registries.......... 10 73 4. Registering Values In An Existing Registry............... 11 74 4.1. What to Put In Documents When Registering Values.... 11 75 4.2. Maintaining Registrations........................... 12 76 4.3. Overriding Registration Procedures.................. 12 78 5. Miscellaneous Issues..................................... 13 79 5.1. When There Are No IANA Actions...................... 13 80 5.2. Appeals............................................. 13 81 5.3. Namespaces Lacking Documented Guidance.............. 13 83 6. Security Considerations.................................. 14 85 7. Changes Relative to RFC 2434............................. 14 86 7.1. Changes Relative to -00............................. 14 88 8. IANA Considerations...................................... 15 90 9. Acknowledgments.......................................... 15 92 10. References.............................................. 15 94 11. Authors��� Addresses.................................... 17 96 1. Introduction 98 Many protocols make use of fields that contain constants and other 99 well-known values (e.g., the Protocol field in the IP header [IP] or 100 MIME types in mail messages [MIME-REG]). Even after a protocol has 101 been defined and deployment has begun, new values may need to be 102 assigned (e.g., a new option type in DHCP [DHCP] or a new encryption 103 or authentication algorithm for IPsec [IPSEC]). To ensure that such 104 fields have consistent values and interpretations in different 105 implementations, their assignment must be administered by a central 106 authority. For IETF protocols, that role is provided by the Internet 107 Assigned Numbers Authority (IANA) [IANA-MOU]. 109 In this document, we call the set of possible values for such a field 110 a "name space"; its actual value may be a text string, a number or 111 another kind of value. The assignment of a specific value to a name 112 space is called an assigned number (or assigned value). Each 113 assignment of a number in a name space is called a registration. 115 In order for the IANA to manage a given name space prudently, it 116 needs guidelines describing the conditions under which new values 117 should be assigned. This document provides guidelines to authors on 118 what sort of text should be added to their documents, and reviews 119 issues that should be considered in formulating an appropriate policy 120 for assigning numbers to name spaces. 122 Not all name spaces require centralized administration. In some 123 cases, it is possible to delegate a name space in such a way that 124 further assignments can be made independently and with no further 125 (central) coordination. In the Domain Name System, for example, the 126 IANA only deals with assignments at the higher-levels, while 127 subdomains are administered by the organization to which the space 128 has been delegated. As another example, Object Identifiers (OIDs) as 129 defined by the ITU are also delegated [ASSIGNED]. When a name space 130 can be delegated, the scope of IANA is limited to the parts of the 131 namespace where IANA has authority. 133 This document uses the terms ���MUST���, ���SHOULD��� and ���MAY���, and their 134 negatives, in the way described in RFC 2119 [KEYWORDS]. In this case, 135 "the specification" as used by RFC 2119 refers to the processing of 136 protocols being submitted to the IETF standards process. 138 2. Issues To Consider 140 One issue to consider in managing a name space is its size. If the 141 space is small and limited in size, assignments must be made 142 carefully to prevent exhaustion of the space. If the space is 143 essentially unlimited, on the other hand, it may be perfectly 144 reasonable to hand out new values to anyone that wants one. Even 145 when the space is essentially unlimited, however, it is usually 146 desirable to have at least minimal review to prevent the hoarding of 147 or unnecessary wasting of a space. For example, if the space 148 consists of text strings, it may be desirable to prevent 149 organizations from obtaining large sets of strings that correspond to 150 the "best" names (e.g., existing company names). Experience has also 151 shown that some level of minimal review is useful to prevent 152 assignments in cases where the request is malformed or not actually 153 needed (this may not always be immediately obvious to a non-subject- 154 matter expert). 156 A second consideration is whether it makes sense to delegate the name 157 space in some manner. This route should be pursued when appropriate, 158 as it lessens the burden on the IANA for dealing with assignments. 160 A third, and perhaps most important consideration, concerns potential 161 impact on interoperability of unreviewed extensions. Proposed 162 protocol extensions generally benefit from community review; indeed, 163 review is often essential to prevent future interoperability 164 problems. [VENDOR-EXT] discusses this topic in considerable detail. 166 In some cases, the name space is essentially unlimited, there are no 167 potential interoperability issues, and assigned numbers can safely be 168 given out to anyone. When no subjective review is needed, the IANA 169 can make assignments directly, provided that the IANA is given 170 specific instructions on what types of requests it should grant, and 171 what information must be provided before a request for an assigned 172 number will be considered. Note that the IANA will not define an 173 assignment policy; it should be given a set of guidelines that allow 174 it to make allocation decisions with minimal subjectivity. 176 2.1. The Motivation For Designated Experts 178 In most cases, some review of prospective allocations is appropriate, 179 and the question becomes who should perform the review and how 180 rigorous the review needs to be. In many cases, one might think that 181 an IETF Working Group (WG) familiar with the name space at hand 182 should be consulted. In practice, however, WGs eventually disband, so 183 they cannot be considered a permanent evaluator. It is also possible 184 for name spaces to be created through individual submission 185 documents, for which no WG is ever formed. 187 One way to ensure community review of prospective assignments is to 188 have the requester submit a document for publication as an RFC. Such 189 an action helps ensure that the specification is publicly and 190 permanently available, and allows some review of the specification 191 prior to publication. This is the preferred way of ensuring review, 192 and is particularly important if any potential interoperability 193 issues can arise. For example, many assignments are not just 194 assignments, but also involve an element of protocol specification. A 195 new option may define fields that need to be parsed and acted on, 196 which (if specified poorly) may not fit cleanly with the architecture 197 of other options or the base protocols on which they are built. 199 In some cases, however, the burden of publishing an RFC in order to 200 get an assignment is excessive. However, it is generally still useful 201 (and sometimes necessary) to discuss proposed additions on a mailing 202 list dedicated to the purpose (e.g., the ietf-types@iana.org for 203 media types) or on a more general mailing list (e.g., that of a 204 current or former IETF WG). Such a mailing list provides a way for 205 new registrations to be publicly reviewed prior to getting assigned, 206 or to give advice for persons who want help in understanding what a 207 proper registration should contain. 209 While discussion on a mailing list can provide valuable technical 210 expertise, opinions may vary and discussions may continue for some 211 time without clear resolution. In addition, the IANA cannot 212 participate in all of these mailing lists and cannot determine if or 213 when such discussions reach consensus. Therefore, the IANA relies on 214 a "designated expert" to advise it in assignment matters. The 215 designated expert is a single individual who is responsible for 216 carrying out an appropriate evaluation and returning a recommendation 217 to IANA. The designated expert is responsible for initiating and 218 coordinating as wide a review of an assignment request as may be 219 necessary to evaluate it properly. This may involve consultation with 220 a set of technology experts, discussion on a public mailing list, or 221 consultation with a working group (or its mailing list if the working 222 group has disbanded), etc. In some case, the designated expert 223 follows specific review guidelines as documented in a related 224 document. (See the IANA Considerations sections of [RFC3748,RFC3575] 225 for examples of some review criteria an expert follows for specific 226 protocol name spaces.) 228 Designated experts are appointed by the relevant Area Director of the 229 IESG. They are typically named at the time a document that creates a 230 new numbering space is published as an RFC, but as experts originally 231 appointed may later become unavailable, the relevant Area Director 232 will appoint replacements if necessary. 234 Any decisions made by the designated expert can be appealed using the 235 normal IETF appeals process as discussed in Section 5.2. below. 237 Since the designated experts are appointed by the IESG, they may be 238 removed by the IESG. 240 3. Creating A Registry 242 Creating a registry involves describing the name spaces to be created 243 together with an initial set of assignments (if appropriate) and 244 guidelines on how future assignments are to be made. 246 3.1. Well-Known IANA Policy Definitions 248 The following are some defined policies, some of which are in use 249 today. These cover a range of typical policies that have been used to 250 date to describe the procedure for assigning new values in a name 251 space. It is not required that documents use these terms; the actual 252 requirement is that the instructions to IANA are clear and 253 unambiguous. However, it is preferable to use these terms where 254 possible, since their meaning is widely understood. 256 Private Use - For private or local use only, with the type and 257 purpose defined by the local site. No attempt is made to 258 prevent multiple sites from using the same value in 259 different (and incompatible) ways. There is no need for 260 IANA to review such assignments and assignments are not 261 generally useful for interoperability. 263 Examples: Site-specific options in DHCP [DHCP] have 264 significance only within a single site. "X-foo:" header 265 lines in email messages. 267 Experimental Use - Similar to private or local use only, with the 268 purpose being to facilitate experimentation. See 269 [EXPERIMENTATION] for details. 271 Hierarchical allocation - Delegated managers can assign values 272 provided they have been given control over that part of the 273 name space. IANA controls the higher levels of the 274 namespace according to one of the other policies. 276 Examples: DNS names, Object Identifiers 278 First Come First Served - Anyone can obtain an assigned number, so 279 long as they provide a point of contact and a brief 280 description of what the value would be used for. For 281 numbers, the exact value is generally assigned by the IANA; 282 with names, specific text strings are usually requested. 284 Examples: vnd. (vendor assigned) MIME types [MIME-REG], TCP 285 and UDP port numbers. 287 Expert Review (or Designated Expert) - approval by a Designated 288 Expert is required. The required documentation and review 289 criteria to be used by the Designated Expert should be 290 provided when defining the registry. 292 Specification Required - Values and their meaning must be 293 documented in an RFC or other permanent and readily 294 available reference, in sufficient detail so that 295 interoperability between independent implementations is 296 possible. [XXX: who assesses whether a non-RFC document is 297 sufficiently clear for interoperability? IANA cannot.] 299 Examples: SCSP [SCSP] 301 RFC Required - RFC publication (either as IETF Submission or as an 302 RFC Editor submission [RFC3932]) suffices. 304 IETF Review - (Formerly called "IETF Consensus" in [IANA- 305 CONSIDERATIONS]) New values are assigned only through RFCs 306 that have been shepherded through the IESG as AD-Sponsored 307 IETF Documents [RFC3932,RFC3978]. The intention is that the 308 document and proposed assignment will be reviewed by the 309 IESG and appropriate IETF WGs (or experts, if suitable 310 working groups no longer exist) to ensure that the proposed 311 assignment will not negatively impact interoperability or 312 otherwise extend IETF protocols in an inappropriate or 313 damaging manner. 315 To ensure adequate community review, such documents should 316 be Last Called. 318 Examples: SMTP extensions [SMTP-EXT], BGP Subsequent 319 Address Family Identifiers [BGP4-EXT]. 321 Standards Action - Values are assigned only for Standards Track 322 RFCs approved by the IESG. 324 Examples: MIME top level types [MIME-REG] 326 IESG Approval - New assignments may be approved by the IESG. 327 Although there is no requirement that the request be 328 documented in an RFC, the IESG has discretion to request 329 documents or other supporting materials on a case-by-case 330 basis. 332 IESG Approval is not intended to be used often. Rather, it 333 is intended to be used in conjunction with other policies 334 as a fall-back mechanism in the case where one of the other 335 allowable approval mechanisms cannot be employed in a 336 timely fashion or for some other compelling reason. IESG 337 Approval is not intended to circumvent the public review 338 processes implied by other policies that could have been 339 employed for a particular assignment. 341 [XXX: Is Section 4.3. below sufficient to cover the case 342 that IESG is designed to handle?] 344 It should be noted that it often makes sense to partition a name 345 space into several categories, with assignments out of each category 346 handled differently. For example, the DHCP option space [DHCP] is 347 split into two parts. Option numbers in the range of 1-127 are 348 globally unique and assigned according to the Specification Required 349 policy described above, while options number 128-254 are "site 350 specific", i.e., Private Use. Dividing the name space up makes it 351 possible to have different policies in place for different ranges. 353 3.2. What To Put In Documents That Create A Registry 355 The previous sections presented some issues that should be considered 356 in formulating a policy for assigning well-known numbers and other 357 protocol constants. It is the Working Group and/or document author���s 358 job to formulate an appropriate policy and specify it in the 359 appropriate document. In almost all cases, having an explicit "IANA 360 Considerations" section is appropriate. The following subsections 361 define what is needed for the different types of IANA actions. 363 Documents that create a new name space (or modify the definition of 364 an existing space) and that expect the IANA to play a role in 365 maintaining that space (e.g., serving as a repository for registered 366 values) MUST provide clear instructions on details of the name space. 367 In particular, instructions MUST include: 369 1) The name of the registry being created and/or maintained. The 370 name will appear on the IANA web page and will be referred to in 371 future documents that need to allocate a value from the new 372 space. The full name (and abbreviation, if appropriate) should 373 be provided. 375 2) What information must be provided in order to assign a new 376 value. 378 3) The process through which future assignments are made (see 379 Section 3.1). 381 Note: When a Designated Expert is used, documents MUST NOT name 382 the Designated Expert in the document itself; instead, the name 383 should be relayed to the appropriate IESG Area Director at the 384 time the document is sent to the IESG for approval. 386 If the request should also be reviewed on a specific public 387 mailing list (such as the ietf-types@iana.org for media types), 388 that mailing address should be specified. Note, however, that 389 use of a Designated Expert MUST also be specified. 391 If the IANA is expected to make assignments without requiring an 392 outside review, sufficient guidance MUST be provided so that the 393 requests can be evaluated with minimal subjectivity. 395 When specifying the process for making future assignments, it is 396 quite acceptable to pick one of the example policies listed in 397 Section 3.1 and refer to it by name. Indeed, this is the preferred 398 mechanism in those cases where the sample policies provide the 399 desired level of review. It is also acceptable to cite one of the 400 above policies and include additional guidelines for what kind of 401 considerations should be taken into account by the review process. 402 For example, RADIUS [RFC3575] specifies the use of a Designated 403 Expert, but includes additional criteria the Designated Expert should 404 follow. 406 For example, a document could say something like: 408 This document defines a new DHCP option, entitled "FooBar" (see 409 Section y), assigned a value of TBD1 from the DCHP Option space 410 [RFCXXX]. The FooBar option also contains an 8-bit FooType 411 field, for which IANA is to create and maintain a registry 412 entitled "FooType values". Initial values for FooType field are 413 given below; future assignments are to be made through Expert 414 Review [IANA-CONSIDERATIONS]. Assignments consist of a name and 415 the value. 417 Name Value Definition 418 ---- ----- ---------- 419 Frobnitz 1 See Section y.1 420 NitzFrob 2 See Section y.2 422 For examples of documents that provide good and detailed guidance to 423 the IANA on the issue of assigning numbers, consult [MIME-REG, MIME- 424 LANG, RFC3757, RFC3749, RFC3575]. 426 3.3. Updating Guidelines In Existing Registries 428 Updating the registration process for an existing name space is 429 similar to that used when creating an new namespace. That is, a 430 document is produced that makes reference to the existing namespace 431 and then provides detailed management guidelines for each registry. 432 Such documents are normally processed as BCPs [RFC1818]. 434 Example documents that updated the guidelines for managing (then) 435 pre-existing registries include: [RFC2929,RFC3228,RFC3575]. 437 4. Registering Values In An Existing Registry 439 4.1. What to Put In Documents When Registering Values 441 Often, a document requests the assignment of a code point from an 442 already existing name space (i.e., one created by a previously-pub- 443 lished RFC). In such cases documents should make clear: 445 - From what name space is a value is being requested? List the exact 446 name space listed on the IANA web page (and RFC), and cite the RFC 447 where the name space is defined. (Note: There is no need to men- 448 tion what the allocation policy for new assignments is, as that 449 should be clear from the references.) 451 - For each value being requested, give it a unique name. When the 452 value is numeric, use the notation: TBD1, TBD2, etc. Throughout 453 the document where an actual IANA-assigned value should be filled 454 in, use the "TDBx" notation. This helps ensure that the final RFC 455 has the correct assigned value filled in in all of the relevant 456 places where the value is listed in the final document. For values 457 that are text strings, a specific name can be suggested: IANA will 458 assign the name, unless it conflicts with a name already in use. 460 - Normally, the values to be used are chosen by IANA; documents 461 shouldn���t pick values themselves. However, in some cases a value 462 may have been used for testing or in early implementations. In 463 such cases, it is acceptable to include text suggesting what spe- 464 cific value should be used (e.g., include the text "the value XXX 465 is suggested"). However, it should be noted that suggested values 466 are just that; IANA will attempt to assign them, but may find that 467 impossible, if the proposed number has already been assigned for 468 some other use. 470 - The IANA Considerations section should summarize all of the IANA 471 actions, with pointers to the relevant sections as appropriate. 472 When multiple values are requested, it is generally helpful to 473 include a summary table. 475 As an example, the following text could be used to request assignment 476 of a DHCPv6 option number: 478 IANA has assigned an option code value of TBD1 to the DNS Recur- 479 sive Name Server option and an option code value of TBD2 to the 480 Domain Search List option from the DHCP option code space defined 481 in section 24.3 of RFC 3315. 483 4.2. Maintaining Registrations 485 Registrations are a request for an assigned number, including the 486 related information needed to evaluate and document the request. Even 487 after a number has been assigned, some types of registrations contain 488 additional information that may need to be updated over time. For 489 example, MIME types, character sets, language tags, etc. typically 490 include more information than just the registered value itself. 491 Example information can include point of contact information, 492 security issues, pointers to updates, literature references, etc. In 493 such cases, the document defining the namespace must clearly state 494 who is responsible for maintaining and updating a registration. It is 495 appropriate to: 497 - Let the author update the registration, subject to the same 498 constraints and review as with new registrations. 500 - Allow some mechanism to attach comments to the registration, for 501 cases where others have significant objections to claims in a 502 registration, but the author does not agree to change the 503 registration. 505 - Designate the IESG or another authority as having the right to 506 reassign ownership of a registration. This is mainly to get 507 around the problem when some registration owner cannot be 508 reached in order to make necessary updates. 510 4.3. Overriding Registration Procedures 512 [XXX: following is new text w.r.t. 2434. Is this something that is 513 appropriate to include??] 515 Since RFC 2434 was published, experience has shown that the 516 documented IANA considerations for individual protocols do not always 517 adequately cover the reality on the ground. For example, many older 518 routing protocols do not have documented, detailed IANA 519 considerations. In addition, documented IANA considerations are 520 sometimes found to be too stringent to allow even working group 521 documents (for which there is strong consensus) to obtain code points 522 from IANA in advance of actual RFC publication. In other cases, the 523 documented procedures are unclear or neglected to cover all the 524 cases. In order to allow assignments in individual cases where there 525 is strong IETF consensus that an allocation should go forward, but 526 the documented procedures do not support such an assignment, the IESG 527 is granted authority to approve assignments in such cases. The 528 intention is not to overrule documented procedures, or to obviate the 529 need for protocols to properly document their IANA Considerations, 530 but to permit assignments in individual cases where it is obvious 531 that the assignment should just be made, but updating the IANA 532 process just to assign a particular code point is viewed as too heavy 533 a burden. In general, the IETF would like to see deficient IANA 534 registration procedures for a namespace revised through the IETF 535 standards process. 537 5. Miscellaneous Issues 539 5.1. When There Are No IANA Actions 541 Before an Internet-Draft can be published as an RFC, IANA needs to 542 know what actions (if any) it needs to perform. Experience has shown 543 that it is not always immediately obvious whether a document has no 544 IANA actions, without reviewing a document in some detail. In order 545 to make it clear to IANA that it has no actions to perform (and that 546 the author has consciously made such a determination!), such 547 documents should include an IANA Considerations section that states: 549 This document has no IANA Actions. 551 5.2. Appeals 553 Appeals on registration decisions made by the IANA can be appealed to 554 the IESG using the normal IETF appeals process as outlined in Section 555 6.5 of [IETF-PROCESS]. Specifically, appeals should be directed to 556 the IESG, followed (if necessary) by an appeal to the IAB. By virtue 557 of the IAB���s role as overseer of IANA administration [RFC 1602], the 558 IAB���s decision is final. 560 5.3. Namespaces Lacking Documented Guidance 562 For all existing RFCs that either explicitly or implicitly rely on 563 the IANA to evaluate assignments without specifying a precise 564 evaluation policy, the IANA (in consultation with the IESG) will 565 continue to decide what policy is appropriate. Changes to existing 566 policies can always be initiated through the normal IETF consensus 567 process. 569 All future RFCs that either explicitly or implicitly rely on the IANA 570 to register or otherwise manage assignments MUST provide guidelines 571 for managing the name space. 573 6. Security Considerations 575 Information that creates or updates a registration needs to be 576 authenticated. 578 Information concerning possible security vulnerabilities of a 579 protocol may change over time. Likewise, security vulnerabilities 580 related to how an assigned number is used (e.g., if it identifies a 581 protocol) may change as well. As new vulnerabilities are discovered, 582 information about such vulnerabilities may need to be attached to 583 existing registrations, so that users are not mislead as to the true 584 security issues surrounding the use of a registered number. 586 An analysis of security issues is required for all parameters (data 587 types, operation codes, keywords, etc.) used in IETF protocols or 588 registered by the IANA. All descriptions of security issues must be 589 as accurate as possible regardless of level of registration. In 590 particular, a statement that there are "no security issues associated 591 with this type" must not given when it would be more accurate to 592 state that "the security issues associated with this type have not 593 been assessed". 595 7. Changes Relative to RFC 2434 597 Changes include: 599 - Major reordering of text to group the "creation of registries" 600 text in same section, etc. 602 - Numerous editorial changes to improve readability. 604 - Change "IETF Consensus" term to "IETF Review" and added more 605 clarifications. 607 - Added "RFC Required" to list of defined policies. 609 - Much more explicit directions and examples of "what to put in 610 RFCs". 612 - no doubt other things... 614 7.1. Changes Relative to -00 616 - Revised Section 5.3 to try and make it even more clear. 618 8. IANA Considerations 620 This document is all about IANA Considerations. 622 9. Acknowledgments 624 From RFC 2434: 626 Jon Postel and Joyce Reynolds provided a detailed explanation on what 627 the IANA needs in order to manage assignments efficiently, and 628 patiently provided comments on multiple versions of this document. 629 Brian Carpenter provided helpful comments on earlier versions of the 630 document. One paragraph in the Security Considerations section was 631 borrowed from [MIME-REG]. 633 10. References 635 [ASSIGNED] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, 636 RFC 1700, October 1994. See also: 637 http://www.iana.org/numbers.html 639 [BGP4-EXT] Bates. T., Chandra, R., Katz, D. and Y. Rekhter, 640 "Multiprotocol Extensions for BGP-4", RFC 2283, 641 February 1998. 643 [DHCP-OPTIONS] Alexander, S. and R. Droms, "DHCP Options and BOOTP 644 Vendor Extensions", RFC 2132, March 1997. 646 [EXPERIMENTATION] "Assigning Experimental and Testing Numbers 647 Considered Useful". T. Narten, RFC 3692, January 648 2004. 650 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 651 Writing an IANA Considerations Section in RFCs", BCP 652 26, RFC 2434, October 1998. 654 [IANA-MOU] Memorandum of Understanding Concerning the Technical Work 655 of the Internet Assigned Numbers Authority. B. 656 Carpenter, F. Baker, M. Roberts, RFC 2860, June 657 2000. 659 [IETF-PROCESS] Bradner, S., "The Internet Standards Process -- 660 Revision 3", BCP 9, RFC 2026, October 1996. 662 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 664 [IPSEC] Atkinson, R., "Security Architecture for the Internet 665 Protocol", RFC 1825, August 1995. 667 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 668 Requirement Levels", BCP 14, RFC 2119, March 1997. 670 [MIME-LANG] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 671 Word Extensions: Character Sets, Languages, and 672 Continuations", RFC 2184, August 1997. 674 [MIME-REG] Freed, N., Klensin, J. and J. Postel, "Multipurpose 675 Internet Mail Extension (MIME) Part Four: 676 Registration Procedures", RFC 2048, November 1996. 678 [SCSP] Luciani, J., Armitage, G. and J. Halpern, "Server Cache 679 Synchronization Protocol (SCSP)", RFC 2334, April 680 1998. 682 [SMTP-EXT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. 683 Crocker, "SMTP Service Extensions", RFC 1869, 684 November 1995. 686 [VENDOR-EXT] "Considerations on the Extensibility of IETF protocols", 687 draft-iesg-vendor-extensions-02.txt 689 [RFC1818] Best Current Practices. J. Postel, T. Li, Y. Rekhter. 690 August 1995. 692 [RFC2929] Domain Name System (DNS) IANA Considerations. D. Eastlake 693 3rd, E. Brunner-Williams, B. Manning. September 694 2000. 696 [RFC3228] IANA Considerations for IPv4 Internet Group Management 697 Protocol (IGMP). B. Fenner. February 2002. 699 [RFC3575] IANA Considerations for RADIUS (Remote Authentication Dial 700 In User Service). B. Aboba. RFC 3575, July 2003. 702 [RFC3978] IETF Rights in Contributions. S. Bradner, Ed.. March 2005. 704 [RFC3575] IANA Considerations for RADIUS (Remote Authentication Dial 705 In User Service). B. Aboba. July 2003. 707 [RFC3748] Extensible Authentication Protocol (EAP). B. Aboba, L. 708 Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, 709 Ed.. June 2004. 711 [RFC3932] The IESG and RFC Editor Documents: Procedures. H. 712 Alvestrand. October 2004. 714 11. Authors��� Addresses 716 Thomas Narten 717 IBM Corporation 718 3039 Cornwallis Ave. 719 PO Box 12195 - BRQA/502 720 Research Triangle Park, NC 27709-2195 722 Phone: 919-254-7798 723 EMail: narten@us.ibm.com 725 Harald Tveit Alvestrand 726 Cisco Systems 727 5245 Arboretum Dr 728 Los Altos, CA 729 USA 731 Email: Harald@Alvestrand.no 733 Intellectual Property Statement 735 The IETF takes no position regarding the validity or scope of any 736 Intellectual Property Rights or other rights that might be claimed to 737 pertain to the implementation or use of the technology described in 738 this document or the extent to which any license under such rights 739 might or might not be available; nor does it represent that it has 740 made any independent effort to identify any such rights. Information 741 on the procedures with respect to rights in RFC documents can be 742 found in BCP 78 and BCP 79. 744 Copies of IPR disclosures made to the IETF Secretariat and any 745 assurances of licenses to be made available, or the result of an 746 attempt made to obtain a general license or permission for the use of 747 such proprietary rights by implementers or users of this 748 specification can be obtained from the IETF on-line IPR repository at 749 http://www.ietf.org/ipr. 751 The IETF invites any interested party to bring to its attention any 752 copyrights, patents or patent applications, or other proprietary 753 rights that may cover technology that may be required to implement 754 this standard. Please address the information to the IETF at ietf- 755 ipr@ietf.org. 757 Disclaimer of Validity 759 This document and the information contained herein are provided on an 760 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 761 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 762 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 763 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 764 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 765 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 767 Copyright Statement 769 Copyright (C) The Internet Society (2005). 771 This document is subject to the rights, licenses and restrictions 772 contained in BCP 78, and except as set forth therein, the authors 773 retain all their rights. 775 This document and the information contained herein are provided on an 776 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 777 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 778 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 779 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 780 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 781 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.