Subject: [Tsvwg] Comments on draft-ietf-tsvwg-rsvp-user-error-spec-03.txt

From: Bruce Davie <[email-masked]>
Date: Fri, 21 Mar 2008 17:31:52 -0400

I believe the chairs were looking for some reviews on this draft  
before letting it go past last call. Here is one.

Summary: the draft looks basically fine to me.

Minor comments to show that I read it.

Bruce

>
> 2. User-Defined Error
>
>    A new Error Code is defined for use in an ERROR_SPEC object.
>
>       Error Code = <tba-xxx>: User Error Spec
>
>       This error code is used to signal the presence of a
>       USER_ERROR_SPEC.  No subcodes are defined.

RFC2205 users the term "Error Value" rather than "subcode". I suggest  
using the same terminology here.

>
> 3. USER_ERROR_SPEC Class
>
>    A new RSVP object class is defined called the the USER_ERROR_SPEC
>    Class.  The class number is taken from the range 192 - 247.   
> This is
>    done for backward compatibility.  Existing implementations will
>    ignore the object and pass it along according to the rules of
>    [RFC2205].
>

I thought this could be written a little more clearly (especially  
when you consider that, when this is published, there will be an  
actual class number assigned). How about this:

A new RSVP object class called USER_ERROR_SPEC is defined. To support  
backwards compatibility, its class number is in the range 192-247. As  
defined in [RFC2205], implementations that do not understand such an  
object will forward it unmodified.

>      User Error Value
>
>         A 16-bit integer. The format and contents are specified by
>         the (sub-)organization indicated by the Enterprise Number
>         and Sub Org fields.

I think what you mean to say its *meaning* is specified by the (sub-) 
organization indicated by the Enterprise Number and Sub Org fields.

> 4.2
[...]
>    Implementations receiving a USER_ERROR_SPEC object on some message
>    other than a PathErr, ResvErr, or Notify message MUST treat the
>    error as a malformed message and process according to [RFC2205].

RFC2205 allows ERROR_SPEC objects in ResvConf messages. I suggest the  
USER_ERROR_SPEC should also be allowed to appear in those messages.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 28 Mar 2008 14:58:52 -0000

Bruce,

Thanks for reading.

Please see in line.

Adrian

> using the same terminology here.

Good.

>>    Class.  The class number is taken from the range 192 - 247.  This is

OK
 
> organization indicated by the Enterprise Number and Sub Org fields.

Yup.

> USER_ERROR_SPEC should also be allowed to appear in those messages.

In fact, the ERROR_SPEC is mandatory on the ResvConf, but RFC 2205 says:

         The ERROR_SPEC is
         used only to carry the IP address of the originating node, in
         the Error Node Address; the Error Code and Value are zero to
         indicate a confirmation.

So there would never be cause to include USER_ERROR_SPEC. Or would there?

---

From: Bruce Davie <[email-masked]>
Date: Fri, 28 Mar 2008 12:52:06 -0400

Adrian,
[points of agreement clipped]

On Mar 28, 2008, at 10:58 AM, Adrian Farrel wrote:

>> RFC2205 allows ERROR_SPEC objects in ResvConf messages. I suggest  
>> the  USER_ERROR_SPEC should also be allowed to appear in those  
>> messages.
>

Your reasoning seems sound to me. Perhaps you want to put in a  
sentence along these lines to avoid future readers scratching their  
heads as I did.

So, with the few changes that I sent previously and that you agreed  
to, I think this document would be ready for publication.

Bruce

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 28 Mar 2008 17:08:01 -0000

Thanks Bruce!

I made the changes you suggested and added a note about ResvConf.

New version submitted.

Cheers,
Adrian