[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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/>