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

From: "Pat R. Calhoun" <[email-masked]>
Date: Thu, 27 Jun 2002 05:46:15 -0700

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?

PatC

-----Original Message-----
From: [email-masked]
To: [email-masked]
Sent: 6/26/2002 11:50 PM
Subject: [AAA-WG]: Vendor ID

In section 3 Diameter Header

There is the Vendor-ID field:

  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 unless for Private Use as
described 
  in Section 11.2.1.

My feeling is that should be updated to this:

  In the event that the Command-Code field contains an experimental 
  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 using an experimental
Diameter 
  command MUST use their own Vendor-ID.

John