[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: -01 version of Chargeable User Identity



Hi Bernard,

This converstation should apply to the capability exchange being proposed by
another draft.

To respond to your comment. What you suggest could work.  It would be best
though to actually created a new packet for capability exchange. Which has
other issues.  But failing that, would the NAS advertize its capabilities on
the first Access-Request that it sends to a particular realm?  But packets
are not neccesarily routed based on realm.  So there could be some RADIUS
server that would never learn the capabilities.  

But is having a few added bytes in every access accept really that big an
issue?  I would think not.

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Wednesday, October 20, 2004 11:02 AM
> To: Greg Weber
> Cc: radiusext@ops.ietf.org
> Subject: 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?
> 
> --
> 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/>