RE: Subtypes (again) and other ideas

[Avi Lior <avi@bridgewatersystems.com>]

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] 
> Sent: Tuesday, January 27, 2004 3:32 PM
> To: 'Avi Lior'; 'Victor Gamov'; radiusext@ops.ietf.org
> 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?

It is. 

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

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
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-lior-radius-attribut
e-type-extension-00.txt 

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