[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: -01 version of Chargeable User Identity
> On Tue, 19 Oct 2004, Greg Weber wrote:
> > > Overhead is not the issue -- the null CUI attribute will only require 2
> > > octets.
> > The overhead is a potential issue if we are introducing
> > a precedent that might be followed by many attributes
> > in the future. The current suggestion seems to be that
> > _every_ Access-Request contain this advertisement (cf once
> > per NAS which might be more reflective of capability).
> I think your point about overhead is well taken. It's one thing to do
> this in a single case (CUI); it's another thing to set a precedent to be
> replicated again and again, on every RADIUS Access-Request.
> Diameter can avoid this via capabilities negotiation (CER/CEA), but since
> RADIUS has no such feature, what do we do?
> Are you suggesting that the RADIUS server keep state on NAS capabilities,
> by presumably mapping NAS-Identifer/NAS-IP-Address/NAS-IPv6-Address
> attributes to various negotiated capabilities?
Hmm. Less than ideal, but the server does already have some
per-NAS information, e.g. shared-secret, vendor.
I wonder if the Status-Server/Status-Client (12/13) packet codes
mentioned in 2865 were originally intended for exchanging this
type of state information?
> to unsubscribe send a message to email@example.com 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 firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.