idnits 2.17.1 draft-ietf-tsvwg-rsvp-user-error-spec-06.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 372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 345. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 352. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 358. 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 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 5, 2008 A. Farrel 6 Expiration Date: October 5, 2008 Old Dog Consulting 8 User-Defined Errors for RSVP 10 draft-ietf-tsvwg-rsvp-user-error-spec-06.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 - Add names to acknowledgments. 52 - Clarify that the Error Description String does not contain 53 information critical to network operation. 54 - Define an Error Value of zero to accompany the Error Code of 55 "User Error Spec". 57 1. Introduction 59 The Resource ReserVation Protocol (RSVP) [RFC2205] defines an 60 ERROR_SPEC object for communicating errors. That object has a 61 defined format that permits the definition of 256 error codes. As 62 RSVP has been developed and extended, the convention has been to be 63 conservative in communicating errors. Further no provision for user 64 defined errors exists in RSVP. 66 When developing extensions to RSVP, it is often useful for those 67 implementing to define error messages to aid both in the initial 68 debugging and in testing against older versions or other 69 implementations. 71 This document defines a new RSVP object to permit user-defined errors 72 to be communicated. This will enable organizations to define errors 73 which they can use for internal development. These error values 74 could also be shared with the community at large to aid in promoting 75 interoperability between diverse implementations. 77 RSVP PathErr and ResvErr messages require the presence of an 78 ERROR_SPEC object ([RFC2205]). [RFC3473] defines the Notify message 79 that also requires the presence of an ERROR_SPEC object. In order to 80 not change the mandatory contents of these messages, this document 81 defines a new error code value that indicates that the new object is 82 present and carries a user-defined error code. 84 Note that the ResvConf message defined in [RFC2205] also carries an 85 ERROR_SPEC object. But this usage of the object does not carry 86 meaningful Error Codes or Error Values and so the extensions defined 87 in this document are not applicable to that message. 89 1.1. Conventions 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [RFC2119]. 95 2. User-Defined Error 97 A new Error Code is defined for use in an ERROR_SPEC object. 99 Error Code = : User Error Spec 101 This error code is used to signal the presence of a 102 USER_ERROR_SPEC. One Error Value is defined as follows. 104 Error Value 0 = Further details in User Error Spec 106 Further error values may be defined in future specifications. 108 When sending this error code, a USER_ERROR_SPEC object MUST be 109 included in the PathErr, ResvErr, or Notify message. 111 [RFC Editor's note: = to be assigned by IANA as per Section 5. 112 Please replace with the number assigned by IANA and remove 113 this note.] 115 3. USER_ERROR_SPEC Class 117 A new RSVP object class called USER_ERROR_SPEC is defined. To support 118 backwards compatibility, its class number is in the range 192-247. As 119 defined in [RFC2205], implementations that do not understand such an 120 object will forward it unmodified. 122 USER_ERROR_SPEC object: Class = , C-Type = 1 124 [RFC Editor's note: = to be assigned by IANA as per Section 5. 125 Please replace with the number assigned by IANA and remove 126 this note.] 128 0 1 2 3 129 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 130 +---------------+---------------+---------------+---------------+ 131 | Enterprise Number | 132 +---------------+---------------+---------------+---------------+ 133 | Sub Org | Err Desc Len | User Error Value | 134 +---------------+---------------+---------------+---------------+ 135 | | 136 ~ Error Description ~ 137 | | 138 +---------------+---------------+---------------+---------------+ 139 | | 140 ~ User-Defined Subobjects ~ 141 | | 142 +---------------+---------------+---------------+---------------+ 143 Enterprise Number 145 A unique identifier of an organization encoded as a 32-bit 146 integer. Enterprise Numbers are assigned by IANA and managed 147 through an IANA registry [RFC2578]. 149 Sub Org 151 A unique identifier of an organization encoded as an 8-bit 152 integer. An organization MAY use this field to create 153 independent Error Value spaces. This is intended to 154 facilitate teams which are doing parallel development. If 155 independent spaces are not required, this field SHOULD be 156 set to zero. 158 Err Desc Len 160 The length of the error description in the Error Description 161 field in bytes excluding any padding. Zero is a valid length if 162 no error description is supplied. 164 User Error Value 166 A 16-bit integer. The meaning is specified by the 167 (sub-)organization indicated by the Enterprise Number and Sub 168 Org fields. 170 Error Description 172 A string of characters in US-ASCII padded with nulls (0x00) 173 to a multiple of 4 bytes. If the Err Desc Len is zero then 174 no bytes are supplied. 176 Note that the content of this field might not be shown to all 177 users in all implementations (because it is limited to 178 US-ASCII). Therefore, it SHOULD be limited to supplementary 179 information and SHOULD NOT contain information critical to 180 operating the network. Criticial information is present in the 181 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. 222 As specified in [RFC2205] and [RFC3473], an ERROR_SPEC object with a 223 valid error code MUST be included in all PathErr, ResvErr, and Notify 224 messages. This rule is not changed by these procedures even when a 225 USER_ERROR_SPEC object is included. If no other error code applies, 226 the Error Code in the ERROR_SPEC object MUST be set to "User Error 227 Spec" as defined in Section 2 of this document. When the Error Code 228 in the ERROR_SPEC object is set to "User Error Spec", the Error Value 229 sub-code SHOULD be set to "Further details in User Error Spec" as 230 defined in Section 2, but further Error Value sub-codes may be 231 defined in future specifications. 233 4.2. Procedures for Receiving the User Error Spec 235 It is RECOMMENDED that implementations that receive a PathErr, 236 ResvErr, or Notify message carrying a USER_ERROR_SPEC object at a 237 minimum log the Enterprise Number, Sub-organization, User Error 238 Value, and Error Description. Note that the Error Description is 239 provided in US-ASCII which means that it might not be suitable for 240 display of logging in all systems. Implementations capable of 241 interpreting the contents of the USER_ERROR_SPEC object should take 242 further action based on the reported error. 244 If a message is received containing an ERROR_SPEC object using the 245 "User Error Spec" error code, but not containing a USER_ERROR_SPEC 246 object, the message MUST be treated as malformed and handled 247 according to [RFC2205]. 249 Implementations SHOULD ignore repeated occurences of USER_ERROR_SPEC 250 objects, and SHOULD forward them unchanged on any messages that they 251 forward. This provides for forward compatiblity. 253 Implementations receiving a USER_ERROR_SPEC object on some message 254 other than a PathErr, ResvErr, or Notify message MUST treat the 255 error as a malformed message and process according to [RFC2205]. 257 5. IANA Considerations 259 5.1. RSVP Error Codes 261 This document makes the following assignments from the RSVP Error 262 Codes and Globally-Defined Error Value Sub-Codes registry (pending 263 IANA action): 265 Error Code Meaning 267 User Error Spec 269 One Error Value sub-code is defined for use with this Error Code as 270 follows: 272 0 = Further details in User Error Spec 274 5.2. RSVP Objects 276 This document makes the following assignments from the RSVP Class 277 Names, Class Numbers, and Class Types registry (pending IANA action): 279 Number Space Value Name 281 Class Numbers * User Error Spec 283 Class Type 1 User-Defined Error 285 * Assignment is requested from the range 192 through 247 287 6. Security Considerations 289 This document makes no changes to the basic message exchanges of 290 [RFC2205] and [RFC3473]. It will result in a small increase in the 291 number of error messages sent in cases where messages were previously 292 silently dropped due to the lack of an appropriate error code. 294 The mechanisms defined in this document may be used by 295 implementations to report additional error conditions and information 296 arising from security issues and attacks on the RSVP network. 298 7. Acknowledgments 300 The authors would like to thank Elisheva Halevy for motivating this 301 document. Thanks to Tom Nadeau, Magnus Westerlund, Hannes 302 Tschofenig, Bruce Davie, Jukka Manner, Francois Le Faucheur, and Lars 303 Eggert for their review and comments. 305 8. References 307 8.1. Normative References 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, March 1997. 312 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 313 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 314 Functional Specification", RFC 2205, September 1997. 316 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 317 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 318 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 320 8.1. Informative References 322 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 323 "Structure of Management Information Version 2 (SMIv2)", 324 STD 58, RFC 2578, April 1999. 326 9. Authors' Addresses 328 George Swallow 329 Cisco Systems, Inc. 330 EMail: swallow@cisco.com 332 Adrian Farrel 333 Old Dog Consulting 334 EMail: adrian@olddog.co.uk 336 10. Intellectual Property 338 The IETF takes no position regarding the validity or scope of any 339 Intellectual Property Rights or other rights that might be claimed to 340 pertain to the implementation or use of the technology described in 341 this document or the extent to which any license under such rights 342 might or might not be available; nor does it represent that it has 343 made any independent effort to identify any such rights. Information 344 on the procedures with respect to rights in RFC documents can be 345 found in BCP 78 and BCP 79. 347 Copies of IPR disclosures made to the IETF Secretariat and any 348 assurances of licenses to be made available, or the result of an 349 attempt made to obtain a general license or permission for the use of 350 such proprietary rights by implementers or users of this 351 specification can be obtained from the IETF on-line IPR repository at 352 http://www.ietf.org/ipr. 354 The IETF invites any interested party to bring to its attention any 355 copyrights, patents or patent applications, or other proprietary 356 rights that may cover technology that may be required to implement 357 this standard. Please address the information to the IETF at ietf- 358 ipr@ietf.org. 360 Full Copyright Notice 362 Copyright (C) The IETF Trust (2008). This document is subject to the 363 rights, licenses and restrictions contained in BCP 78, and except as 364 set forth therein, the authors retain all their rights. 366 This document and the information contained herein are provided on an 367 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 368 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 369 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 370 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 371 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 372 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.