Subject: [AAA-WG]: Base Updated section 1.2

From: <[email-masked]>
Date: Thu, 13 Jun 2002 10:30:17 +0300

Hi all,

In order to resolve the current discussion, I have updated section 1.2.  Most 
all of the information exists already in the Diameter document, in other sections,
I have simply condensed it into the introduction for clarity's sake.

Specific recomendation on text is welcome. 

John

1.2  Approach to Extensibility

   The Diameter protocol is designed to be extensible. The extensibility 
   includes:

      - 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
   is strongly recommended.  Reuse simplifies standardization effort,
   implentation effort and avoids potential interoperability issues.

1.2.1  Standardized Extensions Versus Vendor-Specific Extensions

   Diameter can be extended by standards track documents in the IETF.
   The benefit of this is that the extensions become Internet standards,
   allowing for wider possible deployment and higher assurance of 
   interoperability.  It is strongly recommended that extensions to
   Diameter be made by standards-track RFCs.

   Vendor-specific extensions are allowed, and MUST be registered through
   IANA (see section 11.2).  However, vendor-specific extensions MUST NOT
   harm interoperability of standards-based Diameter implementations.

   Vendor-specific commands MUST NOT be used where an existing command plus a
   vendor-specific AVPs would the same objective. If this basic precept is 
   followed, then most interoperability problems are solved. Vendor-specific 
   commands MUST NOT be sent in response to standard commands.  Unsolicited VSCs 
   sent from a AAA server to a NAS are to be treated as non-mandatory. All 
   vendor-specific Diameter commands require Informational RFCs documenting 
   the command unless for Private Use as described in Section 11.2.1.

   As a general rule, any errors involving Vendor-specific AVP marked with 
   the 'M' bit are considered the fault of the side setting the 'M' bit (see
   Section 4.1).

1.2.2  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, it is possible the application requires 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], with a detailed explanation of the value and document on the 
   value.

1.2.3  Creating New AVPs

   When no existing AVP can be used appropriately to communicate some
   service-specific information, a new AVP should be created. The new
   AVP being defined MUST follow one of the 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 highly
   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
   detailed explanation of the AVP, its type and possible values.
   Furthermore, the request MUST include the commands that would make
   use of the AVP.

1.2.4  Creating New Authentication Applications

   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 method used to authenticate the user is drastically
        different from any existing application, and the authentication
        information cannot be 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. If the Diameter application has any accounting
   requirements, it MUST also specify the AVPs that are to be present in
   the Diameter Accounting messages (see section 9.3).

   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).

1.2.5  Creating New Accounting Applications

   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.

   Note that the creation of a new application should be viewed as a
   last resort and should be used only when Vendor-Specific AVPs are
   insufficient. In most cases, reusing an existing Application ID with
   Vendor-Specific AVPs should work. For example, many accounting
   servers are set up to write AVPs to disk, so they can handle even
   mandatory vendor-specific AVPs that they don't understand.

   This is why "disk writing" accounting servers should advertise
   themselves as "Relays" that can handle any Application ID, including
   Vendor-Specific.

   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.

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

1.2.6  Application Authentication Procedures

   When possible, applications SHOULD be designed such that new
   authentication methods MAY be added without requiring changes to the
   application. This MAY require that new AVP values be assigned to
   represent the new authentication transform, or any other scheme that
   produces similar results. When possible, authentication frameworks,
   such as Extensible Authentication Protocol [EAP], SHOULD be used.

---

From: Erik Guttman <[email-masked]>
Date: Thu, 13 Jun 2002 01:34:13 -0700 (PDT)

John,

> Specific recomendation on text is welcome. 

Here goes.

>    implentation effort and avoids potential interoperability issues.

The following text made it possible to get RFC 3224, Vendor Extensions
to SLP, through.  There were concerns that the document could be read
as *encouraging* vendor extension.

From Abstract:
   While proprietary protocol
   extensions are not encouraged by IETF standards, it is important that
   they not hinder interoperability of compliant implementations when
   they are undertaken.

From Introduction:
   Vendor extensions to standard protocols come at a cost.

      -  Vendor extensions occur without review from the community.
         They may not make good engineering sense in the context of the
         protocol they extend, and the engineers responsible may
         discover this too late.

      -  Vendor extensions preclude interoperation with compliant but
         non-extended implementations.  There is a real danger of
         incompatibility if different implementations support different
         feature sets.

      -  By extending SLPv2 privately, ubiquitous automatic
         configuration is impossible, which is the primary benefit of a
         standard service discovery framework.

By spelling out the disadvantages to readers, it is possible to put
vendor extensibility in an appropriate light.  This doesn't solve the
IESG's issues, but it ameliorates them.

>    [IANA], with a detailed explanation of the value and document on the 

This technique puts an onerous burden on IANA.  Current practice is for
the IESG to appoint a 'designated expert' on Diameter extensibility.  
All requests for IANA registration of extensions get funneled through
him or her.  The designated expert must review the clarity and 
completeness of the specification, and if needed, seek additional 
technical review from the community.  If there is a dispute, one can
use the standard IETF appeals process to challenge the authority of
the Designated Expert.

