idnits 2.17.1 draft-ietf-tsvwg-rsvp-user-error-spec-02.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 346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 332. 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: October 6, 2007 A. Farrel 6 Expiration Date: April 6, 2007 Old Dog Consulting 8 User-Defined Errors for RSVP 10 draft-ietf-tsvwg-rsvp-user-error-spec-02.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 Contents 46 1 Introduction .............................................. 3 47 1.1 Conventions ............................................... 3 48 2 User-Defined Error ........................................ 3 49 3 USER_ERROR_SPEC Class ..................................... 4 50 3.1 Subobjects ................................................ 5 51 4 Procedures for Using the User Error Spec .................. 6 52 4.1 Procedures for Sending the User Error Spec ................ 6 53 4.2 Procedures for Receiving the User Error Spec .............. 6 54 5 IANA Considerations ....................................... 6 55 6 Security Considerations ................................... 7 56 7 Acknowledgments ........................................... 7 57 8 Normative References ...................................... 7 58 9 Authors' Addresses ........................................ 8 60 0. Changes Since Last Revision 62 [This section to be removed before publication as an RFC.] 64 - Use explicit tags for values to be supplied by IANA. 65 Sections 2, 3 and 5. 67 - Definition of Length field mentioned non-existent L field. 68 Section 3.1. 70 1. Introduction 72 The Resource ReserVation Protocol (RSVP) [RFC2205] defines an 73 ERROR_SPEC object for communicating errors. That object has a 74 defined format that permits the definition of 256 error codes. As 75 RSVP has been developed and extended, the convention has been to be 76 conservative in communicating errors. Further no provision for user 77 defined errors exists in RSVP. 79 When developing extensions to RSVP, it is often useful for those 80 implementing to define error messages to aid both in the initial 81 debugging and in testing against older versions or other 82 implementations. 84 This document defines a new RSVP object to permit user-defined errors 85 to be communicated. This will enable organizations to define errors 86 which they can use for internal development. These error values 87 could also be shared with the community at large to aid in promoting 88 interoperability between diverse implementations. 90 RSVP PathErr and ResvErr messages require the presence of an 91 ERROR_SPEC object ([RFC2205]). [RFC3473] defines the Notify message 92 that also requires the presence of an ERROR_SPEC object. In order to 93 not change the mandatory contents of these messages, this document 94 defines a new error code value that indicates that the new object is 95 present and carries a user-defined error code. 97 1.1. Conventions 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 2. User-Defined Error 105 A new Error Code is defined for use in an ERROR_SPEC object. 107 Error Code = : User Error Spec 109 This error code is used to signal the presence of a 110 USER_ERROR_SPEC. No subcodes are defined. 112 When sending this error code, a USER_ERROR_SPEC object MUST be 113 included in the PathErr, ResvErr, or Notify message. 115 [RFC Editor's note: = to be assigned by IANA as per Section 5. 116 Please replace with the number assigned by IANA and remove 117 this note.] 119 3. USER_ERROR_SPEC Class 121 A new RSVP object class is defined called the the USER_ERROR_SPEC 122 Class. The class number is taken from the range 192 - 247. This is 123 done for backward compatibility. Existing implementations will 124 ignore the object and pass it along according to the rules of 125 [RFC2205]. 127 USER_ERROR_SPEC object: Class = , C-Type = 1 129 [RFC Editor's note: = to be assigned by IANA as per Section 5. 130 Please replace with the number assigned by IANA and remove 131 this note.] 133 0 1 2 3 134 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 135 +---------------+---------------+---------------+---------------+ 136 | Enterprise Number | 137 +---------------+---------------+---------------+---------------+ 138 | Sub Org | Err Desc Len | User Error Value | 139 +---------------+---------------+---------------+---------------+ 140 | | 141 ~ Error Description ~ 142 | | 143 +---------------+---------------+---------------+---------------+ 144 | | 145 ~ User-Defined Subobjects ~ 146 | | 147 +---------------+---------------+---------------+---------------+ 149 Enterprise Number 151 A unique identifier of an organization encoded as a 32-bit 152 integer. Enterprise Numbers are assigned by IANA. 154 Sub Org 156 A unique identifier of an organization encoded as an 8-bit 157 integer. An organization MAY use this field to create 158 independent Error Value spaces. This is intended to 159 facilitate teams which are doing parallel development. If 160 independent spaces are not required, this field SHOULD be 161 set to zero. 163 Err Desc Len 165 The length of the error description in the Error Description 166 field in bytes excluding any padding. 168 User Error Value 170 A 16-bit integer. The format and contents are specified by 171 the (sub-)organization indicated by the Enterprise Number 172 and Sub Org fields. 174 Error Description 176 A string of characters in US-ASCII padded with nulls (0x00) 177 to a multiple of 4 bytes. While no format is required, it 178 is RECOMMENDED that organizations use a published schema for 179 this string to promote consistent decoding. 181 User-Defined Subobjects 183 User-defined subobjects MAY be included. The generic format of 184 subobjects is specified in Section 3.1. The semantics of a 185 subobject is indicated by the Type field, but the semantics, 186 format and contents of the Value field are specified by the 187 (sub-)organization indicated by the Enterprise Number and 188 Sub Org fields of this object. 190 3.1. Subobjects 192 Each subobject is encoded as a TLV in the following format: 194 0 1 195 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ 197 | Type | Length | (Subobject contents) | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ 200 Type 202 An 8-bit number assigned by the the (sub-)organization 203 indicated by the Enterprise Number and Sub Org fields of the 204 USER_ERROR_SPEC object. 206 Length 208 The Length contains the total length of the subobject in bytes, 209 including the Type and Length fields. The Length MUST be at 210 least 4, and MUST be a multiple of 4. 212 4. Procedures for Using the User Error Spec 214 4.1. Procedures for Sending the User Error Spec 216 A USER_ERROR_SPEC object MAY be included in any PathErr, ResvErr, or 217 Notify message for any defined error code. The Enterprise Number 218 MUST be a valid value assigned by IANA. 220 As specified in [RFC2205] and [RFC3473], an ERROR_SPEC object with a 221 valid error code MUST be included in all PathErr, ResvErr, and Notify 222 messages. This rule is not changed by these procedures even when a 223 USER_ERROR_SPEC object is included. If no other error code applies, 224 the Error Code in the ERROR_SPEC object MUST be set to "User Error 225 Spec" as defined in Section 2 of this document. 227 4.2. Procedures for Receiving the User Error Spec 229 It is RECOMMENDED that implementations that receive a PathErr, 230 ResvErr, or Notify message carrying a USER_ERROR_SPEC object at a 231 minimum log the Enterprise Number, Sub-organization, User Error 232 Value, and Error Description. Implementation capable of interpreting 233 the contents of the USER_ERROR_SPEC object SHOULD take appropriate 234 action. 236 If a message is received containing an ERROR_SPEC object using the 237 "User Error Spec" error code, but not containing a USER_ERROR_SPEC 238 object, the message SHOULD be treated as malformed and handled 239 according to [RFC2205]. 241 Implementations SHOULD ignore repeated occurences of USER_ERROR_SPEC 242 objects, and SHOULD forward them unchanged on any messages that they 243 forward. 245 Implementations receiving a USER_ERROR_SPEC object on some message 246 other than a PathErr, ResvErr, or Notify message SHOULD treat the 247 error as a malformed message and process according to [RFC2205]. 249 5. IANA Considerations 251 This document makes the following assignments from the RSVP Error 252 Codes and Globally-Defined Error Value Sub-Codes registry (pending 253 IANA action): 255 Value Name 257 User Error Spec 259 This document makes the following assignments from the RSVP Class 260 Names, Class Numbers, and Class Types registry (pending IANA action): 262 Number Space Value Name 264 Class Numbers * User Error Spec 266 Class Type 1 User-Defined Error 268 * Assignment is requested from the range 192 through 247 270 6. Security Considerations 272 This document makes no changes to the basic message exchanges of 273 [RFC2205] and [RFC3473]. It will result in a small increase in the 274 number of error messages sent in cases where messages were previously 275 silently dropped due to the lack of an appropriate error code. 277 The mechanisms defined in this document may be used by 278 implementations to report additional error conditions and information 279 arising from security issues and attacks on the RSVP network. 281 7. Acknowledgments 283 The authors would like to thank Elisheva Halevy for motivating this 284 document, and Tom Nadeau, and Magnus Westerlund for their review and 285 comments. 287 8. Normative References 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, March 1997. 292 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 293 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 294 Functional Specification", RFC 2205, September 1997. 296 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 297 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 298 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 300 9. Authors' Addresses 302 George Swallow 303 Cisco Systems, Inc. 304 EMail: swallow@cisco.com 306 Adrian Farrel 307 Old Dog Consulting 308 EMail: adrian@olddog.co.uk 310 Intellectual Property 312 The IETF takes no position regarding the validity or scope of any 313 Intellectual Property Rights or other rights that might be claimed to 314 pertain to the implementation or use of the technology described in 315 this document or the extent to which any license under such rights 316 might or might not be available; nor does it represent that it has 317 made any independent effort to identify any such rights. Information 318 on the procedures with respect to rights in RFC documents can be 319 found in BCP 78 and BCP 79. 321 Copies of IPR disclosures made to the IETF Secretariat and any 322 assurances of licenses to be made available, or the result of an 323 attempt made to obtain a general license or permission for the use of 324 such proprietary rights by implementers or users of this 325 specification can be obtained from the IETF on-line IPR repository at 326 http://www.ietf.org/ipr. 328 The IETF invites any interested party to bring to its attention any 329 copyrights, patents or patent applications, or other proprietary 330 rights that may cover technology that may be required to implement 331 this standard. Please address the information to the IETF at ietf- 332 ipr@ietf.org. 334 Full Copyright Notice 336 Copyright (C) The IETF Trust (2007). This document is subject to the 337 rights, licenses and restrictions contained in BCP 78, and except as 338 set forth therein, the authors retain all their rights. 340 This document and the information contained herein are provided on an 341 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 342 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 343 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 344 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 345 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 346 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.