Subject: RE: [AAA-WG]: Vendor ID

From: <[email-masked]>
Date: Thu, 27 Jun 2002 15:51:37 +0300

Hi Pat,

> Wasn't the whole goal of having vendor specific commands to eliminate the possibility 
> of address space abuse as other vendors have done with RADIUS in the past? Are we really 
> willing to take the risk of this happening all over again, and having systems abusing the 
> same values, and therefore breaking interoperability? 

I thought so, but I'm just the messenger / editor.  This has been raised by Randy Bush, in 
issue 268.  

John

Issue 268: Diameter Extensibility 
Submitter name: Randy Bush 
Submitter email address: [email-masked] 
Date first submitted: 29-Dec-01 
Reference: 
Document: Base 08 
Comment type: Technical 
Priority: S 
Section: 
Rationale/Explanation of issue: 
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.