RE: Potential work items

[Avi Lior <avi@bridgewatersystems.com>]

If I remember correctly, the Home RADIUS server has to interpret the
attibutes.

A proxy server will never have to look at these attributes.  The Home Radius
server will have a specific application running on it to interpret the
attributes and act on them.  Therefore, since proxy servers don't have to
parse the attributes and the home radius will have a custom application on
it; doesn't it make sense to still allow these attributes to be packed
(somehow) in a String?  

> -----Original Message-----
> From: Alan DeKok [mailto:aland@ox.org] 
> Sent: Thursday, January 08, 2004 11:14 AM
> To: radiusext@ops.ietf.org
> Subject: Re: Potential work items 
> 
> 
> wolfgang.beck01@t-online.de (Wolfgang Beck) wrote:
> > > b. Don't require changes to the RADIUS dictionary (e.g. no 
> > > sub-types).
> > This is ugly. I expect that 20 - 40 attributes are to be expected 
> > (extensions to RfC 2595 are constantly added). As this data doesn't 
> > need to be interpreted by the RADIUS server, I don't see a 
> reason why 
> > sub-attributes are bad here.
> 
>   If the data isn't interpreted by the RADIUS server, then it 
> may be packed into a list of one attribute, like EAP-Message.
> 
>   i.e. using RADIUS to transport opaque data for "foo" should 
> be solved by creating a "packed-foo-message" attribute, and 
> not a RADIUS attribute for every field in "foo".
> 
>   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/>
> 

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