idnits 2.17.00 (12 Aug 2021) /tmp/idnits46573/draft-narten-iana-considerations-rfc2434bis-01.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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 650. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 666), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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-01' == 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 IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' documented IANA considerations for individual protocols do not always' ) ** 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 (September 16, 2004) is 6455 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 307, but not defined == Missing Reference: 'RFCXXX' is mentioned on line 451, but not defined == Missing Reference: 'RFC 1602' is mentioned on line 480, but not defined ** Obsolete undefined reference: RFC 1602 (Obsoleted by RFC 2026) == Unused Reference: 'DHCP-OPTIONS' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'MIME-LANG' is defined on line 588, 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) Summary: 20 errors (**), 1 flaw (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Thomas Narten 2 IBM 3 Harald Tveit Alvestrand 4 Cisco 5 September 16, 2004 7 Guidelines for Writing an IANA Considerations Section in RFCs 9 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference mate- 26 rial or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft expires March, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 Many protocols make use of identifiers consisting of constants and 43 other well-known values. Even after a protocol has been defined and 44 deployment has begun, new values may need to be assigned (e.g., for a 45 new option type in DHCP, or a new encryption or authentication 46 transform for IPsec). To ensure that such quantities have consistent 47 values and interpretations in different implementations, their 48 assignment must be administered by a central authority. For IETF 49 protocols, that role is provided by the Internet Assigned Numbers 50 Authority (IANA). 52 In order for the IANA to manage a given name space prudently, it 53 needs guidelines describing the conditions under which new values can 54 be assigned. If the IANA is expected to play a role in the management 55 of a name space, the IANA must be given clear and concise 56 instructions describing that role. This document discusses issues 57 that should be considered in formulating a policy for assigning 58 values to a name space and provides guidelines to document authors on 59 the specific text that must be included in documents that place 60 demands on the IANA. 62 Contents 64 Status of this Memo.......................................... 1 66 1. Introduction............................................. 3 68 2. Issues To Consider....................................... 4 70 3. Well-Known IANA Policy Definitions....................... 6 72 4. Registration maintenance................................. 8 74 5. What To Put In Documents................................. 8 75 5.1. When There Are No IANA Actions...................... 9 76 5.2. Requesting Assignments From an Existing Name Space.. 9 77 5.3. Creation of New Registries.......................... 10 79 6. Applicability to Past and Future RFCs.................... 11 81 7. Security Considerations.................................. 12 83 8. Changes Relative to RFC 2434............................. 13 84 8.1. Changes Relative to -00............................. 13 86 9. Acknowledgments.......................................... 13 88 10. References.............................................. 13 90 11. Authors' Addresses...................................... 14 92 1. Introduction 94 Many protocols make use of fields that contain constants and other 95 well-known values (e.g., the Protocol field in the IP header [IP] or 96 MIME types in mail messages [MIME-REG]). Even after a protocol has 97 been defined and deployment has begun, new values may need to be 98 assigned (e.g., a new option type in DHCP [DHCP] or a new encryption 99 or authentication algorithm for IPsec [IPSEC]). To ensure that such 100 fields have consistent values and interpretations in different 101 implementations, their assignment must be administered by a central 102 authority. For IETF protocols, that role is provided by the Internet 103 Assigned Numbers Authority (IANA) [IANA-MOU]. 105 In this document, we call the set of possible values for such a field 106 a "name space"; its actual content may be a name, a number or another 107 kind of value. The assignment of a specific value to a name space is 108 called an assigned number (or assigned value). Each assignment of a 109 number in a name space is called a registration. 111 In order for the IANA to manage a given name space prudently, it 112 needs guidelines describing the conditions under which new values 113 should be assigned. This document provides guidelines to authors on 114 what sort of text should be added to their documents, and reviews 115 issues that should be considered in formulating an appropriate policy 116 for assigning numbers to name spaces. 118 Not all name spaces require centralized administration. In some 119 cases, it is possible to delegate a name space in such a way that 120 further assignments can be made independently and with no further 121 (central) coordination. In the Domain Name System, for example, the 122 IANA only deals with assignments at the higher-levels, while 123 subdomains are administered by the organization to which the space 124 has been delegated. As another example, Object Identifiers (OIDs) as 125 defined by the ITU are also delegated [ASSIGNED]. When a name space 126 can be delegated, the IANA only deals with assignments at the top 127 level. 129 This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their 130 negatives, in the way described in RFC 2119 [KEYWORDS]. In this case, 131 "the specification" as used by RFC 2119 refers to the processing of 132 protocols being submitted to the IETF standards process. 134 2. Issues To Consider 136 One issue to consider in managing a name space is its size. If the 137 space is small and limited in size, assignments must be made 138 carefully to ensure that the space doesn't become exhausted. If the 139 space is essentially unlimited, on the other hand, it may be 140 perfectly reasonable to hand out new values to anyone that wants one. 141 Even when the space is essentially unlimited, however, it is usually 142 desirable to have at least minimal review to prevent the hoarding of 143 or unnecessary wasting of a space. For example, if the space 144 consists of text strings, it may be desirable to prevent 145 organizations from obtaining large sets of strings that correspond to 146 the "best" names (e.g., existing company names). Experience has also 147 shown that some level of minimal review is useful to prevent 148 assignments in cases where the request is malformed or not actually 149 needed (this may not always be immediately obvious to a non-subject- 150 matter expert). 152 A second consideration is whether it makes sense to delegate the name 153 space in some manner. This route should be pursued when appropriate, 154 as it lessens the burden on the IANA for dealing with assignments. 156 A third, and perhaps most important consideration, concerns potential 157 impact on interoperability of unreviewed extensions. Proposed 158 protocol extensions generally benefit from community review; indeed, 159 review is often essential to prevent future interoperability 160 problems. [VENDOR-EXT] discusses this topic in considerable detail. 162 In some cases, the name space is essentially unlimited, there are no 163 potential interoperability issues, and assigned numbers can safely be 164 given out to anyone. When no subjective review is needed, the IANA 165 can make assignments directly, provided that the IANA is given 166 specific instructions on what types of requests it should grant, and 167 what information must be provided before a request for an assigned 168 number will be considered. Note that the IANA will not define an 169 assignment policy; it should be given a set of guidelines that allow 170 it to make allocation decisions with minimal subjectivity. 172 In most cases, some review of prospective allocations is appropriate, 173 and the question becomes who should perform the review and how 174 rigorous the review needs to be. In many cases, one might think that 175 an IETF Working Group (WG) familiar with the name space at hand 176 should be consulted. In practice, however, WGs eventually disband, so 177 they cannot be considered a permanent evaluator. It is also possible 178 for name spaces to be created through individual submission 179 documents, for which no WG is ever formed. 181 One way to ensure community review of prospective assignments is to 182 have the requester submit a document for publication as an RFC. Such 183 an action helps ensure that the IESG and relevant WGs review the 184 assignment. [XXX update wrt draft-iesg-rfced-documents?] This is the 185 preferred way of ensuring review, and is particularly important if 186 any potential interoperability issues can arise. For example, many 187 assignments are not just assignments, but also involve an element of 188 protocol specification. A new option may define fields that need to 189 be parsed and acted on, which (if specified poorly) may not fit 190 cleanly with the architecture of other options or the base protocols 191 on which they are built. 193 In some cases, however, the burden of publishing an RFC in order to 194 get an assignment is excessive. However, it is generally still useful 195 (and sometimes necessary) to discuss proposed additions on a mailing 196 list dedicated to the purpose (e.g., the ietf-types@iana.org for 197 media types) or on a more general mailing list (e.g., that of a 198 current or former IETF WG). Such a mailing list provides a way for 199 new registrations to be publicly reviewed prior to getting assigned, 200 or to give advice for persons who want help in understanding what a 201 proper registration should contain. 203 While discussion on a mailing list can provide valuable technical 204 expertise, opinions may vary and discussions may continue for some 205 time without clear resolution. In addition, the IANA cannot 206 participate in all of these mailing lists and cannot determine if or 207 when such discussions reach consensus. Therefore, the IANA cannot 208 allow general mailing lists to fill the role of providing definitive 209 recommendations regarding a registration question. Instead, the IANA 210 will rely on a "designated expert" to advise it in assignment 211 matters. That is, the IANA forwards the requests it receives to a 212 specific point-of-contact (one or a small number of individuals) and 213 acts upon the returned recommendation from the designated expert. The 214 designated expert can initiate and coordinate as wide a review of an 215 assignment request as may be necessary to evaluate it properly. 217 Designated experts are appointed by the relevant Area Director of the 218 IESG. They are typically named at the time a document that creates a 219 new numbering space is published as an RFC, but as experts originally 220 appointed may later become unavailable, the relevant Area Director 221 will appoint replacements if necessary. 223 Any decisions made by the designated expert can be appealed using the 224 normal IETF appeals process as outlined in Section 6.5 of [IETF- 225 PROCESS]. Since the designated experts are appointed by the IESG, 226 they may be removed by the IESG. 228 3. Well-Known IANA Policy Definitions 230 The following are some defined policies, some of which are in use 231 today. These cover a range of typical policies that have been used to 232 date. It is not required that documents use these terms; the actual 233 requirement is that the instructions to IANA are clear and 234 unambigous. However, it is preferable to use these terms where 235 possible, since there meaning is widely understood. 237 Private Use - For private or local use only, with the type and 238 purpose defined by the local site. No attempt is made to 239 prevent multiple sites from using the same value in 240 different (and incompatible) ways. There is no need for 241 IANA to review such assignments and assignments are not 242 generally useful for interoperability. 244 Examples: Site-specific options in DHCP [DHCP] have 245 significance only within a single site. "X-foo:" header 246 lines in email messages. 248 Experimental Use - Similar to private or local use only, with the 249 purpose being to facilitate experimentation. See 250 [EXPERIMENTATION] for details. 252 Hierarchical allocation - Delegated managers can assign values 253 provided they have been given control over that part of the 254 name space. IANA controls the higher levels of the 255 namespace according to one of the other policies. 257 Examples: DNS names, Object Identifiers 259 First Come First Served - Anyone can obtain an assigned number, so 260 long as they provide a point of contact and a brief 261 description of what the value would be used for. For 262 numbers, the exact value is generally assigned by the IANA; 263 with names, specific names are usually requested. 265 Examples: vnd. (vendor assigned) MIME types [MIME-REG], TCP 266 and UDP port numbers. 268 Expert Review (or Designated Expert) - approval by a Designated 269 Expert is required. 271 Specification Required - Values and their meaning must be 272 documented in an RFC or other permanent and readily 273 available reference, in sufficient detail so that 274 interoperability between independent implementations is 275 possible. 277 Examples: SCSP [SCSP] 279 IESG Approval - New assignments must be approved by the IESG. 280 Although there is no requirement that the request be 281 documented in an RFC, the IESG has discretion to request 282 documents or other supporting materials on a case-by-case 283 basis. 285 IETF Review - (Formerly "IETF Consensus" [IANA-CONSIDERATIONS]) 286 New values are assigned only through RFC publication of 287 documents that have been shepherded through the IESG as AD- 288 Sponsored documents [XXX need ref]. The intention is that 289 the document and proposed assignment will be reviewed by 290 the IESG and appropriate IETF WGs (or experts, if suitable 291 working groups no longer exist) to ensure that the proposed 292 assignment will not negatively impact interoperability or 293 otherwise extend IETF protocols in an inappropriate manner. 295 [XXX: should an explicit last call be required?] 297 Examples: SMTP extensions [SMTP-EXT], BGP Subsequent 298 Address Family Identifiers [BGP4-EXT]. 300 Standards Action - Values are assigned only for Standards Track 301 RFCs approved by the IESG. 303 Examples: MIME top level types [MIME-REG] 305 It should be noted that it often makes sense to partition a name 306 space into several categories, with assignments out of each category 307 handled differently. For example, the DHCP option space [DHCP] is 308 split into two parts. Option numbers in the range of 1-127 are 309 globally unique and assigned according to the Specification Required 310 policy described above, while options number 128-254 are "site 311 specific", i.e., Private Use. Dividing the name space up makes it 312 possible to have different policies in place for different ranges. 314 4. Registration maintenance 316 Registrations are a request for an assigned number, including the 317 related information needed to evaluate and document the request. Even 318 after a number has been assigned, some types of registrations contain 319 additional information that may need to be updated over time. For 320 example, mime types, character sets, language tags, etc. typically 321 include more information than just the registered value itself. 322 Example information can include point of contact information, 323 security issues, pointers to updates, literature references, etc. In 324 such cases, the document must clearly state who is responsible for 325 maintaining and updating a registration. It is appropriate to: 327 - Let the author update the registration, subject to the same 328 constraints and review as with new registrations. 330 - Allow some mechanism to attach comments to the registration, for 331 cases where others have significant objections to claims in a 332 registration, but the author does not agree to change the 333 registration. 335 - Designate the IESG or another authority as having the right to 336 reassign ownership of a registration. This is mainly to get 337 around the problem when some registration owner cannot be 338 reached in order to make necessary updates. 340 5. What To Put In Documents 342 The previous sections presented some issues that should be considered 343 in formulating a policy for assigning well-known numbers and other 344 protocol constants. It is the Working Group and/or document author's 345 job to formulate an appropriate policy and specify it in the 346 appropriate document. In almost all cases, having an explicit "IANA 347 Considerations" section is appropriate. The following subsections 348 define what is needed for the different types of IANA actions. 350 5.1. When There Are No IANA Actions 352 Before an Internet-Draft can be published as an RFC, IANA needs to 353 know what actions (if any) it needs to perform. Experience has shown 354 that it is not always immediately obvious whether a document has no 355 IANA actions, without reviewing a document in some detail. In order 356 to make it clear to IANA that it has no actions to perform (and that 357 the author has consciously made such a determination!), such docu- 358 ments should include an IANA Considerations section that states: 360 This document has no IANA Actions. 362 5.2. Requesting Assignments From an Existing Name Space 364 Often, a document requests the assignment of a code point from an 365 already existing name space (i.e., one created by a previously-pub- 366 lished RFC). In such cases documents should make clear: 368 - From what name space is a value is being requested? List the exact 369 name space listed on the IANA web page (and RFC), and cite the RFC 370 where the name space is defined. (Note: There is no need to men- 371 tion what the allocation policy for new assignments is, as that 372 should be clear from the references.) 374 - For each value being requested, give it a unique name, e.g., TBD1, 375 TBD2, etc. Throughout the document where the actual IANA-assigned 376 value should be filled in, use "TDBx" notation. This helps ensure 377 that the final RFC has the correct assigned value filled in in all 378 of the relevant places where the value is listed in the final doc- 379 ument. 381 - Normally, the values to be used are chosen by IANA; documents 382 shouldn't pick values themselves. However, in some cases a value 383 may have been used for testing or in early implementations. In 384 such cases, it is acceptable to include text suggesting what spe- 385 cific value should be used (e.g., include the text "the value XXX 386 is suggested"). However, it should be noted that suggested values 387 are just that; IANA will attempt to assign them, but may find that 388 impossible, if the proposed number has already been assigned for 389 some other use. 391 - The IANA Considerations section should summarize all of the IANA 392 actions, with pointers to the relevant sections as appropriate. 393 When multiple values are requested, it is generally helpful to 394 include a summary table. 396 As an example, the following text could be used to request assignment 397 of a DHCPv6 option number: 399 IANA has assigned an option code value of TBD1 to the DNS Recur- 400 sive Name Server option and an option code value of TBD2 to the 401 Domain Search List option from the DHCP option code space defined 402 in section 24.3 of RFC 3315. 404 5.3. Creation of New Registries 406 Documents that create a new name space (or modify the definition of 407 an existing space) and that expect the IANA to play a role in main- 408 taining that space (e.g., serving as a repository for registered val- 409 ues) MUST provide clear instructions on details of the name space. In 410 particular, instructions MUST include: 412 1) The name of the registry being created and/or maintained. The 413 name will appear on the IANA web page and will be refered to in 414 future Internet Drafts that need to allocate a value from the 415 new space. 417 2) What information must be provided in order to assign a new 418 value. 420 3) The process through which future assignments are made (see Sec- 421 tion 3). 423 Note: When a Designated Expert is used, documents MUST NOT name 424 the Designated Expert in the document itself; instead, the name 425 should be relayed to the appropriate IESG Area Director at the 426 time the document is sent to the IESG for approval. 428 If the request should also be reviewed on a specific public 429 mailing list (such as the ietf-types@iana.org for media types), 430 that mailing address should be specified. Note, however, that 431 use of a Designated Expert MUST also be specified. 433 If the IANA is expected to make assignments without requiring an 434 outside review, sufficient guidance MUST be provided so that the 435 requests can be evaluated with minimal subjectivity. 437 When specifying the process for making future assignments, it is 438 quite acceptable to pick one of the example policies listed in Sec- 439 tion 3 and refer to it by name. Indeed, this is the preferred mecha- 440 nism in those cases where the sample policies provide the desired 441 level of review. It is also acceptable to cite one of the above poli- 442 cies and include additional guidelines for what kind of considera- 443 tions should be taken into account by the review process. For exam- 444 ple, RADIUS [RFC3575] specifies the use of a Designated Expert, but 445 includes additional criteria the Designated Expert should follow. 447 For example, a document could say something like: 449 This document defines a new DHCP option, entitled "FooBar" (see 450 Section y), assigned a value of TBD1 from the DCHP Option space 451 [RFCXXX]. The FooBar option also contains an 8-bit FooType 452 field, for which IANA is to create and maintain a registry enti- 453 tled "FooType values". Initial values for FooType field are 454 given below; future assignments are to be made through Expert 455 Review [IANA-CONSIDERATIONS]. Assignments consist of a name and 456 the value. 458 Name Value Definition 459 ---- ----- ---------- 460 Frobnitz 1 See Section y.1 461 NitzFrob 2 See Section y.2 463 For examples of documents that provide good and detailed guidance to 464 the IANA on the issue of assigning numbers, consult [MIME-REG, MIME- 465 LANG, RFC3757, RFC3749, RFC3575]. 467 6. Applicability to Past and Future RFCs 469 For all existing RFCs that either explicitly or implicitly rely on 470 the IANA to evaluate assignments without specifying a precise 471 evaluation policy, the IANA (in consultation with the IESG) will 472 continue to decide what policy is appropriate. Changes to existing 473 policies can always be initiated through the normal IETF consensus 474 process. 476 Any decisions made by the IANA can be appealed using the normal IETF 477 appeals process as outlined in Section 6.5 of [IETF-PROCESS]. 478 Specifically, appeals should be directed to the IESG, followed (if 479 necessary) by an appeal to the IAB. By virtue of the IAB's role as 480 overseer of IANA administration [RFC 1602], the IAB's decision is 481 final. 483 All future RFCs that either explicitly or implicitly rely on the IANA 484 to register or otherwise manage assignments MUST provide guidelines 485 for managing the name space. 487 [XXX: following is new text w.r.t. 2434. Is this something that is 488 appropriate to include??] 490 Since RFC 2434 was published, experience has shown that the 491 documented IANA considerations for individual protocols do not always 492 adequately cover the reality on the ground. For example, many older 493 routing protocols do not have documented, detailed IANA 494 considerations. In addition, documented IANA considerations are 495 sometimes found to be too stringent to allow even working group 496 documents (for which there is strong consensus) to obtain code points 497 from IANA in advance of actual RFC publication. In other cases, the 498 documented procedures are unclear or neglected to cover all the 499 cases. In order to allow assignments in individual cases where there 500 is strong IETF consensus that an allocation should go forward, but 501 the documented procedures do not support such an assignment, the IESG 502 is granted authority to approve assignments in such cases. The 503 intention is not to overule documented procedures, or to obviate the 504 need for protocols to properly document their IANA Considerations, 505 but to permit assignments in individual cases where it is obvious 506 that the assignment should just be made, but updating the IANA 507 process just to assign a particular code point is viewed as too heavy 508 a burden. 510 7. Security Considerations 512 Information that creates or updates a registration needs to be 513 authenticated. 515 Information concerning possible security vulnerabilities of a 516 protocol may change over time. Likewise, security vulnerabilities 517 related to how an assigned number is used (e.g., if it identifies a 518 protocol) may change as well. As new vulnerabilities are discovered, 519 information about such vulnerabilities may need to be attached to 520 existing registrations, so that users are not mislead as to the true 521 security issues surrounding the use of a registered number. 523 An analysis of security issues is required for all parameters (data 524 types, operation codes, keywords, etc.) used in IETF protocols or 525 registered by the IANA. All descriptions of security issues must be 526 as accurate as possible regardless of level of registration. In 527 particular, a statement that there are "no security issues associated 528 with this type" must not given when it would be more accurate to 529 state that "the security issues associated with this type have not 530 been assessed". 532 8. Changes Relative to RFC 2434 534 TBD 536 8.1. Changes Relative to -00 538 - Revised Section 5.3 to try and make it even more clear. 540 9. Acknowledgments 542 From RFC 2434: 544 Jon Postel and Joyce Reynolds provided a detailed explanation on what 545 the IANA needs in order to manage assignments efficiently, and 546 patiently provided comments on multiple versions of this document. 547 Brian Carpenter provided helpful comments on earlier versions of the 548 document. One paragraph in the Security Considerations section was 549 borrowed from [MIME-REG]. 551 10. References 553 [ASSIGNED] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, 554 RFC 1700, October 1994. See also: 555 http://www.iana.org/numbers.html 557 [BGP4-EXT] Bates. T., Chandra, R., Katz, D. and Y. Rekhter, 558 "Multiprotocol Extensions for BGP-4", RFC 2283, 559 February 1998. 561 [DHCP-OPTIONS] Alexander, S. and R. Droms, "DHCP Options and BOOTP 562 Vendor Extensions", RFC 2132, March 1997. 564 [EXPERIMENTATION] "Assigning Experimental and Testing Numbers 565 Considered Useful". T. Narten, RFC 3692, January 566 2004. 568 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 569 Writing an IANA Considerations Section in RFCs", BCP 570 26, RFC 2434, October 1998. 572 [IANA-MOU] Memorandum of Understanding Concerning the Technical Work 573 of the Internet Assigned Numbers Authority. B. 574 Carpenter, F. Baker, M. Roberts, RFC 2860, June 575 2000. 577 [IETF-PROCESS] Bradner, S., "The Internet Standards Process -- 578 Revision 3", BCP 9, RFC 2026, October 1996. 580 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 582 [IPSEC] Atkinson, R., "Security Architecture for the Internet 583 Protocol", RFC 1825, August 1995. 585 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 586 Requirement Levels", BCP 14, RFC 2119, March 1997. 588 [MIME-LANG] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 589 Word Extensions: Character Sets, Languages, and 590 Continuations", RFC 2184, August 1997. 592 [MIME-REG] Freed, N., Klensin, J. and J. Postel, "Multipurpose 593 Internet Mail Extension (MIME) Part Four: 594 Registration Procedures", RFC 2048, November 1996. 596 [SCSP] Luciani, J., Armitage, G. and J. Halpern, "Server Cache 597 Synchronization Protocol (SCSP)", RFC 2334, April 598 1998. 600 [SMTP-EXT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. 601 Crocker, "SMTP Service Extensions", RFC 1869, 602 November 1995. 604 [VENDOR-EXT] "Considerations on the Extensibility of IETF protocols", 605 draft-iesg-vendor-extensions-02.txt 607 [RFC3575] IANA Considerations for RADIUS (Remote Authentication Dial 608 In User Service). B. Aboba. RFC 3575, July 2003. 610 11. Authors' Addresses 612 Thomas Narten 613 IBM Corporation 614 3039 Cornwallis Ave. 615 PO Box 12195 - BRQA/502 616 Research Triangle Park, NC 27709-2195 618 Phone: 919-254-7798 619 EMail: narten@us.ibm.com 620 Harald Tveit Alvestrand 621 Cisco Systems 622 5245 Arboretum Dr 623 Los Altos, CA 624 USA 626 Email: Harald@Alvestrand.no 628 Intellectual Property Statement 630 The IETF takes no position regarding the validity or scope of any 631 Intellectual Property Rights or other rights that might be claimed to 632 pertain to the implementation or use of the technology described in 633 this document or the extent to which any license under such rights 634 might or might not be available; nor does it represent that it has 635 made any independent effort to identify any such rights. Information 636 on the procedures with respect to rights in RFC documents can be 637 found in BCP 78 and BCP 79. 639 Copies of IPR disclosures made to the IETF Secretariat and any assur- 640 ances of licenses to be made available, or the result of an attempt 641 made to obtain a general license or permission for the use of such 642 proprietary rights by implementers or users of this specification can 643 be obtained from the IETF on-line IPR repository at 644 http://www.ietf.org/ipr. 646 The IETF invites any interested party to bring to its attention any 647 copyrights, patents or patent applications, or other proprietary 648 rights that may cover technology that may be required to implement 649 this standard. Please address the information to the IETF at ietf- 650 ipr@ietf.org. 652 Disclaimer of Validity 654 This document and the information contained herein are provided on an 655 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 656 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 657 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 658 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 659 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 660 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 662 Copyright Statement 664 Copyright (C) The Internet Society (2004). This document is subject 665 to the rights, licenses and restrictions contained in BCP 78, and 666 except as set forth therein, the authors retain all their rights.