idnits 2.17.1 draft-ietf-tsvwg-rsvp-user-error-spec-05.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 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 321. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 327. 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 1, 2008 A. Farrel 6 Expiration Date: October 1, 2008 Old Dog Consulting 8 User-Defined Errors for RSVP 10 draft-ietf-tsvwg-rsvp-user-error-spec-05.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 - Clarify that Error Description may be empty. 53 1. Introduction 55 The Resource ReserVation Protocol (RSVP) [RFC2205] defines an 56 ERROR_SPEC object for communicating errors. That object has a 57 defined format that permits the definition of 256 error codes. As 58 RSVP has been developed and extended, the convention has been to be 59 conservative in communicating errors. Further no provision for user 60 defined errors exists in RSVP. 62 When developing extensions to RSVP, it is often useful for those 63 implementing to define error messages to aid both in the initial 64 debugging and in testing against older versions or other 65 implementations. 67 This document defines a new RSVP object to permit user-defined errors 68 to be communicated. This will enable organizations to define errors 69 which they can use for internal development. These error values 70 could also be shared with the community at large to aid in promoting 71 interoperability between diverse implementations. 73 RSVP PathErr and ResvErr messages require the presence of an 74 ERROR_SPEC object ([RFC2205]). [RFC3473] defines the Notify message 75 that also requires the presence of an ERROR_SPEC object. In order to 76 not change the mandatory contents of these messages, this document 77 defines a new error code value that indicates that the new object is 78 present and carries a user-defined error code. 80 Note that the ResvConf message defined in [RFC2205] also carries an 81 ERROR_SPEC object. But this usage of the object does not carry 82 meaningful Error Codes or Error Values and so the extensions defined 83 in this document are not applicable to that message. 85 1.1. Conventions 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 2. User-Defined Error 93 A new Error Code is defined for use in an ERROR_SPEC object. 95 Error Code = : User Error Spec 97 This error code is used to signal the presence of a 98 USER_ERROR_SPEC. No Error Values are defined. 100 When sending this error code, a USER_ERROR_SPEC object MUST be 101 included in the PathErr, ResvErr, or Notify message. 103 [RFC Editor's note: = to be assigned by IANA as per Section 5. 104 Please replace with the number assigned by IANA and remove 105 this note.] 107 3. USER_ERROR_SPEC Class 109 A new RSVP object class called USER_ERROR_SPEC is defined. To support 110 backwards compatibility, its class number is in the range 192-247. As 111 defined in [RFC2205], implementations that do not understand such an 112 object will forward it unmodified. 114 USER_ERROR_SPEC object: Class = , C-Type = 1 116 [RFC Editor's note: = to be assigned by IANA as per Section 5. 117 Please replace with the number assigned by IANA and remove 118 this note.] 120 0 1 2 3 121 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 122 +---------------+---------------+---------------+---------------+ 123 | Enterprise Number | 124 +---------------+---------------+---------------+---------------+ 125 | Sub Org | Err Desc Len | User Error Value | 126 +---------------+---------------+---------------+---------------+ 127 | | 128 ~ Error Description ~ 129 | | 130 +---------------+---------------+---------------+---------------+ 131 | | 132 ~ User-Defined Subobjects ~ 133 | | 134 +---------------+---------------+---------------+---------------+ 136 Enterprise Number 138 A unique identifier of an organization encoded as a 32-bit 139 integer. Enterprise Numbers are assigned by IANA and managed 140 through an IANA registry [RFC2578]. 142 Sub Org 144 A unique identifier of an organization encoded as an 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 bytes excluding any padding. Zero is a valid length if 155 no error description is supplied. 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. If the Err Desc Len is zero then 167 no bytes are supplied. 169 User-Defined Subobjects 171 User-defined subobjects MAY be included. The generic format of 172 subobjects is specified in Section 3.1. The semantics of a 173 subobject is indicated by the Type field, but the semantics, 174 format and contents of the Value field are specified by the 175 (sub-)organization indicated by the Enterprise Number and 176 Sub Org fields of this object. 178 3.1. Subobjects 180 Each subobject is encoded as a TLV in the following format: 182 0 1 183 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ 185 | Type | Length | (Subobject contents) | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ 187 Type 189 An 8-bit number assigned by the the (sub-)organization 190 indicated by the Enterprise Number and Sub Org fields of the 191 USER_ERROR_SPEC object. 193 Length 195 The Length contains the total length of the subobject in bytes, 196 including the Type and Length fields. The Length MUST be at 197 least 4, and MUST be a multiple of 4. 199 4. Procedures for Using the User Error Spec 201 4.1. Procedures for Sending the User Error Spec 203 A USER_ERROR_SPEC object MAY be included in any PathErr, ResvErr, or 204 Notify message for any defined error code. The Enterprise Number 205 MUST be a valid value assigned by IANA. 207 As specified in [RFC2205] and [RFC3473], an ERROR_SPEC object with a 208 valid error code MUST be included in all PathErr, ResvErr, and Notify 209 messages. This rule is not changed by these procedures even when a 210 USER_ERROR_SPEC object is included. If no other error code applies, 211 the Error Code in the ERROR_SPEC object MUST be set to "User Error 212 Spec" as defined in Section 2 of this document. 214 4.2. Procedures for Receiving the User Error Spec 216 It is RECOMMENDED that implementations that receive a PathErr, 217 ResvErr, or Notify message carrying a USER_ERROR_SPEC object at a 218 minimum log the Enterprise Number, Sub-organization, User Error 219 Value, and Error Description. Implementations capable of 220 interpreting the contents of the USER_ERROR_SPEC object should take 221 further action based on the reported error. 223 If a message is received containing an ERROR_SPEC object using the 224 "User Error Spec" error code, but not containing a USER_ERROR_SPEC 225 object, the message MUST be treated as malformed and handled 226 according to [RFC2205]. 228 Implementations SHOULD ignore repeated occurences of USER_ERROR_SPEC 229 objects, and SHOULD forward them unchanged on any messages that they 230 forward. This provides for forward compatiblity. 232 Implementations receiving a USER_ERROR_SPEC object on some message 233 other than a PathErr, ResvErr, or Notify message MUST treat the 234 error as a malformed message and process according to [RFC2205]. 236 5. IANA Considerations 238 This document makes the following assignments from the RSVP Error 239 Codes and Globally-Defined Error Value Sub-Codes registry (pending 240 IANA action): 242 Value Name 244 User Error Spec 246 This document makes the following assignments from the RSVP Class 247 Names, Class Numbers, and Class Types registry (pending IANA action): 249 Number Space Value Name 251 Class Numbers * User Error Spec 253 Class Type 1 User-Defined Error 255 * Assignment is requested from the range 192 through 247 257 6. Security Considerations 259 This document makes no changes to the basic message exchanges of 260 [RFC2205] and [RFC3473]. It will result in a small increase in the 261 number of error messages sent in cases where messages were previously 262 silently dropped due to the lack of an appropriate error code. 264 The mechanisms defined in this document may be used by 265 implementations to report additional error conditions and information 266 arising from security issues and attacks on the RSVP network. 268 7. Acknowledgments 270 The authors would like to thank Elisheva Halevy for motivating this 271 document. Thanks to Tom Nadeau, Magnus Westerlund, and Hannes 272 Tschofenig for their review and comments. 274 8. References 276 8.1. Normative References 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, March 1997. 281 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 282 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 283 Functional Specification", RFC 2205, September 1997. 285 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 286 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 287 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 289 8.1. Informative References 291 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 292 "Structure of Management Information Version 2 (SMIv2)", 293 STD 58, RFC 2578, April 1999. 295 9. Authors' Addresses 297 George Swallow 298 Cisco Systems, Inc. 299 EMail: swallow@cisco.com 301 Adrian Farrel 302 Old Dog Consulting 303 EMail: adrian@olddog.co.uk 305 10. Intellectual Property 307 The IETF takes no position regarding the validity or scope of any 308 Intellectual Property Rights or other rights that might be claimed to 309 pertain to the implementation or use of the technology described in 310 this document or the extent to which any license under such rights 311 might or might not be available; nor does it represent that it has 312 made any independent effort to identify any such rights. Information 313 on the procedures with respect to rights in RFC documents can be 314 found in BCP 78 and BCP 79. 316 Copies of IPR disclosures made to the IETF Secretariat and any 317 assurances of licenses to be made available, or the result of an 318 attempt made to obtain a general license or permission for the use of 319 such proprietary rights by implementers or users of this 320 specification can be obtained from the IETF on-line IPR repository at 321 http://www.ietf.org/ipr. 323 The IETF invites any interested party to bring to its attention any 324 copyrights, patents or patent applications, or other proprietary 325 rights that may cover technology that may be required to implement 326 this standard. Please address the information to the IETF at ietf- 327 ipr@ietf.org. 329 Full Copyright Notice 331 Copyright (C) The IETF Trust (2008). This document is subject to the 332 rights, licenses and restrictions contained in BCP 78, and except as 333 set forth therein, the authors retain all their rights. 335 This document and the information contained herein are provided on an 336 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 337 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 338 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 339 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 340 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 341 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.