Subject: [Dime] Vendor-Id vs Supported-Vendor-Id

From: "Alper Yegin" <[email-masked]>
Date: Thu, 12 May 2011 21:30:16 +0300

Question:

What is the distinction between these two AVPs?

If an implementation includes vendor-specific extensions, some of which are
coming from the vendor (manufacturer) itself, and others from a Forum spec
it is complying to, then which value goes into which AVP?

Does "manufacturer id" go into "Vendor-Id", and "Forum's IANA-assigned
Enterprise id" go into "Supported-Vendor-Id"?

RFC says:

5.3.6. Supported-Vendor-Id AVP

   The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and
   contains the IANA "SMI Network Management Private Enterprise Codes"
   [ASSIGNNO] value assigned to a vendor other than the device vendor.
   This is used in the CER and CEA messages in order to inform the peer
   that the sender supports (a subset of) the vendor-specific AVPs
   defined by the vendor identified in this AVP.

What is "a vendor other than the device vendor"? Is it equivalent to the
Forum in the aforementioned example?

Thanks.

Alper

---

From: jouni korhonen <[email-masked]>
Date: Thu, 12 May 2011 22:46:15 +0300

Hi,

> Forum in the aforementioned example?

Say, a vendor X implemented a Diameter agent and some application in it. The vendor X also saw it beneficial to support vendor specific extensions from vendors A, B and C for that application. During CER/CEA exchange A, B and C would be put into Supported-Vendor-Id AVPs. The X would be put into Vendor-Id AVP.

- Jouni

> 
> Alper
> 
> 
> 
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 13 May 2011 04:42:12 +0300

> Say, a vendor X implemented a Diameter agent and some application in
> it. The vendor X also saw it beneficial to support vendor specific
> extensions from vendors A, B and C for that application. During CER/CEA
> exchange A, B and C would be put into Supported-Vendor-Id AVPs. The X
> would be put into Vendor-Id AVP.

If vendor X implemented both its own extensions and also extensions from
SDO/Forum Foo, can we say X is carried in Vendor-Id and Foo is carried in
Supported-Vendor-Id? Is that the intent of the spec? 

Alper

---

From: jouni korhonen <[email-masked]>
Date: Fri, 13 May 2011 09:38:09 +0300

Hi,

> Supported-Vendor-Id? Is that the intent of the spec? 

Vendor and SDO/Forum do not make difference if they have their own SMI codes.

- Jouni

---

From: Glen Zorn <[email-masked]>
Date: Sat, 14 May 2011 08:11:17 +0700

> Supported-Vendor-Id? Is that the intent of the spec?

The Vendor-Id AVP identifies the source of the implementation; for
example, a Cisco NAS would identify itself as such by means of this AVP.
 One could assume that a Cisco NAS would support at least a subset of
the Cisco vendor-specific extensions, but it would be safer IMHO for it
to include a Supported-Vendor-Id AVP containing the Cisco SMI code as
well.  There can be multiple instances of the Supported-Vendor-Id AVP in
a message, but only a single instance of the Vendor-Id AVP.  I'm most
interested in what is unclear about the spec, though.  Here is the
section of RFC 3588 defining the Vendor-Id AVP:

5.3.3.  Vendor-Id AVP

   The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains
   the IANA "SMI Network Management Private Enterprise Codes" [ASSIGNNO]
   value assigned to the vendor of the Diameter application.  In
   combination with the Supported-Vendor-Id AVP (Section 5.3.6), this
   MAY be used in order to know which vendor specific attributes may be
   sent to the peer.  It is also envisioned that the combination of the
   Vendor-Id, Product-Name (Section 5.3.7) and the Firmware-Revision
   (Section 5.3.4) AVPs MAY provide very useful debugging information.

   A Vendor-Id value of zero in the CER or CEA messages is reserved and
   indicates that this field is ignored.

Obviously there's something wrong with this text; what is it?

...