[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: -01 version of Chargeable User Identity
On Fri, 15 Oct 2004, Barney Wolff wrote:
> 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.
Do we know that existing servers will behave this way? Perhaps a poll
would be appropriate.
> 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.
Yes, I think that is the issue. If the local ISP felt confident that a
billable identiy was included in the Class attribute, then it wouldn't
need this attribute. On the other hand, if it's a trust issue, what is it
about this attribute that makes the local ISP more confident? After all,
if the home server can't be trusted to put fred@example.com in the Class
attribute, why are they more trusted to put fred@example.com in the new
attribute?
> 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.
In this particular case, my understanding is that the local operator is
unwilling to provide service if the new attribute isn't included, because
it does not feeling confident about payment. So it seems to me that an
Access-Reject might be the desired response.
If an Access-Reject isn't the desired response, I think we have a bigger
problem -- because if the local ISP is willing to live with a Class
attribute, why would this new attribute be needed at all?
--
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/>