Subject: [AAA-WG]: Edits to Diameter 11 to resolve vendor-specific command code issue

From: <[email-masked]>
Date: Tue, 11 Jun 2002 12:12:50 +0300

Hi all,

Here is my suggested text for Diameter to fix this issue.

John

1.2  Approach to Extensibility

   The Diameter protocol is designed to be extensible. However, it is
   strongly encouraged to reuse existing mechanisms before attempting
   any Diameter extensions.  The extensibility includes:

      - Defining new AVP values.
      - Creating new AVPs
      - Creating new authentication/authorization applications
      - Creating new accounting applications
      - Application authentication procedures

   The extension MUST be documented through an IETF process.  The 
   documentation MUST describe interaction with Diameter peers 
   that do not implement the extension.

******

3  Diameter Header

[clip]

   Vendor-ID
      In the event that the Command-Code field contains a vendor
      specific command, the four-octet Vendor-ID field contains the IANA
      assigned "SMI Network Management Private Enterprise Codes"
      [ASSIGNNO] value. If the Command-Code field contains an IETF
      standard Command, the Vendor-ID field MUST be set to zero (0). Any
      vendor wishing to implement a vendor-specific Diameter command
      MUST use their own Vendor-ID along with their privately managed
      Command-Code address space, guaranteeing that they will not
      collide with any other vendor's vendor-specific command, nor with
      future IETF applications. All vendor-specific Diameter commands
      require Informational RFCs documenting the command and specifying
	interoperation with Diameter peers not implementing the command.

---

From: <[email-masked]>
Date: Wed, 12 Jun 2002 18:24:57 +0300

Randy,

> > My feeling is that not all Diameter extensions (vendor-specific)
> > are meant as standards, so in my opinion, a paper trail is what is
> > needed.
> 
> lack of a paper trail is a show-stopper.  whether it needs to be
> standard track, i can explore once things are in sufficient shape
> that i won't get an explosion in my face when the current
> we-can-do-whatever-we-want is seen.

The current "we-can-do-whatever-we-want" is not really the intention
of the draft, I think that there is information in the document, but
it is not organized well. I will pull together the info and then
we can go forward.

> and another standards body wanting to use an ietf standard and
> modify it in arbitrary ways because they don't want to follow ietf
> process will be met with a stone wall at best.  note how carefully
> the ietf does not step on the ieee's ethernet standards (to get our
> jumbo frames in), the itu on sdh/sonet, ...

Understood.  I think that on this subject, it is good to engage in
constructive discussion between the SDOs.

John