Subject: RE: Comments on base-12 (was RE: [AAA-WG]: Diameter Base update)

From: <[email-masked]>
Date: Tue, 10 Sep 2002 11:35:30 +0300

Hi,

the Pete's proposal seems to limit the accounting application to use
ACR/ACA only. A new accoutnig application can only define AVPs.

I would underline that the base accounting does not satify all the
possible accounting requirements that may pop-up in the future, actually
it does even not satify some of the existing requirements e.g prepaid
requirements.
Certain prepaid application used in multiservice environment may need
to define also new command and mechanisms.

Well, the Pete's proposal seems to place a huge limitation to the use
of Diameter as accounting protocol. With such limitation I wonder
whether Diameter would be used for accounting at all...

Br
Marco

> -----Original Message-----
> From: ext Pete McCann [mailto:[email-masked]]
> Sent: 10. September 2002 0:59
> To: Bernard Aboba
> Cc: Loughney John (NRC/Helsinki); [email-masked]
> Subject: RE: Comments on base-12 (was RE: [AAA-WG]: Diameter Base
> update)
> 
> 
> 
> Bernard Aboba writes:
>  > Originally, a new application-ID required a new command, 
> and therefore
>  > there was no reason to expect that a "disk writing" 
> accounting server
>  > could handle anything other than the standard Accounting 
> application-ID.
>  > In some ways this original formulation is very clean -- 
> the accounting
>  > server just advertises the standard accounting 
> application, and there is
>  > no reason to get another application-ID unless you're 
> defining a new
>  > command. In this case, deleting the paragraph has no ill 
> effects, and I'd
>  > agree with you.
> 
> Accounting is also "lumped in" with the various authorization
> applications now, so there are no Application IDs that apply only to
> accounting or only to authorization.  Also, the vendor-specific
> application IDs only come in one flavor.
> 
>  > However, now my understanding is that we are allowing 
> allocation of new
>  > application IDs without a new command. This has the 
> troublesome effect of
>  > breaking interoperability as a result of trivial changes 
> (e.g. adding a
>  > vendor-specific AVP).
> 
>  > Although we have put language in the draft discouraging 
> allocation of new
>  > application IDs without good reason, in practice, this has 
> had no effect
>  > -- virtually every accounting usage in Diameter is now 
> requesting an
>  > application ID, whether it is necessary or not.
> 
>  > So it seems to me that we have a choice of either putting 
> some teeth into
>  > the allocation policy (e.g. going with "expert review" 
> before allocation
>  > of an application ID) or putting bits into the 
> application-ID to allow the
>  > accounting server to distinguish the new AVP case from the 
> new command
>  > case.
> 
>  > If we don't do either of these things, the likely outcome 
> is that Diameter
>  > will end up being less extensible than RADIUS.
> 
> I would like to keep FCFS allocation policy if at all possible.
> 
> I think the best way to add the bits of which you speak would be to
> differentiate more strongly between the Accounting and Authorization
> Application-ID AVPs.  In other words, Accounting applications must be
> "pure" in the sense that they only use ACR/ACA.  It may be the case
> that the same Application ID appears inside both Authorization and
> Accounting Application-ID AVPs during CER/CEA, but this really means
> that a server supports two different aspects of a protocol: 1) the
> authorization state machine and any associated machinery, and 2) the
> ACR/ACA commands and all of the mandatory AVPs associated with the
> application.  This way, we could define the "Relay" Application ID,
> when it appears inside an Accounting Application-ID AVP, to mean that
> the server supports ACR/ACA for any application.  Also, we should
> create 2 AVPs to hold vendor-specific application IDs: one for
> authorization, the other for accounting.  The accounting applications,
> even when vendor-specific, are not allowed to use any commands other
> than ACR/ACA.  A "disk-writing" accounting server could then
> interoperate with any accounting application, even if it were
> negotiating with a proxy that didn't know the semantics of the
> application, because accounting applications are guaranteed to be
> "pure" (only use ACR/ACA) throughout the system.
> 
> Would that work?
> 
> -Pete
> 
>

---

From: Pete McCann <[email-masked]>
Date: Tue, 10 Sep 2002 09:58:09 -0500

Hi, Marco,

We could always just delete that paragraph about "disk-writing"
accounting servers, but I was trying to find a way to keep the ability
to do that.  It seems that to do that, we need some way to indicate
support for ACR/ACA (and nothing else) for any application.  

I certainly don't want to limit the scope of future accounting
protocols; I am just playing with definitions of some terms.  So if a
new protocol used ACR/ACA plus some other commands for doing prepaid,
then those new commands would be considered part of the authorization
application.  We certainly wouldn't expect a "disk-writing" accounting
server to handle those additional commands and state machines.
However, our "disk-writing" accounting server could advertise support
for the ACR/ACAs which could be routed to it and stored on disk, in
some particular deployment.

Of course, if those ACRs/ACAs were intended to trigger certain actions
of the bigger application, you would need the interfaces to do that.
There's probably no way for a simple disk-writing accounting server to
help with that, so my proposal might break such applications.  If it
is important to support these, then I tend to think we should just
delete the paragraph and move on.

What I think Benard proposed originally was to add some "typefulness"
to the Application IDs so that you could look at any given application
ID and see if it was:

   1) "Vanilla" accounting, only used ACR/ACA
   2) "Enhanced" accounting, with some additional commands or
       interactions that would make disk-writing accounting servers
       inappropriate

I guess we could steal the least-order bit from the application ID
for this purpose - you could say that even-numbered accounting IDs are
"vanilla" and odd-numbered accounting IDs are "enhanced".  However,
this seems to require a smidge of expert review at assignment time,
rather than FCFS.  We could modify the text about advertising "Relay"
accounting services to say it means you support any "vanilla"
accounting application.  We would need to understand how to advertise
support for true Relay accounting servers, perhaps using the
least-order bit of the "Relay" identifier.

What do people want to do?

-Pete