idnits 2.17.1 draft-ietf-tsvwg-rsvp-user-error-spec-04.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 342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 328. 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: March 28, 2008 A. Farrel 6 Expiration Date: September 28, 2008 Old Dog Consulting 8 User-Defined Errors for RSVP 10 draft-ietf-tsvwg-rsvp-user-error-spec-04.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 - Minor editorial changes after working group last call review. 52 - Add discussion of ResvConf messages. 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. No Error Values are defined. 101 When sending this error code, a USER_ERROR_SPEC object MUST be 102 included in the PathErr, ResvErr, or Notify message. 104 [RFC Editor's note: = to be assigned by IANA as per Section 5. 105 Please replace with the number assigned by IANA and remove 106 this note.] 108 3. USER_ERROR_SPEC Class 110 A new RSVP object class called USER_ERROR_SPEC is defined. To support 111 backwards compatibility, its class number is in the range 192-247. As 112 defined in [RFC2205], implementations that do not understand such an 113 object will forward it unmodified. 115 USER_ERROR_SPEC object: Class = , C-Type = 1 117 [RFC Editor's note: = to be assigned by IANA as per Section 5. 118 Please replace with the number assigned by IANA and remove 119 this note.] 121 0 1 2 3 122 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 123 +---------------+---------------+---------------+---------------+ 124 | Enterprise Number | 125 +---------------+---------------+---------------+---------------+ 126 | Sub Org | Err Desc Len | User Error Value | 127 +---------------+---------------+---------------+---------------+ 128 | | 129 ~ Error Description ~ 130 | | 131 +---------------+---------------+---------------+---------------+ 132 | | 133 ~ User-Defined Subobjects ~ 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 and managed 141 through an IANA registry [RFC2578]. 143 Sub Org 145 A unique identifier of an organization encoded as an 8-bit 146 integer. An organization MAY use this field to create 147 independent Error Value spaces. This is intended to 148 facilitate teams which are doing parallel development. If 149 independent spaces are not required, this field SHOULD be 150 set to zero. 152 Err Desc Len 154 The length of the error description in the Error Description 155 field in bytes excluding any padding. 157 User Error Value 159 A 16-bit integer. The meaning is specified by the 160 (sub-)organization indicated by the Enterprise Number and Sub 161 Org fields. 163 Error Description 165 A string of characters in US-ASCII padded with nulls (0x00) 166 to a multiple of 4 bytes. While no format is required, it 167 is RECOMMENDED that organizations use a published schema for 168 this string to promote consistent decoding. 170 User-Defined Subobjects 172 User-defined subobjects MAY be included. The generic format of 173 subobjects is specified in Section 3.1. The semantics of a 174 subobject is indicated by the Type field, but the semantics, 175 format and contents of the Value field are specified by the 176 (sub-)organization indicated by the Enterprise Number and 177 Sub Org fields of this object. 179 3.1. Subobjects 181 Each subobject is encoded as a TLV in the following format: 183 0 1 184 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ 186 | Type | Length | (Subobject contents) | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ 188 Type 190 An 8-bit number assigned by the the (sub-)organization 191 indicated by the Enterprise Number and Sub Org fields of the 192 USER_ERROR_SPEC object. 194 Length 196 The Length contains the total length of the subobject in bytes, 197 including the Type and Length fields. The Length MUST be at 198 least 4, and MUST be a multiple of 4. 200 4. Procedures for Using the User Error Spec 202 4.1. Procedures for Sending the User Error Spec 204 A USER_ERROR_SPEC object MAY be included in any PathErr, ResvErr, or 205 Notify message for any defined error code. The Enterprise Number 206 MUST be a valid value assigned by IANA. 208 As specified in [RFC2205] and [RFC3473], an ERROR_SPEC object with a 209 valid error code MUST be included in all PathErr, ResvErr, and Notify 210 messages. This rule is not changed by these procedures even when a 211 USER_ERROR_SPEC object is included. If no other error code applies, 212 the Error Code in the ERROR_SPEC object MUST be set to "User Error 213 Spec" as defined in Section 2 of this document. 215 4.2. Procedures for Receiving the User Error Spec 217 It is RECOMMENDED that implementations that receive a PathErr, 218 ResvErr, or Notify message carrying a USER_ERROR_SPEC object at a 219 minimum log the Enterprise Number, Sub-organization, User Error 220 Value, and Error Description. Implementations capable of 221 interpreting the contents of the USER_ERROR_SPEC object should take 222 further action based on the reported error. 224 If a message is received containing an ERROR_SPEC object using the 225 "User Error Spec" error code, but not containing a USER_ERROR_SPEC 226 object, the message MUST be treated as malformed and handled 227 according to [RFC2205]. 229 Implementations SHOULD ignore repeated occurences of USER_ERROR_SPEC 230 objects, and SHOULD forward them unchanged on any messages that they 231 forward. This provides for forward compatiblity. 233 Implementations receiving a USER_ERROR_SPEC object on some message 234 other than a PathErr, ResvErr, or Notify message MUST treat the 235 error as a malformed message and process according to [RFC2205]. 237 5. IANA Considerations 239 This document makes the following assignments from the RSVP Error 240 Codes and Globally-Defined Error Value Sub-Codes registry (pending 241 IANA action): 243 Value Name 245 User Error Spec 247 This document makes the following assignments from the RSVP Class 248 Names, Class Numbers, and Class Types registry (pending IANA action): 250 Number Space Value Name 252 Class Numbers * User Error Spec 254 Class Type 1 User-Defined Error 256 * Assignment is requested from the range 192 through 247 258 6. Security Considerations 260 This document makes no changes to the basic message exchanges of 261 [RFC2205] and [RFC3473]. It will result in a small increase in the 262 number of error messages sent in cases where messages were previously 263 silently dropped due to the lack of an appropriate error code. 265 The mechanisms defined in this document may be used by 266 implementations to report additional error conditions and information 267 arising from security issues and attacks on the RSVP network. 269 7. Acknowledgments 271 The authors would like to thank Elisheva Halevy for motivating this 272 document. Thanks to Tom Nadeau, Magnus Westerlund, and Hannes 273 Tschofenig for their review and comments. 275 8. References 277 8.1. Normative References 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, March 1997. 282 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 283 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 284 Functional Specification", RFC 2205, September 1997. 286 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 287 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 288 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 290 8.1. Informative References 292 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 293 "Structure of Management Information Version 2 (SMIv2)", 294 STD 58, RFC 2578, April 1999. 296 9. Authors' Addresses 298 George Swallow 299 Cisco Systems, Inc. 300 EMail: swallow@cisco.com 302 Adrian Farrel 303 Old Dog Consulting 304 EMail: adrian@olddog.co.uk 306 10. Intellectual Property 308 The IETF takes no position regarding the validity or scope of any 309 Intellectual Property Rights or other rights that might be claimed to 310 pertain to the implementation or use of the technology described in 311 this document or the extent to which any license under such rights 312 might or might not be available; nor does it represent that it has 313 made any independent effort to identify any such rights. Information 314 on the procedures with respect to rights in RFC documents can be 315 found in BCP 78 and BCP 79. 317 Copies of IPR disclosures made to the IETF Secretariat and any 318 assurances of licenses to be made available, or the result of an 319 attempt made to obtain a general license or permission for the use of 320 such proprietary rights by implementers or users of this 321 specification can be obtained from the IETF on-line IPR repository at 322 http://www.ietf.org/ipr. 324 The IETF invites any interested party to bring to its attention any 325 copyrights, patents or patent applications, or other proprietary 326 rights that may cover technology that may be required to implement 327 this standard. Please address the information to the IETF at ietf- 328 ipr@ietf.org. 330 Full Copyright Notice 332 Copyright (C) The IETF Trust (2008). This document is subject to the 333 rights, licenses and restrictions contained in BCP 78, and except as 334 set forth therein, the authors retain all their rights. 336 This document and the information contained herein are provided on an 337 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 338 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 339 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 340 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 341 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 342 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.