Subject: [Tsvwg] Re: Comments on draft-ietf-tsvwg-user-error-spec-01

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 19 Sep 2007 23:29:55 +0100

Hi,

> I did reveiw the draft before the meeting. Sorry to be slow in sending
> out the comments.

Sorry for the delay in responding.

> 1. Is it really the best use of User_ERROR_SPEC object to only allow it on 
> the new Error Code? I can understand the desire to allow error reporting 
> in case previously not possible. But is there not a benefit in allowing 
> the USER_ERROR_SPEC object to be present also for other error codes? Thus 
> allowing implementations to provide additional information when existing 
> error codes is the correct ones to be used?

No, you're right. Requiring that the Error Code in the OLD ERROR_SPEC object 
is set to "User Error Spec" would be wasteful and not fully flexible.

In section 4.1 (Procedures for Sending the User Error Spec) we have "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." That is 
to say, we allow the USER_ERROR_SPEC to be present for any error code.

But we also say (in section 4.2) "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]." In other words, *if* the new error code is 
used, it mst be used to indicate the present of the USER_ERROR_SPEC.

If we have messed up (likely!) and also said somewhere that the 
USER_ERROR_SPEC dictates the use of the "User Error Spec" code, can you 
point us at the text so we can fix it?

> 2. I think you need to clarify which numbers from IANA that needs to go 
> where. I would recommend that you use different identifiers for numbers to 
> be assigned in the text and then are clear in the IANA section which 
> number that comes from which place.

OK.

There are only two numbers to be assigned, but I will replace the "<tba>" 
tags with explict "<xxx>" and "<yyy>" tags to make it clearer.

> 3. Section 3.1: Length definition:
> "The Length contains the total length of the subobject in bytes,
>         including the L, Type and Length fields."
>
> What is the "L" in the subobject?

Duh-oh! Good catch - well read.
Custard paste problem.
(Prize for the first person who can point at where we cut this from.)

Many thanks.

Adrian

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Sep 2007 10:50:00 +0200

Adrian Farrel skrev:
>> 1. Is it really the best use of User_ERROR_SPEC object to only allow
>> it on the new Error Code? I can understand the desire to allow error
>> reporting in case previously not possible. But is there not a benefit
>> in allowing the USER_ERROR_SPEC object to be present also for other
>> error codes? Thus allowing implementations to provide additional
>> information when existing error codes is the correct ones to be used?
> 
> No, you're right. Requiring that the Error Code in the OLD ERROR_SPEC
> object is set to "User Error Spec" would be wasteful and not fully
> flexible.
> 
> In section 4.1 (Procedures for Sending the User Error Spec) we have "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." That is to say, we allow the USER_ERROR_SPEC to be present
> for any error code.
> 
> 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]." In other words, *if* the
> new error code is used, it mst be used to indicate the present of the
> USER_ERROR_SPEC.
> 

I think the issue is that you are not explicitely saying that it MAY be
used for any Error Code, rather than being explicetly forbidden. I think
it easily can be fixed in the first sentence in Section 4.1:

OLD:
   A USER_ERROR_SPEC object MAY be included in any PathErr, ResvErr, or
   Notify message.

NEW:
   A USER_ERROR_SPEC object MAY be included in any PathErr, ResvErr, or
   Notify message for any valid error code.

> (Prize for the first person who can point at where we cut this from.)

As I am a sucker for getting prizes I will guess on RFC 3209, Section
4.3.3.

Cheers

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, 20 Sep 2007 10:05:54 +0100

Magnus

>   Notify message for any valid error code.

OK.
I'll replace "valid" with "defined" since "any valid error code" tends to 
imply that there are some codes you can do it for, and some codes that you 
can't.

> As I am a sucker for getting prizes I will guess on RFC 3209, Section

An your prize is...

You get to write the Security Considerations section ;-)

Cheers,
Adrian

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Sep 2007 11:11:44 +0200

Adrian Farrel skrev:
> I'll replace "valid" with "defined" since "any valid error code" tends
> to imply that there are some codes you can do it for, and some codes
> that you can't.

Sure.

> You get to write the Security Considerations section ;-)

You probably wouldn't like that. I might put in a couple of realy nasty
requirements ;-).

Cheers

Magnus Westerlund