[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mpls
Subject:    Re: [mpls] [Tsvwg] WG last
From:       "Adrian Farrel" <adrian () olddog ! co ! uk>
Date:       2008-03-31 21:47:30
Message-ID: 025201c89378$f29f1690$0300a8c0 () your029b8cecfe
[Download RAW message or body]

Hi Jukka,

> I have read the draft, and think it is a reasonable proposal, and
> presented well. I have just a few minor comments/clarification requests:
>
> - What is exactly meant by "it is RECOMMENDED that organizations use a
>  published scheme for this string to promote consistent decoding."? Could
>  you add an example, perhaps?

Ah. Probably over-enthusiastic text created when we added the Error 
Description string before this became a WG I-D.

What we meant was that it might be helpful to a device that is going to a 
user that is going to read this string if they knew that a string coming 
from a device made by vendor X should be interpreted in a particular way. 
For example, date stamp, IP address, error string.

However, looking at this again, I would be happy to strike this text.

> - Is it possible to not include the Error Description? If so, this could
>  be said explicitly.

Yes, the length can be set to zero, in which case there are no bytes of 
description string.

I can clarify this.

> - Is it possible to not include User-defined subobjects? If so, this could
>  be said explicitly.

We already have:
        User-defined subobjects MAY be included.

I think that is sufficiently explicit that it is possible to not include 
them.

> These latter two comments are about making the user error propagation a
> bit simpler, e.g., one could primarily use the extended number space to
> define new error values, but leave in some cases the description and
> subobjects out to save bytes.

Agreed, and that is our intention.

Does that work for you?

Adrian 


_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
[prev in list] [next in list] [prev in thread] [next in thread]