Re: -01 version of Chargeable User Identity

[Greg Weber <gdweber@cisco.com>]

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

Greg

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