idnits 2.17.1 draft-ietf-tsvwg-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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 321. 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.) -- The document date (April 2007) is 6214 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: 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 George Swallow 3 Internet Draft Cisco Systems, Inc. 4 Category: Standards Track 5 Expiration Date: October 2007 6 Adrian Farrel 7 Old Dog Consulting 9 April 2007 11 User-Defined Errors for RSVP 13 draft-ietf-tsvwg-rsvp-user-error-spec-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object 41 for communicating errors. That object has a defined format that 42 permits the definition of 256 error codes. As RSVP has been 43 developed and extended, the convention has been to be conservative in 44 defining new error codes. Further, no provision for user-defined 45 errors exists in RSVP. 47 Contents 49 1 Introduction .............................................. 3 50 1.1 Conventions ............................................... 3 51 2 User-Defined Error ........................................ 3 52 3 USER_ERROR_SPEC Class ..................................... 4 53 3.1 Subobjects ................................................ 5 54 4 Procedures for Using the User Error Spec .................. 6 55 4.1 Procedures for Sending the User Error Spec ................ 6 56 4.2 Procedures for Receiving the User Error Spec .............. 6 57 5 IANA Considerations ....................................... 6 58 6 Security Considerations ................................... 7 59 7 Acknowledgments ........................................... 7 60 8 Normative References ...................................... 7 61 9 Authors' Addresses ........................................ 8 63 1. Introduction 65 The Resource ReserVation Protocol (RSVP) [RFC2205] defines an 66 ERROR_SPEC object for communicating errors. That object has a 67 defined format that permits the definition of 256 error codes. As 68 RSVP has been developed and extended, the convention has been to be 69 conservative in communicating errors. Further no provision for user 70 defined errors exists in RSVP. 72 When developing extensions to RSVP, it is often useful for those 73 implementing to define error messages to aid both in the initial 74 debugging and in testing against older versions or other 75 implementations. 77 This document defines a new RSVP object to permit user-defined errors 78 to be communicated. This will enable organizations to define errors 79 which they can use for internal development. These error values 80 could also be shared with the community at large to aid in promoting 81 interoperability between diverse implementations. 83 RSVP PathErr and ResvErr messages require the presence of an 84 ERROR_SPEC object ([RFC2205]). [RFC3473] defines the Notify message 85 that also requires the presence of an ERROR_SPEC object. In order to 86 not change the mandatory contents of these messages, this document 87 defines a new error code value that indicates that the new object is 88 present and carries a user-defined error code. 90 1.1. Conventions 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 2. User-Defined Error 98 A new Error Code is defined for use in an ERROR_SPEC object. 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 [RFC Editor's note: = to be assigned by IANA. Please replace 109 with the number assigned by IANA and remove this note.] 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 according to the rules of 116 [RFC2205]. 118 USER_ERROR_SPEC object: Class = , C-Type = 1 120 [RFC Editor's note: = to be assigned by IANA. Please replace 121 with the number assigned by IANA and remove this note.] 123 0 1 2 3 124 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 125 +---------------+---------------+---------------+---------------+ 126 | Enterprise Number | 127 +---------------+---------------+---------------+---------------+ 128 | Sub Org | Err Desc Len | User Error Value | 129 +---------------+---------------+---------------+---------------+ 130 | | 131 ~ Error Description ~ 132 | | 133 +---------------+---------------+---------------+---------------+ 134 | | 135 ~ User-Defined Subobjects ~ 136 | | 137 +---------------+---------------+---------------+---------------+ 139 Enterprise Number 141 A unique identifier of an organization encoded as a 32-bit 142 integer. Enterprise Numbers are assigned by IANA. 144 Sub Org 146 A unique identifier of an organization encoded as an 8-bit 147 integer. An organization MAY use this field to create 148 independent Error Value spaces. This is intended to 149 facilitate teams which are doing parallel development. If 150 independent spaces are not required, this field SHOULD be 151 set to zero. 153 Err Desc Len 155 The length of the error description in the Error Description 156 field in bytes excluding any padding. 158 User Error Value 160 A 16-bit integer. The format and contents are specified by 161 the (sub-)organization indicated by the Enterprise Number 162 and Sub Org fields. 164 Error Description 166 A string of characters in US-ASCII padded with nulls (0x00) 167 to a multiple of 4 bytes. While no format is required, it 168 is RECOMMENDED that organizations use a published schema for 169 this string to promote consistent decoding. 171 User-Defined Subobjects 173 User-defined subobjects MAY be included. The generic format of 174 subobjects is specified in Section 3.1. The semantics of a 175 subobject is indicated by the Type field, but the semantics, 176 format and contents of the Value field are specified by the 177 (sub-)organization indicated by the Enterprise Number and 178 Sub Org fields of this object. 180 3.1. Subobjects 182 Each subobject is encoded as a TLV in the following format: 184 0 1 185 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ 187 | Type | Length | (Subobject contents) | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ 190 Type 192 An 8-bit number assigned by the the (sub-)organization 193 indicated by the Enterprise Number and Sub Org fields of the 194 USER_ERROR_SPEC object. 196 Length 198 The Length contains the total length of the subobject in bytes, 199 including the L, Type and Length fields. The Length MUST be at 200 least 4, and MUST be a multiple of 4. 202 4. Procedures for Using the User Error Spec 204 4.1. Procedures for Sending the User Error Spec 206 A USER_ERROR_SPEC object MAY be included in any PathErr, ResvErr, or 207 Notify message. The Enterprise Number MUST be a valid value assigned 208 by IANA. 210 As specified in [RFC2205] and [RFC3473], an ERROR_SPEC object with a 211 valid error code MUST be included in all PathErr, ResvErr, and Notify 212 messages. This rule is not changed by these procedures even when a 213 USER_ERROR_SPEC object is included. If no other error code applies, 214 the Error Code in the ERROR_SPEC object MUST be set to "User Error 215 Spec" as defined in Section 2 of this document. 217 4.2. Procedures for Receiving the User Error Spec 219 It is RECOMMENDED that implementations that receive a PathErr, 220 ResvErr, or Notify message carrying a USER_ERROR_SPEC object at a 221 minimum log the Enterprise Number, Sub-organization, User Error 222 Value, and Error Description. Implementation capable of interpreting 223 the contents of the USER_ERROR_SPEC object SHOULD take appropriate 224 action. 226 If a message is received containing an ERROR_SPEC object using the 227 "User Error Spec" error code, but not containing a USER_ERROR_SPEC 228 object, the message SHOULD be treated as malformed and handled 229 according to [RFC2205]. 231 Implementations SHOULD ignore repeated occurences of USER_ERROR_SPEC 232 objects, and SHOULD forward them unchanged on any messages that they 233 forward. 235 Implementations receiving a USER_ERROR_SPEC object on some message 236 other than a PathErr, ResvErr, or Notify message SHOULD treat the 237 error as a malformed message and process according to [RFC2205]. 239 5. IANA Considerations 241 This document makes the following assignments from the RSVP Error 242 Codes and Globally-Defined Error Value Sub-Codes registry (pending 243 IANA action): 245 Value Name 247 User Error Spec 249 This document makes the following assignments from the RSVP Class 250 Names, Class Numbers, and Class Types registry (pending IANA action): 252 Number Space Value Name 254 Class Numbers * User Error Spec 256 Class Type 1 User-Defined Error 258 * Assignment is requested from the range 192 through 247 260 6. Security Considerations 262 This document makes no changes to the basic message exchanges of 263 [RFC2205] and [RFC3473]. It will result in a small increase in the 264 number of error messages sent in cases where messages were previously 265 silently dropped due to the lack of an appropriate error code. 267 The mechanisms defined in this document may be used by 268 implementations to report additional error conditions and information 269 arising from security issues and attacks on the RSVP network. 271 7. Acknowledgments 273 The authors would like to thank Elisheva Halevy for motivating this 274 document and Tom Nadeau for his review and comments. 276 8. 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 9. Authors' Addresses 291 George Swallow 292 Cisco Systems, Inc. 293 EMail: swallow@cisco.com 295 Adrian Farrel 296 Old Dog Consulting 297 EMail: adrian@olddog.co.uk 299 Intellectual Property 301 The IETF takes no position regarding the validity or scope of any 302 Intellectual Property Rights or other rights that might be claimed to 303 pertain to the implementation or use of the technology described in 304 this document or the extent to which any license under such rights 305 might or might not be available; nor does it represent that it has 306 made any independent effort to identify any such rights. Information 307 on the procedures with respect to rights in RFC documents can be 308 found in BCP 78 and BCP 79. 310 Copies of IPR disclosures made to the IETF Secretariat and any 311 assurances of licenses to be made available, or the result of an 312 attempt made to obtain a general license or permission for the use of 313 such proprietary rights by implementers or users of this 314 specification can be obtained from the IETF on-line IPR repository at 315 http://www.ietf.org/ipr. 317 The IETF invites any interested party to bring to its attention any 318 copyrights, patents or patent applications, or other proprietary 319 rights that may cover technology that may be required to implement 320 this standard. Please address the information to the IETF at ietf- 321 ipr@ietf.org. 323 Full Copyright Notice 325 Copyright (C) The IETF Trust (2007). This document is subject to the 326 rights, licenses and restrictions contained in BCP 78, and except as 327 set forth therein, the authors retain all their rights. 329 This document and the information contained herein are provided on an 330 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 331 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 332 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 333 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 334 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 335 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.