Subject: [Tsvwg] I-D Action:draft-ietf-tsvwg-rsvp-user-error-spec-02.txt

From: [email-masked]
Date: Sat, 06 Oct 2007 08:10:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title           : User-Defined Errors for RSVP
	Author(s)       : G. Swallow, et al.
	Filename        : draft-ietf-tsvwg-rsvp-user-error-spec-02.txt
	Pages           : 8
	Date            : 2007-10-06

The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object
for communicating errors.  That object has a defined format that
permits the definition of 256 error codes.  As RSVP has been
developed and extended, the convention has been to be conservative in
defining new error codes.  Further, no provision for user-defined
errors exists in RSVP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-user-error-spec-02.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-tsvwg-rsvp-user-error-spec-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-tsvwg-rsvp-user-error-spec-02.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 06 Oct 2007 16:02:53 +0200

If I understood this document correctly then it essentially suggests 
vendor-specific error codes.

Typically, you use three octets to denote the vendor-specific Object 
Identifier (OID) that points to the IANA assigned "SMI Network 
Management Private Enterprise Codes" value (see [RFC3232]). Then, you 
need to provide a field for the error code. Often 3 bytes are 
sufficient. You seem to split these 3 bytes into 1 byte for a "Sub Org " 
and another 2 bytes for the actual error code value. I believe it is 
more common to just merge the 1+2 bytes together since a vendor will 
hopefully be able to manage the allocation of unique values.

I further suspect that you wrote this draft not really for vendors but 
rather for other SDOs, since they are also listed as vendors.

If my reading of the draft is correct then I wonder why you call the 
document "user-defined" errors instead of vendor-specific error codes 
for RSVP.
Do you think that it is so common that vendors or other SDOs will define 
their own error messages? Could that lead to interoperability problems?

Ciao
Hannes

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 6 Oct 2007 16:21:51 +0100

Hi Hannes,

> vendor-specific error codes.

There is certainly a long history of implementation-specific error codes 
being defined. These are typically used during development, and are also 
present in released producs especially where the vendor believes that they 
have added function over the base specifications.

Since operators do not have access to source code, it might be assumed to be 
improbable that an operator would define an error code. Since the "users" 
are the operators, we might claim that the I-D, object, fields, and error 
codes are badly named.

If changing the name of all of these things is felt to be important, I'm 
sure I don't mind. OTOH, I can also conceive of configuration or policy that 
controls error codes and (in particular) error strings for the use by 
operators (i.e. users) in their own environment.

> Identifier (OID) that points to the IANA assigned "SMI Network Management 
> Private Enterprise Codes" value (see [RFC3232]).

The IANA registry http://www.iana.org/assignments/enterprise-numbers 
contains the enterprise codes. This registry is referenced as being created 
by RFC2578. I'll add a reference to the I-D.

The values maintained in the registry are just integers. I don't see any 
reason why using 32 bits is inappropriate in RSVP.

> Then, you need to provide a field for the error code. Often 3 bytes are 
> sufficient.

I'm not sure why you say three bytes.
Actually, RSVP uses just two bytes for the error value as we do in this I-D.
The other field in RSVP (the error code) is not needed here.

> You seem to split these 3 bytes into 1 byte for a "Sub Org " and another 2 
> bytes for the actual error code value.

I don't think the Sub Org is a filter on the error value. It is a qualifier 
of the enterprise I-D. For example, to separate R&D from product. Or core 
transport, from enterprise.Or to separate (as the I-D suggests) different 
development teams in the same organisation. Effectively, it reduces the 
effort for a central registry in a large organisation.

It is an optional field.

> I believe it is more common to just merge the 1+2 bytes together since a 
> vendor will hopefully be able to manage the allocation of unique values.

If that is the case, just the 2 bytes can be used. 2 bytes is surely enough 
for any organisation.
The 1 byte can be left unused.

> rather for other SDOs, since they are also listed as vendors.

Hmmm.
You are welcome to your suspiscions!
They are unfounded and offensive, but you have every right to voice them.

It is true that several OIDs have registered for enterprise codes.

> document "user-defined" errors instead of vendor-specific error codes

