RE: Subtypes (again) and other ideas

[Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>]

Hi Avi,

I am not sure, if I understand the problem you are raising below.
Are you saying that a sub attribute out of for instance WLAN attribute
(which is treated as a vendor specific) needs security, then that piece
of data cannot be a subattribute anymore?
If true, although I agree that is a problem, but isn't that already a 
problem for vendor specific attributes?
The suggested idea seems to be the best way to handle all the new applications
that are popping up with the limited attribute space.
Furthermore, this approach won't tie the hand of application designers
to have to map all their data into existing attributes.

Regards,
Madjid

>
I have some issues with the above scheme:

You want to introduce application spaces by allowing us to group attributes
for a given application into a single attribute.  There is a problem with
this approach.

If one of these attributes for example had to password protected then this
would break base radius processing.  We would have to promote the attribute
such that it appears as a base radius attribute breaking the scheme you
propose.

Secondly, we should strive to reuse attributes as much as possible.  Note I
don't mean overload attributes but when an attribute is symmatically the
same for two applications it should be reused.

 

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