Re: no overall type in Extended Attributes

[Alan DeKok <aland@deployingradius.com>]

Glen Zorn wrote:
> No, I said that I want to name an attribute that consists of a group of
> TLVs, not the same thing.

  Hmm... the number space for the Extended-Types is flat.  So one
attribute cannot "consist of" a group of TLV's.

>  For example: a cryptosuite consists of a an
> encryption algorithm identifier and an integrity-protection algorithm
> identifier.  Multiple cryptosuite attributes can be in the same message.
> Both the integrity-protection and encryption algorithms MUST be present or
> the cryptosystem attribute is malformed.  I know how to do this easily & in
> a way that comprehensible in Diameter or w/a legacy RADIUS attribute.

  Diameter has a "group" attribute, which is easy.  I don't know how to
do this with a legacy attribute, other than via a complex type.

> Apparently it is not possible to specify such a thing in an easily
> comprehensible fashion using Extended Attributes.  I consider this to be a
> problem (now -- I didn't before because I hadn't run into this,
> short-sighted, I know); I'm not sure why (given your sympathetic concern for
> programmers who would separate the word "hello" into 5 different attributes
> ;-) do not.

  I don't see a problem with sub-TLV's, like is done for WiMAX.  The
various vendors will be implementing WiMAX anyways, so adding sub-TLV's
here wouldn't be a problem.

  This would involve extending the RADIUS data model to include a "tlv"
type.  If the format is the normal 8-bit type, 8-bit data, it would be
compatible with the WiMAX definition, the 3GPP definitions, and perhaps
some other vendor-specific definitions.

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