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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 08 Nov 2007 10:15:00 +0100

Hi,

There are a few open issues in this thread. I would like to come to some
conclusion on them so that we can complete this work and go on. So
please provide your view on the following issues:

A. Change User-error to Vendor specific error? I like to see if other
feel this is important before requiring the authors to do work.

B. If the suborg field should be incorporated a 24 bit long error code
number space scoped by the Enterprise number? Also in this case if no
one supports such a change and provides their view on why it is
motivated we will leave it as it is.

C. If the user error mechanism is a serious interoperability issue.
Hannes proposed to make it purely informative, which it clear isn't
today as it also defines a ERROR_SPEC error code meaning user error.
Opinions on this? Unless there is a clear consensus on changing this we
will leave it as it is.

Please provide any comments before the 22nd of November.

Magnus Westerlund
(as WG chair)

Adrian Farrel skrev:
> Hi Hannes,
> 
>>>> If I understood this document correctly then it essentially suggests
>>>> 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.
>>>
>> I am not sure why you want to become creative when well-established
>> terminology is available.
> 
> Sure, if the WG wants to change it, we'll change it. Maybe people will
> speak up.
> 
>>>> 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]).
>>>
>>> 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.
>>>
>> 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.
> 
>>>> 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.
>>
>> I was referring to the 3 bytes instead of 4 bytes of the Enterprise
>> number.
> 
> 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.
>>>
>>> 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.
> 
> 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.
> 
>>> 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.
>>>
>>>> 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.
>>> 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.
>>>
>> 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.
> 
>>>> 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.
>>>
>>> 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.
>>>
>>>> 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.
>>>
>> 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.
> 
> 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
> 
> 
> 
> 

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 8 Nov 2007 17:57:11 -0000

Hi,

Appreciate the effort to close this down.

> feel this is important before requiring the authors to do work.

I'm not bothered really (what's in a name?).

Note that some implementations might allow interaction with policy or 
management modules that could supply error information making this "user" 
data, or (as previously expressed by various people) this might be limited 
per implementation making it vendor specific.

> motivated we will leave it as it is.

I don't see a lot of value in folding it all together, but also can't get 
excited either way.

> Opinions on this? Unless there is a clear consensus on changing this we

I don't buy into this being an interoperability issue at all.
The object is optional and in addition to the existing ERROR_SPEC.

Normal processing will be to use existing error codes in the ERROR_SPEC and 
additional information in the USER_ERROR_SPEC.

New error codes are frequently defined for inclusion in the ERROR_SPEC 
object and the procedure for handling unknown error codes is well defined.

The use of the new error code defined here "User Error Spec" for use when 
"no other error code applies."

Vendors that do not understand each other's user error codes (as well they 
might not) will still be able to log all of the information which includes:
- the IP address of the reporting node
- the enterprise number of the reporting node
- the user error code
- a printable string

Although some actions can be performed based entirely on error codes, these 
would normally be the key error codes defined by protocol specs, not the 
additional user errors defined as vendor-specific. Thus one vendor's 
implementation might take specific (proprietary) action based on the user 
error code, but another vendor's implementation would act on the ERROR_SPEC 
error code and simply log (as it would be expected to log any error) the 
additional information from the USER_ERROR_SEPC.

Note that I have a revision with a few tiny changes:
   - Add reference to RFC 2578.
   - Add text to Abstract.
on my hard drive, but was holding off submitting it pending any further 
requests for change.

Cheers,
Adrian

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 08 Nov 2007 21:03:57 +0100

Hi Adrian,
Hi Magnus,

thank you Adrian for your response and to Magnus for summarizing the 
raised issues.

> I'm not bothered really (what's in a name?).
There question here really is: Why not to use well established 
terminology with a document like this?

> management modules that could supply error information making this 
> "user" data, or (as previously expressed by various people) this might 
> be limited per implementation making it vendor specific.
The concept of establishing a registry for errors codes is different to 
the semantic of a specific error or the reason why the error is caused.

> I don't see a lot of value in folding it all together, but also can't 
> get excited either way.
It was a obvious question whether there is a reason behind this given 
that it is different than the approaches used in other areas.

> Normal processing will be to use existing error codes in the 
> ERROR_SPEC and additional information in the USER_ERROR_SPEC.
>
> The use of the new error code defined here "User Error Spec" for use 
> when "no other error code applies."
>
> Vendors that do not understand each other's user error codes (as well 
> they might not) will still be able to log all of the information which 
> includes:
> Although some actions can be performed based entirely on error codes, 
> these would normally be the key error codes defined by protocol specs, 
> not the additional user errors defined as vendor-specific. Thus one 
> vendor's implementation might take specific (proprietary) action based 
> on the user error code, but another vendor's implementation would act 
> on the ERROR_SPEC error code and simply log (as it would be expected 
> to log any error) the additional information from the USER_ERROR_SEPC.
>
>
> on my hard drive, but was holding off submitting it pending any 
> further requests for change.
>
I will think about your description and will respond to you later.

Ciao
Hannes