idnits 2.17.1 draft-ietf-tsvwg-rsvp-user-error-spec-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 362. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Swallow 3 Internet-Draft Cisco Systems, Inc. 4 Category: Standards Track 5 Created: April 28, 2008 A. Farrel 6 Expiration Date: October 28, 2008 Old Dog Consulting 8 User-Defined Errors for RSVP 10 draft-ietf-tsvwg-rsvp-user-error-spec-07.txt 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/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object 38 for communicating errors. That object has a defined format that 39 permits the definition of 256 error codes. As RSVP has been 40 developed and extended, the convention has been to be conservative in 41 defining new error codes. Further, no provision for user-defined 42 errors exists in RSVP. 44 This document defines a USER_ERROR_SPEC to be used in addition to the 45 ERROR_SPEC to carry additional user information related to errors. 47 0. Changes Since Last Revision 49 [This section to be removed before publication as an RFC.] 51 - Clarify 'Enterprise Number'. 52 - Clarify 'Error Description' and give reference for ASCII. 54 1. Introduction 56 The Resource ReserVation Protocol (RSVP) [RFC2205] defines an 57 ERROR_SPEC object for communicating errors. That object has a 58 defined format that permits the definition of 256 error codes. As 59 RSVP has been developed and extended, the convention has been to be 60 conservative in communicating errors. Further no provision for user 61 defined errors exists in RSVP. 63 When developing extensions to RSVP, it is often useful for those 64 implementing to define error messages to aid both in the initial 65 debugging and in testing against older versions or other 66 implementations. 68 This document defines a new RSVP object to permit user-defined errors 69 to be communicated. This will enable organizations to define errors 70 which they can use for internal development. These error values 71 could also be shared with the community at large to aid in promoting 72 interoperability between diverse implementations. 74 RSVP PathErr and ResvErr messages require the presence of an 75 ERROR_SPEC object ([RFC2205]). [RFC3473] defines the Notify message 76 that also requires the presence of an ERROR_SPEC object. In order to 77 not change the mandatory contents of these messages, this document 78 defines a new error code value that indicates that the new object is 79 present and carries a user-defined error code. 81 Note that the ResvConf message defined in [RFC2205] also carries an 82 ERROR_SPEC object. But this usage of the object does not carry 83 meaningful Error Codes or Error Values and so the extensions defined 84 in this document are not applicable to that message. 86 1.1. Conventions 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 2. User-Defined Error 94 A new Error Code is defined for use in an ERROR_SPEC object. 96 Error Code = : User Error Spec 98 This error code is used to signal the presence of a 99 USER_ERROR_SPEC. One Error Value is defined as follows. 101 Error Value 0 = Further details in User Error Spec 103 Further error values may be defined in future specifications. 105 When sending this error code, a USER_ERROR_SPEC object MUST be 106 included in the PathErr, ResvErr, or Notify message. 108 [RFC Editor's note: = to be assigned by IANA as per Section 5. 109 Please replace with the number assigned by IANA and remove 110 this note.] 112 3. USER_ERROR_SPEC Class 114 A new RSVP object class called USER_ERROR_SPEC is defined. To support 115 backwards compatibility, its class number is in the range 192-247. As 116 defined in [RFC2205], implementations that do not understand such an 117 object will forward it unmodified. 119 USER_ERROR_SPEC object: Class = , C-Type = 1 121 [RFC Editor's note: = to be assigned by IANA as per Section 5. 122 Please replace with the number assigned by IANA and remove 123 this note.] 125 0 1 2 3 126 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 127 +---------------+---------------+---------------+---------------+ 128 | Enterprise Number | 129 +---------------+---------------+---------------+---------------+ 130 | Sub Org | Err Desc Len | User Error Value | 131 +---------------+---------------+---------------+---------------+ 132 | | 133 ~ Error Description ~ 134 | | 135 +---------------+---------------+---------------+---------------+ 136 | | 137 ~ User-Defined Subobjects ~ 138 | | 139 +---------------+---------------+---------------+---------------+ 140 Enterprise Number 142 A unique identifier of an organization encoded as a 32-bit 143 integer. Enterprise Numbers (sometimes known as Private 144 Enterprise Numbers) are assigned by IANA and managed on a first 145 come first served basis through the IANA registry named 146 "Enterprise Numbers" [RFC2578]. 148 Sub Org 150 A unique identifier of an organization encoded as an 8-bit 151 integer. An organization MAY use this field to create 152 independent Error Value spaces. This is intended to 153 facilitate teams which are doing parallel development. If 154 independent spaces are not required, this field SHOULD be 155 set to zero. 157 Err Desc Len 159 The length of the error description in the Error Description 160 field in bytes excluding any padding. Zero is a valid length if 161 no error description is supplied. 163 User Error Value 165 A 16-bit integer. The meaning is specified by the 166 (sub-)organization indicated by the Enterprise Number and Sub 167 Org fields. 169 Error Description 171 A string of characters in US-ASCII [ASCII] padded with nulls 172 (0x00) to a multiple of 4 bytes. If the Err Desc Len is zero 173 then no bytes are supplied. 175 Note that the content of this field is implementation-specific. 176 It is typically printable, but might not be shown to all users 177 in all implementations (because it is limited to US-ASCII). 178 Therefore, the content of the field SHOULD be limited to 179 supplementary information and SHOULD NOT contain information 180 critical to operating the network. Criticial information is 181 present in the User Error Value field. 183 User-Defined Subobjects 185 User-defined subobjects MAY be included. The generic format of 186 subobjects is specified in Section 3.1. The semantics of a 187 subobject is indicated by the Type field, but the semantics, 188 format and contents of the Value field are specified by the 189 (sub-)organization indicated by the Enterprise Number and 190 Sub Org fields of this object. 192 3.1. Subobjects 194 Each subobject is encoded as a TLV in the following format: 196 0 1 197 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ 199 | Type | Length | (Subobject contents) | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ 202 Type 204 An 8-bit number assigned by the the (sub-)organization 205 indicated by the Enterprise Number and Sub Org fields of the 206 USER_ERROR_SPEC object. 208 Length 210 The Length contains the total length of the subobject in bytes, 211 including the Type and Length fields. The Length MUST be at 212 least 4, and MUST be a multiple of 4. 214 4. Procedures for Using the User Error Spec 216 4.1. Procedures for Sending the User Error Spec 218 A USER_ERROR_SPEC object MAY be included in any PathErr, ResvErr, or 219 Notify message for any defined error code. The Enterprise Number 220 MUST be a valid value assigned by IANA from the "Enterprise Numbers" 221 registry. 223 As specified in [RFC2205] and [RFC3473], an ERROR_SPEC object with a 224 valid error code MUST be included in all PathErr, ResvErr, and Notify 225 messages. This rule is not changed by these procedures even when a 226 USER_ERROR_SPEC object is included. If no other error code applies, 227 the Error Code in the ERROR_SPEC object MUST be set to "User Error 228 Spec" as defined in Section 2 of this document. When the Error Code 229 in the ERROR_SPEC object is set to "User Error Spec", the Error Value 230 sub-code SHOULD be set to "Further details in User Error Spec" as 231 defined in Section 2, but further Error Value sub-codes may be 232 defined in future specifications. 234 4.2. Procedures for Receiving the User Error Spec 236 It is RECOMMENDED that implementations that receive a PathErr, 237 ResvErr, or Notify message carrying a USER_ERROR_SPEC object at a 238 minimum log the Enterprise Number, Sub-organization, User Error 239 Value, and Error Description. Note that the Error Description is 240 provided in US-ASCII which means that it might not be suitable for 241 display of logging in all systems. Implementations capable of 242 interpreting the contents of the USER_ERROR_SPEC object should take 243 further action based on the reported error. 245 If a message is received containing an ERROR_SPEC object using the 246 "User Error Spec" error code, but not containing a USER_ERROR_SPEC 247 object, the message MUST be treated as malformed and handled 248 according to [RFC2205]. 250 Implementations SHOULD ignore repeated occurences of USER_ERROR_SPEC 251 objects, and SHOULD forward them unchanged on any messages that they 252 forward. This provides for forward compatiblity. 254 Implementations receiving a USER_ERROR_SPEC object on some message 255 other than a PathErr, ResvErr, or Notify message MUST treat the 256 error as a malformed message and process according to [RFC2205]. 258 5. IANA Considerations 260 5.1. RSVP Error Codes 262 This document makes the following assignments from the RSVP Error 263 Codes and Globally-Defined Error Value Sub-Codes registry (pending 264 IANA action): 266 Error Code Meaning 268 User Error Spec 270 One Error Value sub-code is defined for use with this Error Code as 271 follows: 273 0 = Further details in User Error Spec 275 5.2. RSVP Objects 277 This document makes the following assignments from the RSVP Class 278 Names, Class Numbers, and Class Types registry (pending IANA action): 280 Number Space Value Name 282 Class Numbers * User Error Spec 284 Class Type 1 User-Defined Error 286 * Assignment is requested from the range 192 through 247 288 6. Security Considerations 290 This document makes no changes to the basic message exchanges of 291 [RFC2205] and [RFC3473]. It will result in a small increase in the 292 number of error messages sent in cases where messages were previously 293 silently dropped due to the lack of an appropriate error code. 295 The mechanisms defined in this document may be used by 296 implementations to report additional error conditions and information 297 arising from security issues and attacks on the RSVP network. 299 7. Acknowledgments 301 The authors would like to thank Elisheva Halevy for motivating this 302 document. Thanks to Tom Nadeau, Magnus Westerlund, Hannes Tschofenig, 303 Bruce Davie, Jukka Manner, Francois Le Faucheur, Lars Eggert, and Tom 304 Petch for their review and comments. 306 8. References 308 8.1. Normative References 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, March 1997. 313 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 314 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 315 Functional Specification", RFC 2205, September 1997. 317 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 318 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 319 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 321 [ASCII] American National Standards Institute, "USA Code for 322 Information Interchange", ANSI X3.4, 1968. 324 8.1. Informative References 326 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 327 "Structure of Management Information Version 2 (SMIv2)", 328 STD 58, RFC 2578, April 1999. 330 9. Authors' Addresses 332 George Swallow 333 Cisco Systems, Inc. 334 EMail: swallow@cisco.com 336 Adrian Farrel 337 Old Dog Consulting 338 EMail: adrian@olddog.co.uk 340 10. Intellectual Property 342 The IETF takes no position regarding the validity or scope of any 343 Intellectual Property Rights or other rights that might be claimed to 344 pertain to the implementation or use of the technology described in 345 this document or the extent to which any license under such rights 346 might or might not be available; nor does it represent that it has 347 made any independent effort to identify any such rights. Information 348 on the procedures with respect to rights in RFC documents can be 349 found in BCP 78 and BCP 79. 351 Copies of IPR disclosures made to the IETF Secretariat and any 352 assurances of licenses to be made available, or the result of an 353 attempt made to obtain a general license or permission for the use of 354 such proprietary rights by implementers or users of this 355 specification can be obtained from the IETF on-line IPR repository at 356 http://www.ietf.org/ipr. 358 The IETF invites any interested party to bring to its attention any 359 copyrights, patents or patent applications, or other proprietary 360 rights that may cover technology that may be required to implement 361 this standard. Please address the information to the IETF at ietf- 362 ipr@ietf.org. 364 Full Copyright Notice 366 Copyright (C) The IETF Trust (2008). This document is subject to the 367 rights, licenses and restrictions contained in BCP 78, and except as 368 set forth therein, the authors retain all their rights. 370 This document and the information contained herein are provided on an 371 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 372 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 373 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 374 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 375 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 376 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.