Re: AW: -01 version of Chargeable User Identity

[Barney Wolff <barney@databus.com>]

On Wed, Oct 20, 2004 at 07:20:40AM -0700, Bernard Aboba wrote:
> 
> The other issue is whether the NAS supports CUI, and if so, what it will
> do on receipt of an Access-Accept where CUI is not present.  My
> understanding is that CUI will typically be required by the NAS, at least
> for sessions where privacy is invoked.  Without CUI, there may be no way
> for the NAS to know that has a valid billable identity prior to providing
> service.  So it seems that the NAS would need to treat an Access-Accept
> without CUI like an Access-Reject.  There is some precedent for this in
> RFC 2865 -- I believe that the NAS needs to treat an Access-Accept with an
> unimplemented Service-Type this way.

I think this is not a real issue, at least for the NAS.  After all, the
NAS (perhaps with proxy help) managed to get the Access-Request to a
server that was willing to -Accept.  The bill must go to the organization
responsible for that server.  Whether the server can then bill some
individual/organization is the server's problem, not the NAS's.

Surely as a matter of ordinary business practice, a server cannot say
"provide service" but then refuse to accept billing for that service.

Maybe I still don't understand the model this attribute is designed for.
Are we really laboring to repair fatal defects in a model where the
Access and Accounting are handled by different organizations who cannot
come to agreement with each other on Class, and where bills somehow flow
by a different path than Access-Requests?  Why should we?

I have philosophical problems with the whole class of such issues.  We
already have a super-heavyweight AAA protocol in Diameter.  RADIUS has
always been the bantamweight.  Attempts to bulk it up will ultimately
fail, because its legs are still toothpicks.

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