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

RE: -01 version of Chargeable User Identity



Hi Barney,
The CUI is an optional attribute -- I don't understand why the old
server should reject the request, as you indicated below.  
BR,
Farid

> -----Original Message-----
> From: Barney Wolff [mailto:barney@databus.com] 
> Sent: Friday, October 15, 2004 9:58 AM
> To: Adrangi, Farid
> Cc: Lothar Reith; Greg Weber; radiusext@ops.ietf.org; 
> bernarda@windows.microsoft.com; david.mariblanca@ericsson.com
> Subject: Re: -01 version of Chargeable User Identity
> 
> 
> On Fri, Oct 15, 2004 at 06:58:46AM -0700, Adrangi, Farid wrote:
> > Thanks for your comments.   RADIUS does not support a 
> generic capability advertisement.  However in this draft,  we 
> can say that the NAS MUST send the CUI attribute with a nul 
> value in the Access-Request, if it supports the attribute.  
> This indicates the home RADIUS server whether or not the NAS 
> support CUI.  Will this address your concern?
> 
> Since an old server that does not support CUI is quite likely 
> to respond
> with Reject to a request with an attribute that it does not 
> understand,
> this is not likely to solve all interoperability problems.
> 
> On the other hand, 
> > 	From: Lothar Reith [mailto:lothar.reith@nortelnetworks.com] 
> > 	I beleive it is not acceptable for the Home-Radius to 
> find out only when receiving the RADIUS Accounting Start 
> Request Message (i.e. after the fact of admitting the user) 
> that he does not have a chargeable-identity for the currently 
> already ongoing usage  - and therefore can not charge for that usage.
> 
> A server that expects to see the accounting requests can 
> always use Class
> to communicate whatever information it likes back to itself.  
> CUI seems
> intended to solve the cases where the servers for access and 
> accounting
> are run by different organizations that cannot manage to negotiate an
> agreed format for Class.  While that is perhaps a real case, it is NOT
> acceptable to impose retroactive requirements on existing devices that
> are now RADIUS compliant.  One would need a much stronger reason to
> disenfranchise the installed base; only a major break could 
> justify it.
> 
> -- 
> Barney Wolff         http://www.databus.com/bwresume.pdf
> I'm available by contract or FT, in the NYC metro area or via 
> the 'Net.
> 

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