[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Subtypes (again) and other ideas
> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: Tuesday, January 27, 2004 3:32 PM
> To: 'Avi Lior'; 'Victor Gamov'; email@example.com
> Subject: RE: Subtypes (again) and other ideas
> 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.
But don't forget my other reason. Not using application space allows us to
I think that there is a better approach to handling the limited attribute
space for RADIUS. I already posted an internet draft for that. See
> 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 firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.