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

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 14 Feb 2008 23:07:37 -0000

Hi,

>> I read through the document again to figure out what happens if a node
>> receives a message with this new error code but he does not understand
>> it. So, what happens?

The processing rules for a node that does not understand an RSVP object are 
defined in RFC 2205 and depend on the Class Number.

This I-D requests that the new object have a class number assigned from the 
range 192 - 247.

The rules for this range are described in section 3.10 of RFC 2205.

<extract>
           There are three possible ways that an RSVP implementation can
           treat an object with unknown class.  This choice is
           determined by the two high-order bits of the Class-Num octet,
           as follows.
[SNIP]
           o    Class-Num = 11bbbbbb
                The node should ignore the object but forward it,
                unexamined and unmodified, in all messages resulting
                from this message.

           The following more detailed rules hold for unknown-class
           objects with a Class-Num of the form 11bbbbbb:

           1.   Such unknown-class objects received in PathTear,
                ResvTear, PathErr, or ResvErr messages should be
                forwarded immediately in the same messages.
</extract>

As it says in this I-D
   This is
   done for backward compatibility.  Existing implementations will
   ignore the object and pass it along according to the rules of
   [RFC2205].

I don't think it is necessary to provide any further description.

>> I also ran into a couple of statements that only specified SHOULDs
>>
>>    Implementation capable of interpreting
>>    the contents of the USER_ERROR_SPEC object SHOULD take appropriate
>>    action.
>>
>> I don't think that this sentence makes a lot of sense. Particularly the
>> RFC 2119 SHOULD does not help interoperability a lot.
>
>I think the above may be best handled by not using 2119 language at all.
>I would replace it with "is expected" or something like that.

OK. Lower case "should" as suggested by Bob is fine with me.

However, I find myself caught on the barb of one of my pet hates: viz. 
"appropriate".

I have changed the sentence to...

   Implementations capable of
   interpreting the contents of the USER_ERROR_SPEC object should take
   further action based on the reported error.

>>    If a message is received containing an ERROR_SPEC object using the
>>    "User Error Spec" error code, but not containing a USER_ERROR_SPEC
>>    object, the message SHOULD be treated as malformed and handled
>>    according to [RFC2205].
>>
>> What happens if the node does not treat it as malformed?
>> Maybe this should be replaced with a MUST
>
>I agree that this needs to be binding. I think "SHALL" fits better.

It is a little academic since RFC 2205 says...

   Should a programming
   error allow an RSVP to create a malformed message, the error is not
   generally reported to end systems in an ERROR_SPEC object; instead,
   the error is simply logged locally, and perhaps reported through
   network management mechanisms.

So applying a MUST/SHALL in this I-D is OK by me.
(I prefer MUST as SHALL sounds rather Biblical in this context!)

>>    Implementations SHOULD ignore repeated occurences of USER_ERROR_SPEC
>>    objects, and SHOULD forward them unchanged on any messages that they
>>    forward.
>>
>> Why should they ignore them? Why does it help to forward them? There
>> might be a persistent problem.
>
>Here I personally don't have any opinion. But it seems that this must be
>resolved.

The reason is for forward compatibility.
If tomorrow you invent a reason to include multiple User_Error_Spec objects, 
you do not want to find that nodes in the core of the network (that do not 
need to examine the objects) are stripping them out or dropping the 
messages.

I have inserted the reasoning in draft.

>>    Implementations receiving a USER_ERROR_SPEC object on some message
>>    other than a PathErr, ResvErr, or Notify message SHOULD treat the
>>    error as a malformed message and process according to [RFC2205].
>>
>> Again, why not a MUST?
>
>Yes, as before I think this should be binding behavior for an
>implementation following this specification.

Same as above.
So changed to MUST.

I will post a revised version. Changes (as listed in section 0 of the I-D) 
are a collection of nits from the last few months as follows:
   - Add reference to RFC 2578.
   - Add text to Abstract.
   - Section 4.2, para 1. Resolve "SHOULD" to "should" and replace
     "appropriate".
   - Section 4.2, para 2. Replace "SHOULD" with "MUST".
   - Section 4.2, para 3. Provide reason for ignoring repeated objects.
   - Section 4.2, para 4. Replace "SHOULD" with "MUST".

Cheers,
Adrian

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 14 Feb 2008 18:00:50 -0600

Adrian

Thanks for the detailed update

James

At 05:07 PM 2/14/2008, Adrian Farrel wrote:
>The processing rules for a node that does not understand an RSVP 
>object are defined in RFC 2205 and depend on the Class Number.
>
>This I-D requests that the new object have a class number assigned 
>from the range 192 - 247.
>
>However, I find myself caught on the barb of one of my pet hates: 
>viz. "appropriate".
>
>If tomorrow you invent a reason to include multiple User_Error_Spec 
>objects, you do not want to find that nodes in the core of the 
>network (that do not need to examine the objects) are stripping them 
>out or dropping the messages.
>
>I will post a revised version. Changes (as listed in section 0 of 
>the I-D) are a collection of nits from the last few months as follows: