RE: no overall type in Extended Attributes

["Glen Zorn" <glenzorn@comcast.net>]

Alan DeKok [mailto:aland@deployingradius.com] writes:

> Glen Zorn wrote:
> > Maybe I didn't say it correctly.  I want to name a group of TLVs, I
> guess.
> > to get a structure like that of, say the MS-CHAP-CPW-1 Attribute only
> using
> > the TLV construct,
> 
>   Isn't that what the tags are for?

Not historically.  In RFC 2869, for example, the Tag field is used to group
sets of attributes in an ad-hoc fashion: there's no requirement placed on
the actual membership  of the groups & different groups can contain
different sets of attributes in the same message.

> 
>   Foo:1 = 1
>   Bar:1 = "hello"
>   BaZ:1 = "foo"
> 
>   It's not a nice name, but it's a name.

It's a very inefficient encapsulation, too, since all of the TLVs could be
carried in a single extended attribute.

> 
> >>   So... what's a "named, multi-TLV attribute"?  An attribute inside
> of
> >> the Extended-Attribute that can carry other TLV's?  Like what's done
> in
> >> WiMAX?
> >
> > Maybe, I'm open; that's why I asked :-).
> 
>   The main difficulty with that is it's hard to distinguish between
> different sets of nested TLV's.  Requiring them to be grouped would
> help.
> 
>   e.g.  An "encapsulating tlv" has sub-tlv's A, B, and C.  What do you
> do if you want to send *two* copies of "encapsulating tlv", each with
> different values for A, B, and C?
> 
>   My guess would to use tags.  The sub-tlv's can be referred to as
> "A:1", which would mean "A, encapsulated in it's TLV, which is
> encapsulated in Extended-Attribute, which is encapsulated in
> Vendor-Specific."
> 
>   Ugh.  But it works:
> 
>    A:1 = foo
>    B:1 = 1
>    C:1 = 1.2.3.4
>    A:2 = bar
>    B:2 = 42
>    C:2 = 192.168.0.1
> 
>   Alan DeKok.



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