Subject: RE: [AAA-WG]: Issue 360: Accounting standalone

From: <[email-masked]>
Date: Wed, 11 Sep 2002 19:37:03 +0300

OK, then it seems we need two accounting application Id.

However,
A disk-writing accounting server is probably just storing AVPs to the
disk, later on it will send the AVPs to a postprocessing system (e.g.
billing system)that may understand this information to create the bill.
This does not mean tha such accounting server can handle any application
using only ACR/ACA.

For example, you might have prepaid accounting application that make only 
use of ACR/ACA. When the server receive ACR would need to reserve money from
some account, calculate the quota and send back the calculated quota to the client.
This is "any application using only ACR/ACA", but clearly a disk-writing
accounting server cannot handle this application.

Perhaps it is still better to delete the "disk-writing" text as originally
proposed by Pete.

Br
Marco

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: 11. September 2002 18:00
> To: Stura Marco (NET/Helsinki)
> Cc: Loughney John (NRC/Helsinki); [email-masked];
> [email-masked]
> Subject: RE: [AAA-WG]: Issue 360: Accounting standalone
> 
> 
> > it sounds good proposal to allocate this kind of accounting 
> application Id.
> > But why would you need two? one that indicate "I support 
> Diameter Base
> > Accounting and any application using only ACR/ACA" is not enough?
> 
> Let's look at three cases.
> 
> Suppose Accounting server advertises "any application
> using only ACR/ACA". Accounting client advertises their 
> application ID,
> which the accounting server might not understand, as well as "any
> application using only ACR/ACA". Negotiation succeeds.
> 
> Accounting client now sends an ACR command with their application ID,
> perhaps some new mandatory AVPs. Accounting server will only 
> look at the
> ACR, ignore the application ID (since can handle any 
> application ID with
> ACR), and responds with an ACA with that application ID.
> 
> Seems to work fine.
> 
> Now what if the accounting server doesn't support "any app 
> with ACR/ACA"?
> 
> Accounting server advertises no application ID (implying that it does
> basic accounting only). Accounting client advertises the new 
> application
> ID, plus "any application using only ACR/ACA". Negotiation fails.
> 
> The last case is if both client and server only do basic 
> accounting. Both
> will advertise no application ID in CER/CEA, and negotiation 
> will succeed.
> But then the issue is what application goes in the header, along with
> ACR/ACA.
> 
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Sep 2002 09:17:12 -0700 (PDT)

> This does not mean tha such accounting server can handle any application

That's a fair statement. I think you are saying that in an accounting
command, the "M" bit in an AVP means "this AVP *must* be understood by the
backend billing system", not necessarily "this AVP *must* be understood by
the accounting server."

Note that this is *not* the same thing as saying that the AVP is required
by the ABNF in the accounting application definition. It is possible for
the ABNF to require inclusion of an AVP without the "M" bit set.

The implication is that AVPs marked with the "M" bit for authentication
would not necessarily have this bit marked for use within an accounting
command. For example, it might be important that the NAS implement a
special filtering AVP, (set "M" in the authentication), but that might be
irrelevant for accounting purposes (NAS doesn't set "M" bit in the ACR).

If we can guarantee that the "M" bit is set this way in accounting AVPs,
I'm not clear why you'd need a new accounting application unless
a new command is being defined. You just let the Accounting server
advertise the standard accounting command; if you send it mandatory AVPs
it doesn't understand, it will send you an error message.

> Perhaps it is still better to delete the "disk-writing" text as originally

This could work, provided that the above issues with the "M" bit and
accounting application id allocation are worked through.