RE: backwards compatible introduction of NEW attribute such as CUI

["Congdon, Paul T (ProCurve)" <paul.congdon@hp.com>]

These are all good points... If the overhead isn't that significant to
advertise each time, then I agree that the stateless benefits outweigh
this potential optimization.

Paul 

> -----Original Message-----
> From: Barney Wolff [mailto:barney@databus.com] 
> Sent: Tuesday, December 14, 2004 9:37 AM
> To: Congdon, Paul T (ProCurve)
> Cc: Lothar Reith; Nelson, David; radiusext@ops.ietf.org
> Subject: Re: backwards compatible introduction of NEW 
> attribute such as CUI
> 
> On Tue, Dec 14, 2004 at 09:04:32AM -0800, Congdon, Paul T 
> (ProCurve) wrote:
> >  
> > Instead of sending these 'advertised' attributes in every 
> Access-Request, why doesn't a NAS send a single 
> Access-Request for itself that advertises all the things it 
> needs to advertise once.  This 'self generated' 
> Access-Request could occur at start-up time or anytime 
> configuration changes such that new things need to be 
> advertised.  Perhaps a new attribute like 'NAS registration' 
> would be required to be included, followed by a list of 
> 'advertised' capabilities that the AS would 'remember' for this NAS.
> 
> A while back, I said "keeping state is a terrible idea" and 
> didn't bother to explicate further.  This is why.  How is the 
> NAS to know when the server has rebooted or otherwise lost 
> state and the NAS needs to refresh it?
> 
> Futhermore, in a proxy situation, which is how most things 
> seem to be run these days, how would the registration get to 
> the servers that need it?
> 
> I'm firmly in the KISS camp, for RADIUS.  Diameter/RADIUS >> 
> 2 and let's keep it that way.
> 
> Barney Wolff
> 

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