idnits 2.17.1 draft-swallow-rsvp-user-error-spec-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 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 301. ** 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? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. 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.) -- The document date (March 2007) is 6244 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) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group George Swallow 2 Internet Draft Cisco Systems, Inc. 3 Category: Standards Track 4 Expiration Date: September 2007 5 Updates RFC2205, RFC3473 Adrian Farrel 6 Old Dog Consulting 8 March 2007 10 User Defined Errors for RSVP 12 draft-swallow-rsvp-user-error-spec-01.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Abstract 39 The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object 40 for communicating errors. That object has a defined format that 41 permits the definition of 256 error codes. As RSVP has been 42 developed and extended, the convention has been to be conservative in 43 defining new error codes. Further, no provision for user defined 44 errors exists in RSVP. 46 This document defines a new RSVP object to permit user defined error 47 values to be communicated. 49 Contents 51 1 Introduction .............................................. 4 52 1.1 Conventions ............................................... 4 53 2 User Defined Error ........................................ 4 54 3 USER_ERROR_SPEC Class ..................................... 5 55 3.1 Subobjects ................................................ 6 56 4 Procedures for using the User Error Spec .................. 7 57 4.1 Procedures for sending the User Error Spec ................ 7 58 4.2 Procedures for receiving the User Error Spec .............. 7 59 5 IANA Considerations ....................................... 7 60 6 Security Considerations ................................... 8 61 7 Acknowledgments ........................................... 8 62 8 Normative References ...................................... 8 63 9 Authors' Addresses ........................................ 9 65 1. Introduction 67 The Resource ReserVation Protocol (RSVP) [RFC2205] defines an 68 ERROR_SPEC object for communicating errors. That object has a 69 defined format that permits the definition of 256 error codes. As 70 RSVP has been developed and extended, the convention has been to be 71 conservative in communicating errors. Further no provision for user 72 defined errors exists in RSVP. 74 When developing extensions to RSVP, it is often useful for those 75 implementing to define error messages to aid both in the initial 76 debugging and in testing against older versions or other implementa- 77 tions. 79 This document defines a new RSVP object to permit user defined errors 80 to be communicated. This will enable organizations to define errors 81 which they can use for internal development. These error values 82 could also be shared with the community at large to aid in promoting 83 interoperability between diverse implementations. 85 RSVP PathErr and ResvErr messages require the presence of an 86 ERROR_SPEC object. [RFC3473] defines the Notify message that also 87 requires the presence of an ERROR_SPEC object. In order to not 88 change the mandatory contents of these messages, this document 89 defines a new error code value that indicates that the new object is 90 present and carries a user defined error code. 92 1.1. Conventions 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 98 2. User Defined Error 100 Error Code = : User Error Spec 102 This error code is used to signal the presence of a 103 USER_ERROR_SPEC. No subcodes are defined. 105 When sending this error code, a USER_ERROR_SPEC object MUST be 106 included in the PathErr, ResvErr or Notify message. 108 [Editor's note: = to be assigned by IANA] 110 3. USER_ERROR_SPEC Class 112 A new RSVP object class is defined called the the USER_ERROR_SPEC 113 Class. The class number is taken from the range 192 - 247. This is 114 done for backward compatibility. Existing implementations will 115 ignore the object and pass it along. 117 USER_ERROR_SPEC object: Class = , C-Type = 1 119 0 1 2 3 120 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 121 +---------------+---------------+---------------+---------------+ 122 | Enterprise Number | 123 +---------------+---------------+---------------+---------------+ 124 | Sub Org | Err Desc Len | User Error Value | 125 +---------------+---------------+---------------+---------------+ 126 | | 127 . Error Description . 128 . . 129 | | 130 +---------------+---------------+---------------+---------------+ 131 | | 132 . User Defined Subobjects . 133 . . 134 | | 135 +---------------+---------------+---------------+---------------+ 137 Enterprise Number 139 A unique identifier of an organization encoded as a 32-bit 140 integer. Enterprise Numbers are assigned by IANA. 142 Sub-organization 144 A unique identifier of an organization encoded as a 8-bit 145 integer. An organization MAY use this field to create 146 independent Error Value spaces. This is intended to 147 facilitate teams which are doing parallel development. If 148 independent spaces are not required, this field SHOULD be 149 set to zero. 151 Err Desc Len 153 The length of the error description in the Error Description 154 field in buyes excluding any padding. 156 User Error Value 158 A 16-bit integer The format and contents are specified by 159 the (sub-)organization indicated by the Enterprise Number 160 and Sub Org fields. 162 Error Description 164 A string of characters in US-ASCII padded with nulls (0x00) 165 to a multiple of 4 bytes. While no format is required, it 166 is RECOMMENDED that organizations use a published schema for 167 this string to promote consistent decoding. 169 User Defined Subobjects 171 Optionally, user defined subobjects may be included. The 172 semantics of the Type and the format and contents of the 173 value are specified by the (sub-) organization indicated 174 by the Enterprise Number and Sub Org fields. 176 3.1. Subobjects 178 Each subobject is encoded as a TLV in the following format: 180 0 1 181 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ 183 | Type | Length | (Subobject contents) | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ 186 Type 188 An 8-bit number assigned by the the (sub-) organization 189 indicated by the Enterprise Number and Sub Org fields. 191 Length 193 The Length contains the total length of the Subobject contents 194 in bytes, including the L, Type and Length fields. The Length 195 MUST be at least 4, and MUST be a multiple of 4. 197 4. Procedures for using the User Error Spec 199 4.1. Procedures for sending the User Error Spec 201 A USER_ERROR_SPEC object MAY be included in any PathErr, ResvErr or 202 Notify message. The Enterprise Number MUST be a valid value assigned 203 by IANA. As specified in [RFC2205] and [RFC3473], an ERROR_SPEC 204 object with a valid error code MUST be included in those messages. 205 If no other error code applies, the error code MUST be set to , 206 Unspecified Error. 208 4.2. Procedures for receiving the User Error Spec 210 It is RECOMMENDED that implementations at a minimum log the Enter- 211 prise Number Sub-organization, User Error Value, and Error Descrip- 212 tion. Implementation capable of interpreting the contents of the 213 USER_ERROR_SPEC object SHOULD take appropriate action. 215 If a message is received containing an ERROR_SPEC object using the 216 "User Error Spec" error code, but not containing a USER_ERROR_SPEC 217 object, the message SHOULD be treated as malformed and handled 218 according to [RFC2205]. 220 Implementations SHOULD ignore repeated occurences of USER_ERROR_SPEC 221 objects. 223 5. IANA Considerations 225 This document makes the following assignments from the RSVP Error 226 Codes and Globally-Defined Error Value Sub-Codes registry (pending 227 IANA action): 229 Value Name 231 User Error Spec 233 This document makes the following assignments from the RSVP Class 234 Names, Class Numbers, and Class Types registry (pending IANA action): 236 Number Space Value Name 238 Class Numbers * User Error Spec 240 Class Type 1 User Defined Error 242 * Assignment is requested from the range 192 through 247 244 6. Security Considerations 246 This document makes no changes to the basic message exchanges of 247 [RFC2205] and [RFC3473]. It will result in a small increase in the 248 number of error messages sent in cases where messages were silently 249 dropped due to the lack of an appropriate error code. 251 7. Acknowledgments 253 The authors would like to thank Elisheva Halevy for motivating this 254 document and Tom Nadeau for his review and comments. 256 8. Normative References 258 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 259 "Resource ReSerVation Protocol (RSVP) -- Version 1 260 Functional Specification", RFC 2205, September 1997. 262 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 263 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 264 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 266 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, March 1997. 269 9. Authors' Addresses 271 George Swallow 272 Cisco Systems, Inc. 273 Email: swallow@cisco.com 275 Adrian Farrel 276 Old Dog Consulting 277 EMail: adrian@olddog.co.uk 279 Intellectual Property 281 The IETF takes no position regarding the validity or scope of any 282 Intellectual Property Rights or other rights that might be claimed to 283 pertain to the implementation or use of the technology described in 284 this document or the extent to which any license under such rights 285 might or might not be available; nor does it represent that it has 286 made any independent effort to identify any such rights. Information 287 on the procedures with respect to rights in RFC documents can be 288 found in BCP 78 and BCP 79. 290 Copies of IPR disclosures made to the IETF Secretariat and any assur- 291 ances of licenses to be made available, or the result of an attempt 292 made to obtain a general license or permission for the use of such 293 proprietary rights by implementers or users of this specification can 294 be obtained from the IETF on-line IPR repository at 295 http://www.ietf.org/ipr. 297 The IETF invites any interested party to bring to its attention any 298 copyrights, patents or patent applications, or other proprietary 299 rights that may cover technology that may be required to implement 300 this standard. Please address the information to the IETF at ietf- 301 ipr@ietf.org. 303 Full Copyright Notice 305 Copyright (C) The IETF Trust (2007). This document is subject to the 306 rights, licenses and restrictions contained in BCP 78, and except as 307 set forth therein, the authors retain all their rights. 309 This document and the information contained herein are provided on an 310 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 311 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 312 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 313 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 314 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 315 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.