The rules for this are set forth in RFC 2434, under the Designated
Expert policy.  

Example text using RFC 2434 policy is in RFC 2608 (SLPv2):

   New SLP Extensions with types in the range 2-65535 may be registered
   following review by a Designated Expert.

This means the process is as follows:

a) a group wants to register an extension.  They prepare a specification
   and post it publicly for download.
b) the group contacts the designated expert.  This can be done by
   specifying a well known email alias ([email-masked])
   that the designated expert monitors
c) the designated expert reviews the doc on a best effort basis and
   works with the authors and community to ensure the doc is 
   reasonably clear and complete, not redundent and not harmful.
d) once the doc is in reasonable shape, the Designated Expert passes
   a version of the text to add to an IANA registry page.  For
   example, "Please add CODE=0x9234  NAME=blahblah  AUTHOR CONTACT=a@b
   SPECIFICATION=http://example.org/spec.txt to AVP extension table of
   the Diameter Extensions page."

This process can be very swift for simple extensions.  If there is an
active community of implementors and users, as there will be for
Diameter, one can vet new suggestions on a mailing list, with the 
authority and discretion still being in the hands of the Designated
Expert.
  
>    Furthermore, the request MUST include the commands that would make

Please see RFC 3080, The Blocks Extensible Exchange Protocol Core, 
Section 5, for an excellent set of sections for describing process 
for defining new extensions.  What we should have in the 1.2 subsections
is a set of templates to fill in - to send to the designated expert.
These templates could be filed with IANA as part of registration, 
after the kinks get worked out of them.  The templates are not a 
replacement for a spec. 

Example of one:

RFC 3080, 5.1 Profile Registration Template

   When a profile is registered, the following information is supplied:

   Profile Identification: specify a URI [10] that authoritatively
      identifies this profile.

   Message Exchanged during Channel Creation: specify the datatypes that
      may be exchanged during channel creation.

   Messages starting one-to-one exchanges: specify the datatypes that
      may be present when an exchange starts.

   Messages in positive replies: specify the datatypes that may be
      present in a positive reply.

   Messages in negative replies: specify the datatypes that may be
      present in a negative reply.

   Messages in one-to-many exchanges: specify the datatypes that may be
      present in a one-to-many exchange.

   Message Syntax: specify the syntax of the datatypes exchanged by the
      profile.

   Message Semantics: specify the semantics of the datatypes exchanged
      by the profile.

   Contact Information: specify the postal and electronic contact
      information for the author of the profile.

The template for the section 1.2.3 could be:

   When a new AVP is registered, the following information is supplied:

   What Application is the AVP intended to be used in?

   What Commands make use of the AVP?

   What is the AVP's type?

   What are its possible values and how can one interpret these values?

   Are there any restrictions on use of the AVP?  For example are there
   any additional AVPs which are needed to intepret the AVP correctly?
   Are there any AVPs which cannot appear in the same command as this
   AVP (or it won't make sense, etc)?

   Does this AVP change the interpretation of any other AVP or command?
   What are the side effects of including this AVP in a command?

   When is appropriate to set the Mandatory 'M' bit in the AVP?

   How is the AVP used?

   Where is the specification for the AVP?

   What is the contact information for further questions.  Please
   include postal and electronic contact information for the author
   of the AVP extension.

Erik

---

From: Erik Guttman <[email-masked]>
Date: Thu, 13 Jun 2002 01:56:51 -0700 (PDT)

John,

One more suggestion - a propos to current discussion.  If we add an
additional question to the proposed 'AVP Registration Template' we
put the burden of proof of uniqueness and need for the AVP into the
requester's hands.

>    When a new AVP is registered, the following information is supplied:

   Why are no existing standard AVPs suitable?  If an existing AVP or
   combination of existing AVPs suffice, this AVP registration will be
   rejected.

Erik

---

From: Pete McCann <[email-masked]>
Date: Thu, 13 Jun 2002 09:55:15 -0500

Hi,

I think some of the text below regarding Application IDs is
inconsistent.  Let me point it out, and then ask a question which I
think will help clear up some of the confusion I see in the recent
discussions.

[email-masked] writes:
...
 > 1.2.4  Creating New Authentication Applications
...
 > 1.2.5  Creating New Accounting Applications
...
 >    allocated Application Identifier, or a vendor specific Application
...
 >    assigned Application Identifier (see section 2.4).

So apparently Accounting applications are allowed to have vendor
specific Application IDs, but Auth Applications are not.  Was
this the intention?

My opinion is that the final sentence of each of these sections should
read:

  Every Diameter [authentication,accounting] application MUST have an
  IANA assigned Application Identifier, or a vendor specific
  Application Identifier.

Much of the discussion recently has focused on vendor-specific
*commands* inside standard applications, but I want to make sure we
retain the ability to define new vendor-specific *applications* as
well.  Note that I do not think there are any interoperability
concerns here, because both sides must explicitly indicate support for
a vendor-specific application before any of the commands belonging to
the application can be sent.  These applications never constitute
"changes" or "modifications" to the Diameter base protocol or to any
standard application.  Would that be acceptable to the IESG?

-Pete