Re: AW: -01 version of Chargeable User Identity

[Bernard Aboba <aboba@internaut.com>]

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

But in a roaming situation, it is the problem of the local realm that
provided the service, not the "home server", no?  If it is purely the
problem of the "home server" then the Class attribute can be used by
the home server and there is no need for CUI, as you point out.

However, the argument was made that if the "local realm" needs assurance,
it can't get this from Class, since that this attribute is to be treated
as opaque data by RADIUS clients.  So I think the argument for CUI is one
that originates from the local realm, not the home server.

Does this make sense??

> I wholeheartedly agree. And I also think that there's a better solution
> to help administrators of accounting servers to guarantee that they
> don't process and bill their users for unwanted records.

Yes, there is an existing solution to this problem -- the Class attribute,
as you point out.

> I feel this is a better solution to tying accounting to authentication
> than eg. requiring Acct-Session-Id in access requests as some operators
> stretch RFC2869 to, or CUI.  I know, it's not exactly the same thing,
> but as far as I understand CUI's purpose, CUI was aimed at solving a
> similar problem.

I guess I understood CUI's purpose differently.  But that's not a good
sign, since a clearly stated problem is a pre-requisite for a solution to
that problem.



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