Subject: [AAA-WG]: Issue 311:Acct-Application-Id and Vendor-Specific-Application-Id in ACR

From: <[email-masked]>
Date: Thu, 28 Mar 2002 15:26:03 +0200

Hi all,

Sometimes, reading through these issues gives me a headache .... but
let me see if I have got this one right.  The changes are as follows:

Change the ABNF in 9.7.1 Accounting-Request

from:

	<ACR> ::= < Diameter Header: 271, REQ, PXY >
	< Session-Id >
	{...}
	{ Acct-Application-Id }
	[...]

To:

	<ACR> ::= < Diameter Header: 271, REQ, PXY >
	< Session-Id >
	{ ... }
	[ Acct-Application-Id ]
	[ ... ]

and replace the last 2 paragraphs in section 2.3.3 with:

Accounting is somewhat different from Authentication in that in many cases
the accounting server only writes the AVPs to disk, and therefore doesn't
need to understand them. As a result, one can send vendor-specific AVPs to
an accounting server without the server needing to "support" them. 

Should a new application require Diameter support, but it cannot fit
within an existing application without requiring major changes to the
specification, it may be desirable to create a new Diameter
application. Major changes to an application include:
- Requiring a whole different set of mandatory AVPs to a command
- Requiring a command that has a different number of round trips
to satisfy a request (e.g. application foo has a command that
requires one round trip, but new application bar has a command
that requires two round trips to complete).
- The accounting method is drastically different from any existing application, 
and the accounting server needs to understand the information carried within 
the AVPs defined in the application.

Note that the creation of a new application should be viewed as a
last resort.

New Diameter applications MUST define at least one Command Code, the
expected AVPs in an ABNF [ABNF] grammar (see section 3.2), and MAY
also define new AVPs. 

When possible, a new Diameter application SHOULD attempt to re-use
any existing Diameter AVP, in order to reduce the possibility of
having multiple AVPs that carry similar information.

Every Diameter application specification MUST have an IANA assigned
Application Identifier (see section 2.4).

Does this work?
John

---

From: Jari Arkko <[email-masked]>
Date: Thu, 28 Mar 2002 21:44:48 +0200

I have a somewhat modified proposal. Removing the acct-application-id
is a nice idea, but unfortunately it runs into trouble with the capability
discovery process and in particular with the contents of section 6.1. So,
I'm proposing we keep the acct application ids, but allow for vendor specific
values as well. This allows also at the same time that the accounting servers
will be able to know the application type immediately, without trying to infer
it from the AVPs.

My proposed solution contains the following changes:

1) Section 2.3.3 should be renumbered in base to 1.3.3. (!)

2) References to section 2.5 throughout the base are wrong, and should
    probably point to 2.4

3) 2.5 Connections vs. Sessions is missing from the contents table.
    (It seems like going through the whole contents table as well
    as all references would make sense.)

4) Relay app id (0xffffffff) can be used also by "dumb" file writing accounting
    servers. Add text to just before "while" in 2.4: ", accounting servers capable
    of storing any records MUST advertise the Relay Application Identifier for
    accounting".

5) Modify ANF for ACR as follows:

    <ACR> ::= < Diameter Header: 271, REQ, PXY >
              < Session-Id >
              { ... }
	     [ Acct-Application-Id ]
              [ Vendor-Specific-Application-Id ]
	     [ ... ]

    And add text: "One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs
    MUST be present. If the Vendor-Specific-Application-Id grouped AVP is present,
    it must have an Acct-Application-Id inside."

6) Similar modifications for ACA.

7) Don't touch 2.3.3 (i.e. 1.2.3), it is for authentication only.

8) Add replace the text in  1.2.4 with

    Services that have an Application Identifier MUST use the same identifier
    also to identify the service when Diameter accounting is used.

   There are services that only require the use of Diameter accounting.
   Such services need to define the service specific AVPs that must be
   carried in the Accounting-Request/Answer messages, but do not need to
   define command codes. Application Identifiers are, however, still required
   for accounting due to the Diameter capability discovery process.
   Every accounting application MUST have either an IANA allocated Application
   Identifier, or a vendor specific Application Identifier.       

   When possible, a new Diameter accounting application SHOULD attempt
   to re-use any existing Diameter AVP, in order to reduce the
   possibility of having multiple AVPs that carry similar information.

9) Modify AVP occurrence tables appropriately.

10) 6.1.1 add Vendor-Specific-Application-Id to the list in the last bullet.

11) Add a new paragraph after the first paragraph of 11.3: "Both Application-Id
    and Acct-Application-Id AVPs use the same Application Identifier space."

12) Also add to 11 that not just zero but also 0xffffffff are reserved values.