RE: backwards compatible introduction of NEW attribute such as CUI

["Adrangi, Farid" <farid.adrangi@intel.com>]

Interesting discussion!   Going forward, we agree that we should avoid
any solution that makes RADIUS more stateful.  That said, there seems to
be three viable options for handling backward compatibility in CUI
draft:

1) NAS always advertises CUI support

Then, we can simply replace the first sentence of the second paragraph
in section 2.1 with the following:

"
If the NAS supports CUI, it MUST include the CUI attribute with a null
character for its data field in the Access-Request message to indicate
its support for this attribute to the home RADIUS server. 
"

Note: BTW,
http://www.ietf.org/internet-drafts/draft-adrangi-radius-attributes-exte
nsion-01.txt, section 2.2, introduces a solution for general capability
advertisement support for RADIUS.    

2) NAS may advertise CUI support (optional - implementation dependent)

The current text (i.e., second paragraph in section 2.1) in version -03
should suffice.

3) NAS never advertises CUI support 

Then, we can simply remove the the first sentence of the second
paragraph in section 2.1. 


Please also note that in options (2) and (3), the home RADIUS server may
have some other reliable methods to determine the NAS support for CUI.
But such methods or mechanisms are out of scope.

I'd prefer (2) or (3).  Your thoughts?

Farid



   




> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Congdon, 
> Paul T (ProCurve)
> Sent: Tuesday, December 14, 2004 11:24 AM
> To: Barney Wolff
> Cc: Lothar Reith; Nelson, David; radiusext@ops.ietf.org
> Subject: RE: backwards compatible introduction of NEW 
> attribute such as CUI
> 
> 
> 
> 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/>
> 

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