idnits 2.17.1 draft-swallow-rsvp-user-error-spec-00.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 on line 242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 251. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 264. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 7 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 RFC 3978 Section 5.4 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 (October 2006) is 6403 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: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 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: April 2007 5 Adrian Farrel 6 Old Dog Consulting 8 October 2006 10 User Defined Errors for RSVP 12 draft-swallow-rsvp-user-error-spec-00.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 communicating errors. Further, no provision for user defined errors 44 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 4 Procedures for using the User Error Spec .................. 6 56 4.1 Procedures for sending the User Error Spec ................ 6 57 4.2 Procedures for receiving the User Error Spec .............. 6 58 5 IANA Considerations ....................................... 6 59 6 Security Considerations ................................... 7 60 7 Acknowledgments ........................................... 7 61 8 Normative References ...................................... 7 62 9 Authors' Addresses ........................................ 7 64 1. Introduction 66 The Resource ReserVation Protocol (RSVP) [RFC2205] defines an 67 ERROR_SPEC object for communicating errors. That object has a 68 defined format that permits the definition of 256 error codes. As 69 RSVP has been developed and extended, the convention has been to be 70 conservative in communicating errors. Further no provision for user 71 defined errors exists in RSVP. 73 When developing extensions to RSVP it is often useful for those 74 implementing to define error messages to aid both in the initial 75 debugging and in testing against older versions or other implementa- 76 tions. 78 This document defines a new RSVP object to permit user defined errors 79 to be communicated. This will enable diverse organizations to define 80 errors which they can use for internal development. These error val- 81 ues could also be shared with the community at large to aid in pro- 82 moting interoperability between diverse implementations. 84 RSVP PathErr and ResvErr messages require the presence of an 85 ERROR_SPEC object. [RFC3473] defines the Notify message that also 86 requires the presence of an ERROR_SPEC object. In order to not 87 change the mandatory contents of these messages, this document 88 defines a new error code value that indicates that the new object is 89 present and carries a user defined error code. 91 1.1. Conventions 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 97 2. User Defined Error 99 Error Code = : User Error Spec 101 This error code is used to signal the presence of a 102 USER_ERROR_SPEC. No subcodes are defined. 104 When sending this error code, a USER_ERROR_SPEC object SHOULD be 105 included in the PathErr, ResvErr or Notify message. 107 3. USER_ERROR_SPEC Class 109 A new RSVP object class is defined called the the USER_ERROR_SPEC 110 Class. The class number is taken from the range 192 - 247. This is 111 done for backward compatibility. Existing implementations will 112 ignore the object and pass it along. 114 USER_DEFINED_ERROR object: Class = , C-Type = 1 116 0 1 2 3 117 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 118 +---------------+---------------+---------------+---------------+ 119 | Organizationally Unique Identifier | Sub Org | 120 +---------------+---------------+---------------+---------------+ 121 | User Error Value | 122 +---------------+---------------+---------------+---------------+ 123 | | 124 . User Defined Sub-TLVs . 125 . . 126 | | 127 +---------------+---------------+---------------+---------------+ 129 Organizationally Unique Identifier (OUI) 131 A unique identifier of an organization. OUIs are assigned by 132 the IEEE. 134 Sub-organization 136 An organization MAY use this field to create independent 137 Error Value spaces. This is intended to facilitate teams 138 which are doing parallel development. If independent 139 spaces are not required, this field SHOULD be set to zero. 141 User Error Value 143 The format and contents are specified by the (sub-) 144 organization indicated by the OUI and Sub Org fields. 146 User Defined Sub-TLVs 148 The format and contents are specified by the (sub-) 149 organization indicated by the OUI and Sub Org fields. 151 4. Procedures for using the User Error Spec 153 4.1. Procedures for sending the User Error Spec 155 A USER_DEFINED_ERROR object MAY be included in any PathErr or ResvErr 156 message. The Organizationally Unique Identifier MUST be a valid 157 value assigned by the IEEE. As specified in [RFC2205], an ERROR_SPEC 158 object MUST be included with a valid error code. If no other error 159 code applies, the error code MUST be set to , Unspecified Error. 161 4.2. Procedures for receiving the User Error Spec 163 It is RECOMMENDED that implementations at a minimum log the OUI, Sub- 164 organization, and User Error Value. If an implementation is capable 165 of interpreting the contents of the User Error Spec it MAY take any 166 appropriate action. 168 5. IANA Considerations 170 This document makes the following assignments from the RSVP Error 171 Codes and Globally-Defined Error Value Sub-Codes registry (pending 172 IANA action): 174 Value Name 176 User Error Spec 178 This document makes the following assignments from the RSVP Class 179 Names, Class Numbers, and Class Types registry (pending IANA action): 181 Number Space Value Name 183 Class Numbers * User Error Spec 185 Class Type 1 User Defined Error 187 * Assignment is requested from the range 192 through 247 189 6. Security Considerations 191 This document makes no changes to the basic message exchanges of 192 [RFC2205] and [RFC3473]. It will result in a small increase in the 193 number of error messages sent in cases where messages were silently 194 dropped due to the lack of an appropriate error code. 196 7. Acknowledgments 198 The authors would like to thank Elisheva Hochberg for motivating this 199 document. 201 8. Normative References 203 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 204 "Resource ReSerVation Protocol (RSVP) -- Version 1 205 Functional Specification", RFC 2205, September 1997. 207 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 208 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 209 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 211 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 212 Requirement Levels", BCP 14, RFC 2119, March 1997. 214 9. Authors' Addresses 216 George Swallow 217 Cisco Systems, Inc. 218 Email: swallow@cisco.com 220 Adrian Farrel 221 Old Dog Consulting 222 EMail: adrian@olddog.co.uk 224 Copyright Notice 226 Copyright (C) The Internet Society (2006). This document is subject 227 to the rights, licenses and restrictions contained in BCP 78, and 228 except as set forth therein, the authors retain all their rights. 230 Expiration Date 232 April 2007 234 Disclaimer of Validity 236 This document and the information contained herein are provided on an 237 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 238 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 239 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 240 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 241 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 242 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 244 The IETF takes no position regarding the validity or scope of any 245 Intellectual Property Rights or other rights that might be claimed to 246 pertain to the implementation or use of the technology described in 247 this document or the extent to which any license under such rights 248 might or might not be available; nor does it represent that it has 249 made any independent effort to identify any such rights. Information 250 on the procedures with respect to rights in RFC documents can be 251 found in BCP 78 and BCP 79. 253 Copies of IPR disclosures made to the IETF Secretariat and any 254 assurances of licenses to be made available, or the result of an 255 attempt made to obtain a general license or permission for the use of 256 such proprietary rights by implementers or users of this 257 specification can be obtained from the IETF on-line IPR repository at 258 http://www.ietf.org/ipr. 260 The IETF invites any interested party to bring to its attention any 261 copyrights, patents or patent applications, or other proprietary 262 rights that may cover technology that may be required to implement 263 this standard. Please address the information to the IETF at 264 ietf-ipr@ietf.org.