Subject: [AAA-WG]: Re: Diameter extensibility

From: Randy Bush <[email-masked]>
Date: Sat, 29 Dec 2001 10:57:53 -0800

is eeems that the results of the discussion last may of vendor-specific
commands never made it into the documents.  in specific.

---

25 of the base:

"The Command-Code field is three octets, and is used in order to
communicate the command associated with the message. The 24-bit address
space is managed by IANA (see section 11.2). 

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" [2] 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 vnedor's vendor-specific command, nor with future
IETF applications."

---

as i said last april,

> as an engineer, i sympathize with the excitement that the protocol is
> very extensible.  otoh, an architect might view that the protocol is
> merely a list of name/value tuples to indicate a lack of bounding and
> understanding of the problems and/or inability to make a real design for
> it.
> 
> open loop extensibility is really worrying the iesg.

---

and we discussed again in may:

> So, the WG questioned whether the specs could be more relax on the 
> IANA requirements for extensibility. Specifically, could a 
> vendor-specific extension be created without Standards Action.

i can see arguments for relaxing to info but not iana-only.  a
documentation trail is needed.

---

and a number of iesg members made quite clear, or at least tried to, that
any extensions, vendor or otherwise, must require previous documentation
in an rfc.

---

please consider this a bug report.  my apologies for not knowing how to
get a bug number etc.

randy