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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 11 Jan 2008 17:03:35 +0100

Magnus Westerlund skrev:
> 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.

Hi,

It is now definitely later than 22nd of November and no further input 
has come on this subject.

After having thought about A bit more, I think it makes sense to change 
this to vendor specific. So Adrian please change that. On the other two 
please leave them as they are.

When the new version is available we will do a WG last call.

Cheers

Magnus Westerlund

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

---

From: <[email-masked]>
Date: Mon, 28 Jan 2008 09:34:45 +0200

Hi Magnus, 

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?  

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. 

   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

   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. 

   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? 

Ciao
Hannes

-----Original Message-----
From: ext Magnus Westerlund [mailto:[email-masked]] 
Sent: 11 January, 2008 18:04
To: Magnus Westerlund
Cc: tsvwg
Subject: Re: [Tsvwg] Re:I-D
Action:draft-ietf-tsvwg-rsvp-user-error-spec-02.txt

Magnus Westerlund skrev:
> 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:
> 

> Opinions on this? Unless there is a clear consensus on changing this 
> we will leave it as it is.
> 

Hi,

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 28 Jan 2008 09:20:08 +0100

Hi Hannes,

Some personal opinions below. Comments from authors and other WG 
participants highly appreciated.

> 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.

> Maybe this should be replaced with a MUST

I agree that this needs to be binding. I think "SHALL" fits better.

> Why should they ignore them? Why does it help to forward them? There

Here I personally don't have any opinion. But it seems that this must be 
resolved.

>    error as a malformed message and process according to [RFC2205].

Yes, as before I think this should be binding behavior for an 
implementation following this specification.

Cheers

Magnus Westerlund