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

From: Avi Lior <[email-masked]>
Date: Wed, 1 Jun 2011 19:25:23 -0400

So here you go Glen.

The wording in the 3588 is really screwed up hence the confusion
everywhere. I don't necessarily disagree with your interpretation.

5.3.3 Vendor-Id is the vendor of the Diameter Application.

Vendor or SDO is the same - we all agree.

Given that that Cisco is the device Vendor - the entity that made the
machine.

And WiMAX forum as the vendor(SDO) of the Diameter Application - they own
that Specification and thus they are the vendor for the Diameter
APplication.

Therefore, regarding Vendor-Id.

Since WiMAX is the vendor of the WiMAX DIameter Application and Cisco is
only the device vendor then Vendor-Id attribute should be set to WiMAX
Forum.

5.3.3 does not state that the vendor-id is set to the *implementor* of the
Diameter Application.

So that is what is wrong with the text in section 5.3.3

If we want to align the text to your interpretation of the text I suggest
we re-write to explicitly state what we mean potentially as follows:

From:
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.

TO:
 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 implementor of the  Diameter
application. 

Even Better (using the text from 5.3.6)
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 device vendor.

Logically it makes sense since a given platform is made by one vendor and
supports zero or more applications.  Thus given the cardinality of the
attributes, it makes sense that Vendor-Id records the manufacturers
identity.  

Also, reading towards the end, of 5.3.3 we get further hints that it is
the device vendor.

The bottom line, does the Vendor Id and Supported Vendor actually matter.
In some SDOs its not used at all.

-- Avi Lior
--Bridgewater Systems

On 13-05-11 21:11 , "Glen Zorn" <[email-masked]> wrote:

>On 5/13/2011 8:42 AM, Alper Yegin wrote:
>
>>>> What is "a vendor other than the device vendor"? Is it equivalent to
>>> the
>>>> Forum in the aforementioned example?
>>>>
>>>> Thanks.
>>>
>>> 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?
>
>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?
>
>...

---

From: Glen Zorn <[email-masked]>
Date: Thu, 02 Jun 2011 12:33:22 +0700

> Given that that Cisco is the device Vendor - the entity that made the

OK

> that Specification and thus they are the vendor for the Diameter

OK.

> only the device vendor then Vendor-Id attribute should be set to WiMAX

Nope.  In this case, the Vendor-Id should be set to Cisco & an instance
of the Vendor-Specific-Application-Id AVP (RFC 3588, Section 6.11) must
be included, set to WiMAX Forum.  If a "server" running on a
multipurpose computer or appliance, the Vendor-Id should be set to, for
example, Open Diameter but still the Vendor-Specific-Application-Id must
be present.

> value assigned to the device vendor.

Yes, that's better, but there is the possibility on the "server" side
(on the "client" side, too, I suppose, but that seems less likely) that
the vendor of the base protocol code is different from the creator of
the application code, right?  For example, someone might build a plug-in
for an existing base Diameter server to implement the WiMAX application.
 So maybe "assigned to the Diameter software vendor" might be better?

> attributes, it makes sense that Vendor-Id records the manufacturers

Yes.

> In some SDOs its not used at all.

One-trick ponies?

---

From: Avi Lior <[email-masked]>
Date: Thu, 2 Jun 2011 09:54:02 -0400

See inline...
-- Avi Lior
--Bridgewater Systems

>example, Open Diameter but still the Vendor-Specific-Application-Id must

I know that is what you *think* should go in -- I don't disagree -- but
you asked what is wrong with the text and I am telling you that when you
read the text it instructs you to put the Vendor Id of the Diameter
Application and in no way can I come to your conclusion (the correct one)
by the text in 3588.

> So maybe "assigned to the Diameter software vendor" might be better?

Perhaps.  The stack and application(s) on top of it is all software to me.
 To me the statement is saying (not the hardware vendor) I.e., not Sun or
IBM etc... But I wouldn't think that anyone would think that putting down
the hardware.

In situations that you are mentioning where the stack and applications are
different.  Then we do have an issue.  If what we are using this
information for is to learn which extensions I can use on the next hop and
if those extensions apply to either or both the stack and the application
then I would need to convey both vendor's (stack and application) to the
next hop.  There are no instructions on how to use these 'tools'.  In this
case we could put one vendor id in the Vendor-Id attribute, the other in
the Supported-Vendor attribute.  But which?  Its a mess.  The bottom line
is is this ever used?  What are the typical use cases? And should be
document how one would use this information.

People must realize that this is a hop by hop thing.  Some people think
that it is an end-to-end thing. As a hop by hop mechanism how useful is it
especially when many if not most of the time we are talking through one or
more intermediaries before we get to the application "end" points.  And
that is when we are really interested in Vendor extension and thus who
wrote the APplication code/who wrote the stack code etc.

---

From: Glen Zorn <[email-masked]>
Date: Fri, 03 Jun 2011 01:17:59 +0700

On 6/2/2011 8:54 PM, Avi Lior wrote:

...

> Application and in no way can I come to your conclusion (the correct one)

OK, it actually says "Diameter application"; there's a difference.  IIRC
there was a debate about the wording here.  I think that it originally
said "Diameter software" but somebody pointed out that in a NAS, router,
etc. it would actually be "Diameter firmware" but nobody liked "Diameter
software or firmware" so "application" was taken as a compromise,
apparently incorrectly.

...

> the Supported-Vendor attribute.  

We could, but that would be wrong IMHO: if it is a vendor-specific app
then there is an AVP specifically designed to carry that information,
the Vendor-Specific-Application-Id.  The Supported-Vendor-ID AVP is
specifically used to advertise support for vendor-specific AVPs, _not_ apps.

...

---

From: Avi Lior <[email-masked]>
Date: Thu, 2 Jun 2011 14:56:28 -0400

Okay so lets recap:

We seem to agree that the wording for Vendor ID should be changed to:
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 Diameter software vendor.

We need an errata? 

-- Avi Lior
--Bridgewater Systems

---

From: Glen Zorn <[email-masked]>
Date: Fri, 03 Jun 2011 02:22:59 +0700

> value assigned to the Diameter software vendor.

It's pretty minor, maybe we can just stick it in 3588bis.

...

---

From: Avi Lior <[email-masked]>
Date: Thu, 2 Jun 2011 17:18:33 -0400

Works for me.

-- Avi Lior
--Bridgewater Systems