RE: no overall type in Extended Attributes

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

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

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

Right.  The example is related to security...anyway, here's an idea: how
about breaking the Ext-Type field into 2 8-bit fields one of which stays in
the Extended Attribute header (giving naming capability for the attribute
itself) & the other staying in the TLV header?  

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