Given your puzzlement and my assertion that we did not write the draft for 
other SDOs, a possibility very you may regretfully have to consider is that 
we chose the name "user-defined" because we meant it.

> their own error messages?

Seems very common to me in my limited experience of implementing code over 
the last 20 years and working with RSVP over the last 10 years.

> Could that lead to interoperability problems?

What does interoperability mean in this case?
The I-D describes what an implementation should do with the object if they 
are not party to the enterprise.
The object class number is from the range 192 - 247 to allow backward 
compatibility.
The Error_Spec object remains mandatory.

I think there is only one possible interop problem. An implementation might 
decide to use the new Error Code "User Error Spec". It would do this in the 
case described in section 4.1:
   If no other error code applies,
   the Error Code in the ERROR_SPEC object MUST be set to "User Error
   Spec" as defined in Section 2 of this document.
Thus, the problem would arise for a new error condition, not one that is 
already defined by an existing (or future) RFC.

Clearly, an implementation making this choice would be sending an error that 
could only be understood by an implementation that shared the same 
enterprise view. Although such an error could be logged, it could not be 
acted on.

I wonder if we should define the "User Error Spec" error code as coming out 
of the same mould as the "Notify" error code. In that way, all uses would be 
purely informational.

Thanks,
Adrian

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 06 Oct 2007 20:39:18 +0200

Hi Adrian,

Adrian Farrel wrote:
> There is certainly a long history of implementation-specific error 
> codes being defined. These are typically used during development, and 
> are also present in released producs especially where the vendor 
> believes that they have added function over the base specifications.
>
> Since operators do not have access to source code, it might be assumed 
> to be improbable that an operator would define an error code. Since 
> the "users" are the operators, we might claim that the I-D, object, 
> fields, and error codes are badly named.
>
> If changing the name of all of these things is felt to be important, 
> I'm sure I don't mind. OTOH, I can also conceive of configuration or 
> policy that controls error codes and (in particular) error strings for 
> the use by operators (i.e. users) in their own environment.
>
I am not sure why you want to become creative when well-established 
terminology is available.

>> Management Private Enterprise Codes" value (see [RFC3232]).
>
> contains the enterprise codes. This registry is referenced as being 
> created by RFC2578. I'll add a reference to the I-D.
>
> The values maintained in the registry are just integers. I don't see 
> any reason why using 32 bits is inappropriate in RSVP.
>
My understanding was that the vendor-specific part is only 3 octets 
long; not 4 octets.

>> Then, you need to provide a field for the error code. Often 3 bytes 
>> are sufficient.
>
I was referring to the 3 bytes instead of 4 bytes of the Enterprise number.

>
>> You seem to split these 3 bytes into 1 byte for a "Sub Org " and 
>> another 2 bytes for the actual error code value.
>
> I don't think the Sub Org is a filter on the error value. It is a 
> qualifier of the enterprise I-D. For example, to separate R&D from 
> product. Or core transport, from enterprise.Or to separate (as the I-D 
> suggests) different development teams in the same organisation. 
> Effectively, it reduces the effort for a central registry in a large 
> organisation.
I believe that this sub-devision is not necessary. Every enterprise can 
decide on their own how they want to manage (and potentially split 
their) available number space.

>
> It is an optional field.
>
>> I believe it is more common to just merge the 1+2 bytes together 
>> since a vendor will hopefully be able to manage the allocation of 
>> unique values.
>
> If that is the case, just the 2 bytes can be used. 2 bytes is surely 
> enough for any organisation.
>> I further suspect that you wrote this draft not really for vendors 
>> but rather for other SDOs, since they are also listed as vendors.
>
> Hmmm.
But when you write such a document you need to understand the 
consequences when an SDO defines their own RSVP errors since they are 
not interested to go to the IETF todo that. This this sound so extremely 
unlikely?

