idnits 2.17.1 draft-kompella-rsvp-change-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2205, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3209, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC2205, updated by this document, for RFC5378 checks: 1997-09-01) -- 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 (May 2004) is 7286 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kompella 3 Internet Draft Juniper Networks 4 Updates: 2205 3209 J. Lang 5 Category: Best Current Practice Rincon Networks 6 Expires: November 2004 May 2004 8 Procedures for Modifying RSVP 9 draft-kompella-rsvp-change-02.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This memo specifies procedures for modifying the Resource reSerVation 39 Protocol (RSVP). This memo also lays out new assignment guidelines 40 for number spaces for RSVP messages, object classes, class-types and 41 sub-objects. 43 Conventions used in this document 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 49 1. Introduction 51 This memo specifies procedures for modifying the Resource reSerVation 52 Protocol (RSVP) [RSVP], including (but not limited to) adding, 53 updating, extending or making obsolete: messages, message formats and 54 procedures; object classes and class types, object formats and 55 procedures; header formats; error codes and subcodes and semantics; 56 and procedures for sending, receiving and addressing RSVP messages. 58 IANA recognizes the following RSVP name spaces: Message Types; Class 59 Names, Class Numbers, Class Types and Sub-objects; Virtual 60 Destination Ports; and Error Codes and (Subcode) Values (all of these 61 will collectively be referred to as RSVP entities in this document). 62 This memo specifies for each name space ranges and assignment 63 policies for each range. New RSVP name spaces must be defined in a 64 Standards Track RFC which include guidelines for IANA assignments 65 within the new name spaces. 67 The assignment policies used in this document are: Standards Action 68 (as defined in [IANA]), Expert Review and Vendor Private; the last 69 two are defined in this document. The intent of these assignment 70 policies is to ensure that extensions to RSVP receive adequate review 71 before code-points are assigned, without being overly rigid. Thus, 72 if an extension is widely accepted and its ramifications are well 73 understood, it may receive an assignment from the Standards Action 74 space; however, if an extension is experimental in nature, it 75 receives an assignment from the Expert Review space, and may, with 76 maturity, move to Standards Track. Assignments from the Vendor 77 Private space are not reviewed, but there are mechanisms in place to 78 ensure that these codepoints can co-exist in a network without harm. 80 A standards body other than the IETF that wishes to obtain an 81 assignment for an RSVP entity must decide from which type of 82 name/number space they desire their assignment be made from, and then 83 submit the appropriate documentation. For example, if the assignment 84 is to be made from a number space designated as Standards Action, a 85 Standards Track RFC MUST be submitted in support of the request for 86 assignment. 88 This memo updates the IANA Considerations section (section 7) of 89 [RSVP-TE], replacing the assignment policies stated there. 91 2. Assignment Policies for RSVP Entities 93 For each of the RSVP name spaces identified by IANA, the space is 94 divided into assignment ranges; the following terms are used in 95 describing the procedures by which IANA assigns values: "Standards 96 Action" (as defined in [IANA]); "Expert Review" and "Vendor Private 97 Use", defined below. 99 "Expert Review" ranges refer to values that are to be reviewed by an 100 Expert designated by the IESG. The code points from these ranges are 101 typically used for experimental extensions; such assignments MUST be 102 requested by Experimental RFCs that document their use and 103 processing, and the actual assignments made during the IANA actions 104 for the document. Values from "Expert Review" ranges MUST be 105 registered with IANA. 107 "Vendor Private" ranges refer to values that are enterprise-specific; 108 these MUST NOT be registered with IANA. For Vendor Private values, 109 the first 4-octet word of the data field MUST be an enterprise code 110 [ENT] as registered with the IANA SMI Network Management Private 111 Enterprise Codes, and the rest of the data thereafter is for the 112 private use of the registered enterprise. (For each RSVP entity that 113 has a Vendor Private range, it must be specified where exactly the 114 data field starts; see below for examples.) In this way, different 115 enterprises, vendors or Standards Development Organizations (SDOs) 116 can use the same code point without fear of collision. 118 2.1. Message Types 120 A Message Type is an 8-bit number that identifies the function of the 121 RSVP message. Values from 0 through 239 are to be assigned by 122 Standards Action. Values from 240 through 255 are to be assigned by 123 Expert Review. 125 2.2. Class Names and Numbers 127 Each class of data object in an RSVP message is identified by an all 128 upper-case Class Name and an 8-bit Class Number (also known as 129 Class-Num or C-Num). Class Numbers are divided broadly into three 130 ranges (0-127, 128-191, and 192-255) determined by the two high-order 131 bits of the Class-Num object (the 'b' below represents a bit). 133 Note: the first 32-bit word of an Object whose Class-Num or 134 Class-Type is from the Vendor Private range MUST be that vendor's SMI 135 enterprise code in network octet order (these enterprise codes can be 136 obtained from, and registered with, IANA). An implementation 137 encountering a Vendor Private object with an SMI enterprise code that 138 it does not recognize MUST treat that object (and enclosing message) 139 based on the Class-Num, as specified in [RSVP], section 3.10. 141 o Class-Num = 0bbbbbbb 143 Class Numbers from 0 through 119 are to be assigned by 144 Standards Action. Class Numbers from 120 through 123 are to be 145 assigned by Expert Review. Class Numbers from 124 through 127 146 are reserved for Vendor Private Use. 148 o Class-Num = 10bbbbbb 150 Class Numbers from 128 through 183 are to be assigned by 151 Standards Action. Class Numbers from 184 through 187 are to be 152 assigned by Expert Review. Class Numbers from 188 through 191 153 are reserved for Vendor Private Use. 155 o Class-Num = 11bbbbbb 157 Class Numbers from 192 through 247 are to be assigned by 158 Standards Action. Class Numbers from 248 through 251 are to be 159 assigned by Expert Review. Class Numbers from 252 through 255 160 are reserved for Vendor Private Use. 162 2.3. Class Types 164 Within each object class there is an 8-bit Class Type (also known as 165 a C-Type). Class Types are scoped to a Class Number. In general, 166 the appropriateness of allowing assignments of Class Types through 167 Expert Review or Vendor Private depends on the semantics of the Class 168 Number itself. Thus, any new Class Number definition must specify an 169 appropriate IANA Considerations policy for assigning additional Class 170 Type values. 172 For Class Numbers that pre-date this document (specifically, 0, 1, 173 3-25, 30-37, 42-45, 64, 65, 128-131, 161-165, 192-196 and 207), the 174 default assignment policy for new Class Types is Standards Action, 175 unless a Standards Track or Best Current Practice RFC supercedes 176 this. 178 2.3.1. Sub-objects 180 Within an object, sub-objects may be defined, generally as a 181 Type-Length-Value triple. This memo defines the assignment policies 182 for sub-objects of EXPLICIT_ROUTE and RECORD_ROUTE. An RFC defining 183 new sub-objects MUST state how IANA is to assign the sub-object 184 Types. 186 The EXPLICIT_ROUTE object [RSVP-TE] carries a variable length 187 sub-object that is identified by a 7-bit Type field. Types 0 through 188 119 are to be assigned by Standards Action. Types 120 through 123 189 are to be assigned by Expert Review. Types 124 through 127 are to be 190 reserved for Vendor Private Use. 192 The RECORD_ROUTE object [RSVP-TE] carries a variable length 193 sub-object that is identified by an 8-bit Type field. Types 0 194 through 191 are to be assigned by Standards Action. Types 192 through 195 251 are to be assigned by Expert Review. Types 252 through 255 are 196 to be reserved for Vendor Private Use. 198 The first four octets of the sub-object contents of a Vendor Private 199 sub-object of an EXPLICIT_ROUTE or RECORD_ROUTE object MUST be that 200 vendor's SMI enterprise code in network octet order. 202 2.4. Virtual Destination Ports 204 Virtual destination ports are described in [RSVP-IPSEC], which also 205 specifies how IANA assignments are to be made. 207 2.5. Error Codes and Values 209 An Error Code is an 8-bit quantity that appears in an ERROR_SPEC 210 object to broadly define an error condition. With each Error Code 211 there may be a 16-bit Error Value that further specifies the cause of 212 the error. Error Value may be globally defined, in which case the 213 sub-code component is assigned by IANA. 215 Error Code values from 0 through 239 are to be assigned by Standards 216 Action. Values from 240 through 251 are to be assigned by Expert 217 Review. Values from 252 through 255 are reserved for Vendor Private 218 Use. If the Error Code is for Vendor Private Use, the first four 219 octets following the Error Value MUST be the vendor's SMI enterprise 220 code in network octet order. 222 Globally defined Error Values are assigned by Standards Action. 224 3. Modifying RSVP Procedures 226 RSVP entities have associated procedures describing when and how they 227 are to be sent, received, processed and responded to. A change to a 228 procedure that affects the processing of an RSVP entity that belongs 229 to a range designated "Standards Action" MUST be documented in a 230 Standards Track RFC. A change to a procedure that affects the 231 processing of an RSVP entity that belongs to a range designated 232 "Expert Review" MUST be documented in an Experimental RFC. 234 Acknowledgments 236 Many thanks to Scott Bradner, who encouraged this project, and made 237 several helpful comments and suggestions. 239 Security Considerations 241 It is hoped that the procedures outlined in this memo will ensure 242 that changes made to RSVP will be better reviewed and thus be more 243 architecturally sound, thereby enhancing the security both of the 244 protocol and of networks deploying it. 246 IANA Considerations 248 See section 2. 250 Normative References 252 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119, March 1997 255 [RSVP] Braden, R. Ed., L. Zhang, S. Berson, S. Herzog, and S. Jamin, 256 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 257 Specification", RFC 2205, September 1997. 259 [RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., and Swallow, G., 260 "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209, December 261 2001. 263 Informative References 265 [ENT] IANA PRIVATE ENTERPRISE NUMBERS, 266 http://www.iana.org/assignments/enterprise-numbers 268 [IANA] Narten, T. and H. Alvestrand, "Guidelines for IANA 269 Considerations", BCP 26, RFC 2434, October 1998. 271 [RSVP-IPSEC] Berger, L., and T. O'Malley, "RSVP Extensions for IPSEC 272 Data Flows", RFC 2207, September 1997. 274 Authors' Addresses 276 Kireeti Kompella 277 Juniper Networks 278 1194 N. Mathilda Ave 279 Sunnyvale, CA 94089 USA 280 Email: kireeti@juniper.net 282 Jonathan P. Lang 283 Rincon Networks 284 Email: jplang@ieee.org 286 Full Copyright Notice 288 Copyright (C) The Internet Society (2004). All Rights Reserved. 290 This document and translations of it may be copied and furnished to 291 others, and derivative works that comment on or otherwise explain it 292 or assist in its implementation may be prepared, copied, published 293 and distributed, in whole or in part, without restriction of any 294 kind, provided that the above copyright notice and this paragraph are 295 included on all such copies and derivative works. However, this 296 document itself may not be modified in any way, such as by removing 297 the copyright notice or references to the Internet Society or other 298 Internet organizations, except as needed for the purpose of 299 developing Internet standards in which case the procedures for 300 copyrights defined in the Internet Standards process must be 301 followed, or as required to translate it into languages other than 302 English. 304 The limited permissions granted above are perpetual and will not be 305 revoked by the Internet Society or its successors or assigns. 307 This document and the information contained herein is provided on an 308 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 309 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 310 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 311 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 312 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 314 Acknowledgement 316 Funding for the RFC Editor function is currently provided by the 317 Internet Society.