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

From: <[email-masked]>
Date: Wed, 11 Sep 2002 20:50:31 +0300

Hi Bernard,

I think you fully missunderstood my point, I don't know where in my
mail you read the "fair statement" you speak about.
I'm not discussing AVP with M bit set at all, I'm arguing that 
disk-writing accounting server cannot handle "any accounting
application that only use ACR/ACA" as they probably just store
say accounting information, may be it's more clear, that may be used
by other systems to create the bill.

There was also a clear example that you didn't comment at all

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

This is one good reason to remove the disk-writing text.

Moreover, Here I was refferring to AVP required in the accounting application
definition that trigger some specific server action necessary to support
the requested service (one example is prepaid). 
How would you differentiate this kind of application if not with an accounting 
application id?

Br
Marco

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: 11. September 2002 19:17
> To: Stura Marco (NET/Helsinki)
> Cc: Loughney John (NRC/Helsinki); [email-masked];
> [email-masked]
> Subject: RE: [AAA-WG]: Issue 360: Accounting standalone
> 
> 
> > 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.
> 
> 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
> > proposed by Pete.
> 
> This could work, provided that the above issues with the "M" bit and
> accounting application id allocation are worked through.
> 
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Sep 2002 10:57:43 -0700 (PDT)

> mail you read the "fair statement" you speak about.

I agreed with you that a disk-writing accounting server couldn't handle
your prepaid accounting application.

> I'm arguing that

I agree with that.

> This is one good reason to remove the disk-writing text.

I agree with that, too.

> Moreover, Here I was referring to AVP required in the accounting application

There are two cases:

1. If the application not only requires new AVPs to be present in the
application (e.g. ABNF mandates them), but also requires the billing
server to understand them (e.g. new AVPs have "M" bit set in accounting
messages), then a new application ID is required, even if no new
commands are used, only ACR/ACA.

2. However, if the application requires new AVPs to be present (ABNF
mandatory), but does not require the billing server to understand them
(e.g. new AVPs don't have "M" bit set) and there are no new commands, then
I'd argue that a new application ID is not required and MUST NOT be used.

If you buy this argument, then I think the indicated fix is:

a. Delete the "disk writing" text.

b. Change the "Extensions" text to indicate that a new  accounting
application ID is needed only when there are new commands, OR when new
AVPs defined in the application ABNF have the "M" bit set. If there are no
new commands, and new AVPs are non-mandatory, a new application ID MUST
NOT be used.

c. Add text to require that in accounting
commands, the "M" bit is only set when a backend billing server MUST
support the AVP in order to issue a correct bill. If the backend billing
server can ignore the AVP in computing the bill, then the  AVP MUST NOT
have the "M" bit set within an accounting message, even if the "M" bit
was set on that AVP within an authentication message.

d. Add a "standard accounting application" ID so that accounting can be
used by itself within Diameter.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 11 Sep 2002 15:32:14 -0400

> I'd argue that a new application ID is not required and MUST NOT be used.

But does case 2) mean that it requires an additional ABNF in addition
to the ABNF for base ACR/ACA (and thus additional command dictionary
entry would be necessary to parse the new AVP)?  If so, how the
additional command dictionary entry can be distinguished from the
command dictionary entry for the base ACR/ACA without using a new
application id?

Yoshihiro Ohba

---

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

> command dictionary entry for the base ACR/ACA without using a new

It should be possible to add new AVPs to the dictionary without requiring
the application id to change. That can be done in RADIUS today. If the
AVPs are non-mandatory there is no reason to allocate a new application ID.

A new application id would only be required if mandatory AVPs are added.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 12 Sep 2002 14:36:07 +0300

I think the most serious issue we have in the current specifications
is what Marco brought up, i.e., that credit control -like applications
are not compatible with the disk-writing approach. For this reason, it
makes sense to make it the choice of the application specification
whether or not fallback to "disk-writing" is allowed or not. This is
essentially what deleting the disk-writing text and adding a base
accounting application id accomplishes.

However, I'm pretty uncertain whether the "M" bit approach is the
right one. Remember that billing is a process inherently guided by
a policy. How would we as accounting-application-writers know whether
a particular field from the SIP protocol is or is not going to be
necessary for printing the bill? The answer is that we do not, and
any information specified in the application standard *could* be
used. Furthermore, the information about whether the AVPs are
mandatory in a specific business case is something that only the
home network knows. Therefore, it is hard for us to do anything
else than to declare most accounting AVPs mandatory, and then
have the client set the bits. According to the rules below
this would lead to the situation where the basic accounting
application is used by almost no one.

This is undesirable since in many cases the basic accounting
application would in fact be sufficient as long as the
record reached the right server. On the other hand, the combination
of the home domain and the accounting application Id would
act as a convenient routing mechanisms to get to the dial-in/wlan/3g
department accounting servers.

In conclusion my main concern is that there'll be new applications
and we'll be under the mercy of the negotiation process. And I
need to get vendor X's server to get it to work with their client,
if they chose to invent a new application ID -- even if *I* think
I can handle it with my disk-writing basic accounting mechanism.

But perhaps there's an easy fix to this. We could require that
all implementations of DIAMETER basic accounting must be _configurable_
to advertise a specific accounting application support.

This would mean that we lose the automatic fallback to disk-writing
server (but for a good reason noted by Marco). Instead, we have
a human-controlled process.

Jari