> Given your puzzlement and my assertion that we did not write the draft 
> for other SDOs, a possibility very you may regretfully have to 
> consider is that we chose the name "user-defined" because we meant it.
>
>> Do you think that it is so common that vendors or other SDOs will 
>> define their own error messages?
>
> Seems very common to me in my limited experience of implementing code 
> over the last 20 years and working with RSVP over the last 10 years.
>
> The I-D describes what an implementation should do with the object if 
> they are not party to the enterprise.
> I think there is only one possible interop problem. An implementation 
> might decide to use the new Error Code "User Error Spec". It would do 
> this in the case described in section 4.1:
> Thus, the problem would arise for a new error condition, not one that 
> is already defined by an existing (or future) RFC.
>
> Clearly, an implementation making this choice would be sending an 
> error that could only be understood by an implementation that shared 
> the same enterprise view. Although such an error could be logged, it 
> could not be acted on.
>
> I wonder if we should define the "User Error Spec" error code as 
> coming out of the same mould as the "Notify" error code. In that way, 
> all uses would be purely informational.
>
I just wanted to share my experience with these type of extensibility 
mechanisms with you. When other SDOs figure out that such an 
extensibility mechanisms exists then they will use it (probably in a way 
you haven't envisioned and wouldn't expect). If you do not consider the 
impact of some of these extensions then you might run into 
interoperability problems. These are not totally artificial concerns, as 
I had to learn with Diameter.

Ciao
Hannes

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 6 Oct 2007 23:01:39 +0100

Hi Hannes,

>> present in released producs especially where the vendor believes that 
>> they have added function over the base specifications.
>>
>> Since operators do not have access to source code, it might be assumed to 
>> be improbable that an operator would define an error code. Since the 
>> "users" are the operators, we might claim that the I-D, object, fields, 
>> and error codes are badly named.
>>
>> sure I don't mind. OTOH, I can also conceive of configuration or policy 
>> that controls error codes and (in particular) error strings for the use 
>> by operators (i.e. users) in their own environment.
>>

Sure, if the WG wants to change it, we'll change it. Maybe people will speak 
up.

> My understanding was that the vendor-specific part is only 3 octets long; 
> not 4 octets.

I'm sure you're right. I don't have time to chase this down. I looked in 
your referenced RFC and it is obviously not the one you meant.

If three bytes are enough to hold the enterprise number, then I'm sure four 
bytes will contain it. Since RSVP objects are aligned to double words, using 
a 3-byte field here, would just give us an unused/reserved byte. So I don't 
see a lot of point in changing this.

> I was referring to the 3 bytes instead of 4 bytes of the Enterprise 

OK. Although your very next sentence refered to the use of three bytes for 
the error codes, as:

>>> You seem to split these 3 bytes into 1 byte for a "Sub Org " and another 
>>> 2 bytes for the actual error code value.
>>
> decide on their own how they want to manage (and potentially split their) 
> available number space.

You are right. They could. They can still do so in the I-D as currently 
specified. Or they can avoid complicated management strategies by using a 
hierarchical space.

> But when you write such a document you need to understand the consequences 
> when an SDO defines their own RSVP errors since they are not interested to 
> go to the IETF todo that. This this sound so extremely unlikely?

They can (and do) already define their own error codes under RFC3936.
Under that scheme they are supposed to register with IANA for each code.

On the whole, I don't think error codes are such a terrible thing to be 
worried about. Far more important to worry about new protocol objects and 
messages that create broken usage and real interoperability problems.

>> for other SDOs, a possibility very you may regretfully have to consider 
>> is that we chose the name "user-defined" because we meant it.
>>
>> Clearly, an implementation making this choice would be sending an error 
>> that could only be understood by an implementation that shared the same 
>> I wonder if we should define the "User Error Spec" error code as coming 
>> out of the same mould as the "Notify" error code. In that way, all uses 
>> would be purely informational.
>>
> mechanisms with you. When other SDOs figure out that such an extensibility 
> mechanisms exists then they will use it (probably in a way you haven't 
> envisioned and wouldn't expect). If you do not consider the impact of some 
> of these extensions then you might run into interoperability problems. 
> These are not totally artificial concerns, as I had to learn with 
> Diameter.

Thanks for sharing your experiences.
I also have had some experience with other SDOs (non-SDOs) making use of 
IETF protocols in a way that the IETF finds hard to stomach. Hence RFC4929.

Regards,
Adrian