Subject: [AAA-WG]: Issue 378: Yet More Base-15 Nits

From: Bernard Aboba <[email-masked]>
Date: Sun, 3 Nov 2002 05:34:23 -0800 (PST)

Issue 378: Yet More Base-15 Nits
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: November 3, 2002
Reference:
Document: Base-15
Comment type: E
Priority: S
Section: Several
Rationale/Explanation of issue:

Since we agreed to adopt a base protocol standard accounting
application Id, the value needs to be included somewhere and
statements about support being implicit within CER/CEA need
to be removed.

Section 1.2.4, Page 14:

Change:

"Since every Diameter implementation MUST support accounting, there is
no need to advertise support for the Base accounting application
within the CER/CEA, since this is implicit. This basic accounting
support is sufficient to handle any application that uses the ACR/ACA
commands defined in this document, as long as no new mandatory AVPs
are added. A mandatory AVP is defined as one which has the "M" bit
set when sent within an accounting command, regardless of whether it
is required or optional within the ABNF for the accounting
application."

To:

"Every Diameter implementation MUST support accounting.
Basic accounting support is sufficient to handle any application
that uses the ACR/ACA commands defined in this document, as long
as no new mandatory AVPs are added. A mandatory AVP is defined as
one which has the "M" bit set when sent within an accounting
command, regardless of whether it is required or optional
within the ABNF for the accounting application."

Section 1.2.4, last paragraph:

"If the base accounting is used without any mandatory AVPs, new
commands or additional mechanisms (e.g. application defined state
machine), then the base protocol defined standard accounting
application Id (section 2.4) MUST be used in ACR/ACA commands."

The base protocol defined standard accounting application id is not
defined in section 2.4, 11.3 or anywhere else for that matter.
Suggest the value 0x00000000 be allocated in Section 11.3:
"IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for
standards-track applications; and 0xff00000000 - 0xfffffffe for
vendor specific applications, on a first-come, first-served basis.
The value 0x00000000 is allocated for use within the Diameter
Base standard accounting application.
Assignment of standards-track application IDs are by Designated
Expert with Specification Required [IANA]."

Section 3, Application-ID

"See Section 11.3 for the possible values that the application-id may
use."

Section 11.3 doesn't contain any such values. Should this section include
values for NASREQ or MIP?

Section 6.8 (Auth-Application-Id AVP) and 6.9 (Acct-Application-ID AVP)

"This AVP SHOULD be placed as close to the Diameter header as possible."

The ABNFs show this AVP 6th in commands as as RAR. Is this "as close as
possible"? Or was this a typo, made unnecessary by including the
application-Id in the header?

Section 3:

" Command-Code values in the range 0xfffffe through 0xffffff are
reserved for experimental use (see Section 11.3). Commands in
this range MUST also include a Vendor-Specific Application ID AVP
(see section 6.11)."

There are only two experimental AVPs now, and this space is to be used
for experimental, not vendor-specific purposes. Please change to:

"Command-Code values 16,777,214 and 16,777,215 (hexidecimal values FFFFFE
-
FFFFFF) are reserved for experimental use (See Section 11.3). "

6.11 Vendor-Specific-Application-Id AVP

"Exactly one of the Auth-Application-Id and
Acct-Application-Id AVPs MAY be present."

Shouldn't this statement have occurred earlier, such as in section 6.9?

---

From: <[email-masked]>
Date: Thu, 28 Nov 2002 15:12:24 +0200

Hi,

> within the ABNF for the accounting application."

OK.

> Expert with Specification Required [IANA]."

OK

> Section 11.3 doesn't contain any such values. Should this 
> section include values for NASREQ or MIP?

OK

> application-Id in the header?

Suggest deleting sentance.
 
> "Command-Code values 16,777,214 and 16,777,215 (hexidecimal values FFFFFE -

OK
 
> Shouldn't this statement have occurred earlier, such as in 

Will add it to 6.9.

John