draft-ietf-tsvwg-rsvp-user-error-spec-07.txt   draft-ietf-tsvwg-rsvp-user-error-spec-08.txt 
Network Working Group G. Swallow Network Working Group G. Swallow
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Category: Standards Track Category: Standards Track
Created: April 28, 2008 A. Farrel Created: May 31, 2008 A. Farrel
Expiration Date: October 28, 2008 Old Dog Consulting Expiration Date: November 31, 2008 Old Dog Consulting
User-Defined Errors for RSVP User-Defined Errors for RSVP
draft-ietf-tsvwg-rsvp-user-error-spec-07.txt draft-ietf-tsvwg-rsvp-user-error-spec-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 5 skipping to change at page 2, line 5
The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object
for communicating errors. That object has a defined format that for communicating errors. That object has a defined format that
permits the definition of 256 error codes. As RSVP has been permits the definition of 256 error codes. As RSVP has been
developed and extended, the convention has been to be conservative in developed and extended, the convention has been to be conservative in
defining new error codes. Further, no provision for user-defined defining new error codes. Further, no provision for user-defined
errors exists in RSVP. errors exists in RSVP.
This document defines a USER_ERROR_SPEC to be used in addition to the This document defines a USER_ERROR_SPEC to be used in addition to the
ERROR_SPEC to carry additional user information related to errors. ERROR_SPEC to carry additional user information related to errors.
0. Changes Since Last Revision
[This section to be removed before publication as an RFC.]
- Clarify 'Enterprise Number'.
- Clarify 'Error Description' and give reference for ASCII.
1. Introduction 1. Introduction
The Resource ReserVation Protocol (RSVP) [RFC2205] defines an The Resource ReserVation Protocol (RSVP) [RFC2205] defines an
ERROR_SPEC object for communicating errors. That object has a ERROR_SPEC object for communicating errors. That object has a
defined format that permits the definition of 256 error codes. As defined format that permits the definition of 256 error codes. As
RSVP has been developed and extended, the convention has been to be RSVP has been developed and extended, the convention has been to be
conservative in communicating errors. Further no provision for user conservative in communicating errors. Further no provision for user
defined errors exists in RSVP. defined errors exists in RSVP.
When developing extensions to RSVP, it is often useful for those When developing extensions to RSVP, it is often useful for those
skipping to change at page 4, line 35 skipping to change at page 4, line 35
no error description is supplied. no error description is supplied.
User Error Value User Error Value
A 16-bit integer. The meaning is specified by the A 16-bit integer. The meaning is specified by the
(sub-)organization indicated by the Enterprise Number and Sub (sub-)organization indicated by the Enterprise Number and Sub
Org fields. Org fields.
Error Description Error Description
A string of characters in US-ASCII [ASCII] padded with nulls A string of characters padded with nulls (0x00) to a multiple of
(0x00) to a multiple of 4 bytes. If the Err Desc Len is zero 4 bytes. According to the guidance in [RFC2277], this string
then no bytes are supplied. MUST use UTF-8/Net-Unicode encoding [RFC5198]. Furthermore, it
is RECOMMENDED that implementations limit the strngs that they
generate to single-line printable US-ASCII [ASCII] whenever
feasible to improve the likelihood of easy use by the recipient.
If the Err Desc Len is zero then no bytes are supplied.
Note that the content of this field is implementation-specific. Note that the content of this field is implementation-specific.
It is typically printable, but might not be shown to all users It is typically printable, but might not be shown to all users
in all implementations (because it is limited to US-ASCII). in all implementations (because of character set choice).
Therefore, the content of the field SHOULD be limited to Therefore, the content of the field SHOULD be limited to
supplementary information and SHOULD NOT contain information supplementary information and SHOULD NOT contain information
critical to operating the network. Criticial information is critical to operating the network. Criticial information is
present in the User Error Value field. present in the User Error Value field.
User-Defined Subobjects User-Defined Subobjects
User-defined subobjects MAY be included. The generic format of User-defined subobjects MAY be included. The generic format of
subobjects is specified in Section 3.1. The semantics of a subobjects is specified in Section 3.1. The semantics of a
subobject is indicated by the Type field, but the semantics, subobject is indicated by the Type field, but the semantics,
skipping to change at page 6, line 4 skipping to change at page 6, line 10
in the ERROR_SPEC object is set to "User Error Spec", the Error Value in the ERROR_SPEC object is set to "User Error Spec", the Error Value
sub-code SHOULD be set to "Further details in User Error Spec" as sub-code SHOULD be set to "Further details in User Error Spec" as
defined in Section 2, but further Error Value sub-codes may be defined in Section 2, but further Error Value sub-codes may be
defined in future specifications. defined in future specifications.
4.2. Procedures for Receiving the User Error Spec 4.2. Procedures for Receiving the User Error Spec
It is RECOMMENDED that implementations that receive a PathErr, It is RECOMMENDED that implementations that receive a PathErr,
ResvErr, or Notify message carrying a USER_ERROR_SPEC object at a ResvErr, or Notify message carrying a USER_ERROR_SPEC object at a
minimum log the Enterprise Number, Sub-organization, User Error minimum log the Enterprise Number, Sub-organization, User Error
Value, and Error Description. Note that the Error Description is Value, and Error Description. Note that the character set used for
provided in US-ASCII which means that it might not be suitable for the Error Description may mean that it might not be suitable for
display of logging in all systems. Implementations capable of display of logging in all systems. Implementations capable of
interpreting the contents of the USER_ERROR_SPEC object should take interpreting the contents of the USER_ERROR_SPEC object SHOULD take
further action based on the reported error. further action based on the reported error.
Implementations that are not UTF-8 capable that receive a
USER_ERROR_SPEC object SHOULD handle the Error Descriprion according
to the procedures set out in [RFC5137].
If a message is received containing an ERROR_SPEC object using the If a message is received containing an ERROR_SPEC object using the
"User Error Spec" error code, but not containing a USER_ERROR_SPEC "User Error Spec" error code, but not containing a USER_ERROR_SPEC
object, the message MUST be treated as malformed and handled object, the message MUST be treated as malformed and handled
according to [RFC2205]. according to [RFC2205].
Implementations SHOULD ignore repeated occurences of USER_ERROR_SPEC Implementations SHOULD ignore repeated occurences of USER_ERROR_SPEC
objects, and SHOULD forward them unchanged on any messages that they objects, and SHOULD forward them unchanged on any messages that they
forward. This provides for forward compatiblity. forward. This provides for forward compatiblity.
Implementations receiving a USER_ERROR_SPEC object on some message Implementations receiving a USER_ERROR_SPEC object on some message
skipping to change at page 7, line 16 skipping to change at page 7, line 29
This document makes no changes to the basic message exchanges of This document makes no changes to the basic message exchanges of
[RFC2205] and [RFC3473]. It will result in a small increase in the [RFC2205] and [RFC3473]. It will result in a small increase in the
number of error messages sent in cases where messages were previously number of error messages sent in cases where messages were previously
silently dropped due to the lack of an appropriate error code. silently dropped due to the lack of an appropriate error code.
The mechanisms defined in this document may be used by The mechanisms defined in this document may be used by
implementations to report additional error conditions and information implementations to report additional error conditions and information
arising from security issues and attacks on the RSVP network. arising from security issues and attacks on the RSVP network.
Note that the use of a character string that will be displayed or
logged opens the potential for certain security attacks through the
use of overruns or embedded control characters. Implementations
SHOULD take precautions against overruns, and (especially where the
full characterset of [RFC5198] is not supported, SHOULD use the
procedures set out in [RFC5137] to handle unexpected or unknown
control characters.
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Elisheva Halevy for motivating this The authors would like to thank Elisheva Halevy for motivating this
document. Thanks to Tom Nadeau, Magnus Westerlund, Hannes Tschofenig, document. Thanks to Tom Nadeau, Magnus Westerlund, Hannes Tschofenig,
Bruce Davie, Jukka Manner, Francois Le Faucheur, Lars Eggert, and Tom Bruce Davie, Jukka Manner, Francois Le Faucheur, Lars Eggert, and Tom
Petch for their review and comments. Petch for their review and comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 7, line 38 skipping to change at page 8, line 9
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC5137] Klensin, J., "ASCII Escaping of Unicode Characters",
RFC 5137, BCP 137, February 2008.
[RFC5198] Klensin, J., and Padlipsky, M., "Unicode Format for
Network Interchange", RFC 5198, March 2008.
[ASCII] American National Standards Institute, "USA Code for [ASCII] American National Standards Institute, "USA Code for
Information Interchange", ANSI X3.4, 1968. Information Interchange", ANSI X3.4, 1968.
8.1. Informative References 8.2. Informative References
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", RFC 2277, BCP 18, January 1998.
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)", "Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999. STD 58, RFC 2578, April 1999.
9. Authors' Addresses 9. Authors' Addresses
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
EMail: swallow@cisco.com EMail: swallow@cisco.com
 End of changes. 11 change blocks. 
18 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/