Subject: RE: [AAA-WG]: Issue 365: Revised Extensibility Section

From: <[email-masked]>
Date: Thu, 12 Sep 2002 13:42:51 +0300

Hi Bernard,

Your text seems reasonable here also.

John

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: 11 September, 2002 21:46
> To: [email-masked]
> Subject: [AAA-WG]: Issue 365: Revised Extensibility Section
> 
> 
> Issue 365: Revised Extensibility Section
> Submitter: Bernard Aboba
> Submitter email address: [email-masked]
> Date first submitted: September 9, 2002
> Reference:
> Document: BASE-12
> Comment type: T
> Priority: S
> Section: 1.2
> Rationale/Explanation of issue:
> 
> This revision is designed to clarify the issue of
> extensibility to make it clear that addition of
> non-mandatory AVPs does not require definition of a
> new application ID.
> 
> Replace section 1.2 with the following:
> 
> "1.2 Approach to Extensibility
> 
> The Diameter protocol is designed to be extensible, using
> several mechanisms, including:
> 
> - Defining new AVP values.
> - Creating new AVPs
> - Creating new authentication/authorization applications
> - Creating new accounting applications
> - Application authentication procedures
> 
> Reuse of existing AVP values, AVPs, applications and command codes
> are strongly recommended. Reuse simplifies standardization and
> implementation and avoids potential interoperability issues.
> 
> 1.2.1 Defining New AVP Values
> 
> New applications should attempt to reuse AVPs defined in existing
> applications when possible, as opposed to creating new AVPs. For AVPs
> of type Enumerated an application may require a new
> value to communicate some service-specific information.
> 
> In order to allocate a new AVP value, a request MUST be
> sent to IANA [IANA], along with an explanation of the new
> AVP value. IANA considerations for Diameter are discussed
> in Section 11.
> 
> 1.2.2 Creating New AVPs
> 
> When no existing AVP can be used, a new AVP should
> be created. The new AVP being defined MUST use one of the
> data types listed in section 4.3.
> 
> In the event that a logical grouping of AVPs is necessary, and
> multiple "groups" are possible in a given command, it is
> recommended that a Grouped AVP be used (see Section 4.5).
> 
> In order to create a new AVP, a request MUST be sent to IANA,
> with a specification for the AVP. The request MUST include
> the commands that would make use of the AVP.
> 
> 1.2.3 Creating New Authentication Applications
> 
> Every Diameter application specification MUST have an IANA assigned
> Application Identifier (see section 2.4) or a vendor specific
> Application Identifier.
> 
> Should a new Diameter usage scenario find itself unable to 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:
> 
> - Adding new AVPs to the command, which have the "M" bit set.
> 
> - 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).
> 
> - Adding support for an authentication method requiring definition of
> new AVPs for use with the application. Since a new EAP authentication
> method can be supported within Diameter without requiring new AVPs,
> addition of EAP methods does not require the creation of a new
> authentication
> application.
> 
> Creation of a new application should be viewed as a last resort.
> An implementation MAY add arbitrary non-mandatory AVPs to any
> command defined in an application, including vendor-specific 
> AVPs without
> needing to define a new application. Please refer to section 
> 11.1.1 for
> details.
> 
> In order to justify allocation of a new application 
> identifier, Diameter
> applications MUST define one Command Code, or add new 
> mandatory AVPs to
> the ABNF.
> 
> The expected AVPs MUST be defined in an ABNF [ABNF] grammar 
> (see section
> 3.2). If the Diameter application has accounting requirements, it
> MUST also specify the AVPs that are to be present in the Diameter
> Accounting messages (see section 9.3). However, just because a new
> authentication application id is required, does not imply that a new
> accounting application id is required.
> 
> When possible, a new Diameter application SHOULD reuse
> existing Diameter AVPs, in order to avoid defining
> multiple AVPs that carry similar information.
> 
> 1.2.4 Creating New Accounting Applications
> 
> There are services that only require Diameter accounting.
> Such services need to define the AVPs carried in the ACR/ACA messages,
> but do not need to define new command codes. An implementation MAY add
> arbitrary non-mandatory AVPs (e.g. AVPs with the "M" bit not 
> set) to any
> command defined in an application, including vendor-specific
> AVPs, without needing to define a new accounting application. Please
> refer to section 11.1.1 for details.
> 
> Application Identifiers are still required for Diameter capability
> exchange. Every accounting application MUST have either an IANA
> allocated Application Identifier, or a vendor specific Application
> Identifier.
> 
> 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.
> 
> The creation of a new accounting application should be viewed as a
> last resort and MUST NOT be used unless a new command is defined with
> the application, or new mandatory AVPs are added to the ABNF.
> 
> Within an accounting command, setting the "M" bit implies that
> the backend billing server MUST understand the AVP in order to compute
> a correct bill. If the AVP is not relevant to the billing 
> process, when
> the AVP is included within an accounting command, it MUST NOT
> have the "M" bit set, even if the "M" bit is set when the same AVP is
> used within other Diameter commands.
> 
> When possible, a new Diameter accounting application SHOULD attempt
> to reuse existing AVPs, in order to to avoid defining multiple AVPs
> that carry similar information.
> 
> Every Diameter accounting application specification MUST have an IANA
> assigned Application Identifier (see section 2.4) or a vendor specific
> Application Identifier."
> 
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 12 Sep 2002 04:57:06 -0700 (PDT)

To accomodate comments, I've made some slight changes, which will be
reflected in the text up on the website.