Re: Draft of extensions format

[Peter Deacon <peterd@iea-software.com>]

On Fri, 3 Sep 2010, Peter Deacon wrote:

> I'm going to use an example from an actual wimax attribute to reduce the 
> chance of any dis-ambiguity.

> For this example I will be using the wimax QoS-Descriptor:
> Its structure is as follows:
>
> 1 byte -RADIUS  Type (26)
> 1 byte - RADIUS Length
> 4 bytes - Vendor ID
> 1 byte - Wimax type (29)
> 1 byte - Length
> 1 byte - Continuation
> TLV1..
> TLV2..
> TLV3..
> TLVn...

Please disregard, I get it now.  This is all essentially describing wimax 
and works the same way and I can do the same thing.

For some reason I kept getting hung up on the meaning of the type field in 
the container which is my fault.  I came back to understand something I 
knew implicitly but didn't register for some reason:

Every time I look at the TLV description all I see is "nesting" 
"encapsulation" and "container" as in attributes within attributes never 
attributes NEXT to attributes and it wasn't clear to me thats what was 
being described. Its my fault.

From 2.3.1

"That is, the "container" TLV-Length field MUST be exactly two (2)
   more than the sum of the "contained" TLV-Length fields."

If the container is not a TLV itself but instead an Extension attribute 
then there is no containing TLV-Length field actually present on the 
wire.

The length field in this case is the extensions length field which is an 
extension header representing a TLV value.

I just have to switch between "wire view" and "logical view" to keep 
things straight :(

regards,
Peter

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>