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

From: <[email-masked]>
Date: Wed, 11 Sep 2002 09:34:47 +0300

Hi Pete & Bernard,

This discussion is opening a can of worms, in my opinion - and I'm
not so sure we're quite ready to fish (just to mix some metaphors!)

The can of worms is this: what is a Diameter application (not just
accounting).  This is a rather simple question, but there are a lot
of issues behind it. I'd like to avoid, at present, issues about
'typing' of Diameter applications, as I think we don't yet have 
enough experience with them.  I am sure we could device a rather
complex system which would inform peers about the different
applications - what type, suggested compatability, etc. - but I am
not entirely sure that this complexity would be useful.

Perhaps some sort of additional application negotiation mechanism could
be added as an extension to the Diameter base, which would help.  However,
I think this could / should be done after we get the Base out the door.

John
> -----Original Message-----
> From: ext Pete McCann [mailto:[email-masked]]
> Sent: 10 September, 2002 17:20
> 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:
>  > It is conceivable that someone could come up
>  > with an accounting application that required a new command, no?
> 
> Maybe we should say that's not an accounting application.  Or rather,
> if it still used ACR/ACA, that part would be accounting, but the new
> command would be an authorization application.
> 
>  > > Would that work?
>  > 
>  > 99% of the time, I think it would. But I'm curious as to 
> how we would
>  > handle the other 1%.
> 
> We currently don't have any formal definition of what an accounting
> application is, so let's just define the problem away by saying that
> *only* ACR/ACA can be a part of an accounting application, and
> anything else is part of the corresponding authorization application.
> If an application doesn't use ACR/ACA, then it's not an accounting
> application.  If it uses ACR/ACA + some other commands, then only the
> ACR/ACA part is the accounting, but the other commands are
> authorization.  You could always advertise support for each one
> separately in CER/CEA, or advertise as an accounting relay to say you
> support all applications' ACR/ACA commands but nothing else.
> 
> -Pete
> 
>

---

From: Pete McCann <[email-masked]>
Date: Wed, 11 Sep 2002 10:08:32 -0500

Hi, John,

I see your point.

Why don't we just delete the paragraph that talks about disk-writing
accounting servers.  I think if we are going to allocate a new
Application ID specifically for base-accounting, that should take care
of most kinds of disk-writing accounting servers: they can advertise
support for base accounting and nothing else.  If someone really felt
the need to invent a new Application ID for an accounting application,
it is probably (hopefully) because some new functionality was added
that would make the application incompatible with those simple
disk-writing servers anyway.

-Pete

---

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

> If someone really felt

That's the rub. If a new accounting application *required* a new command
(not just mandatory AVPs), then there'd be no problem. But it's also
possible to create a new accounting application that uses ACR/ACA, but
just adds some mandatory AVPs.

---

From: Pete McCann <[email-masked]>
Date: Wed, 11 Sep 2002 10:37:32 -0500

> just adds some mandatory AVPs.

Right, it's possible, but as I understand it, not required.  If you
get a new ID, you just won't be able to take advantage of
already-deployed "disk-writing" accounting servers.  That's the
disincentive for people to request the new Application ID.  If someone
does so anyway, it's their own fault, and they get what they deserve.
Or rather, we assume they know what they're doing, and those mandatory
AVPs are so important that they are willing to break backwards
compatibility with those disk-writers.

-Pete

---

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

> If you get a new ID, you just won't be able to take advantage of
> disincentive for people to request the new Application ID.

Unfortunately, application developers don't seem to be perceiving that as
a "disincentive": so far most accounting applications seem to want an
application ID, even if they don't need one (The SIP accounting draft is
one example).

I'd hate for this to imply that only Diameter clients and servers from the
same vendor will be likely to work together, but in practice that's what
might happen.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 11 Sep 2002 12:45:58 -0400

On Wed, Sep 11, 2002 at 10:08:32AM -0500, Pete McCann wrote:
> accounting servers.  

Or more explanation for "disk-writing" accounting would be necessary.
It is difficult to follow the discussion without knowing what the
"disk-writing" accounting actually does and why the "disk-writing"
accounting is important.

Yoshihiro Ohba

> I think if we are going to allocate a new

---

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

> "disk-writing" accounting actually does and why the "disk-writing"

The issue is inclusion of additional AVPs in accounting applications which
do not have to be understood by the backend billing system. Such AVPs
may be required to be included by the accounting application (e.g. mandatory
within the ABNF), but if they don't change the customer bill, then they
don't need to be marked with the "M" bit in an accounting command. This is
true even if the "M" bit would be set on that same AVP within an
authentication command.

Thus, an AVP can have the "M" bit set for authentication, but not have it set for accounting.

---

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

>>disincentive for people to request the new Application ID.

(I haven't read all of this thread yet, so excuse me if this
has already been discussed.)

I'd view the "disk-writing" accounting servers as such that they
can accept any accounting information carried by ACR/ACA regardless
of the application ID. It seems unnecessary to require that the
disk-writing servers only accept those accounting streams where
the client has explicitly required the use of a disk-writing
application.

We can require the right behaviour in the RFC, i.e. overriding
any negative effects unnecessary acct application id tagging
has. I do agree that people will probably want to get themselves
an id even when they don't need one.

Jari