Subject: RE: Colliding on Vendor Class Identification? - Not an attachment

From: Eric Michelsen <[email-masked]>
Date: Thu, 28 Jan 1999 16:42:59 -0500 (EST)

> 		d) How many Vendor class identifiers can a client have?
> 		   Only one, as there is only one DHCP client
> 		   vendor. It is impossible to have more than one, since
> 		   there would be no way to know which encapsulated
> 		   option went with which Vendor Class.

This limitation inhibits "plug-and-play" in some devices.  For example, in
the datacomm business, there are many CPE vendors whose device interoperate
with many CO equipment vendors.  Each CO vendor has some vendor-specific
capabilities, which the CPE would like to take advantage of.  But the CPE
never knows ahead of time what vendor's CO equipment it will connect to.
Therefore, it can't ask for that CO vendor's specific options.

A similar problem exists in the CO to CPE direction: even given a CPE's
vendor class identifier, the CO equipment can't keep up with all the new
CPEs hitting the field, and can't know if some new CPE's
vendor-class-identifier indicates a superset of the CO equipment's
capabilities.

It seems that there is a simple option that we could add to DHCP that
greatly simplifies vendor-specific extensions.  Define a "vendor-extension"
option of minimum length 3, whose first 3 octets are the vendor's
Organizationally Unique Identifier (OIU), and whose remaining octets (if
any) are defined by the OUI's organization.  (Smart organizations will
pattern their options after the existing "encapsulated options" of the
vendor-specific-information option.)  Clients and servers may include any
number of these vendor-extension options.

Unrecognized options are, of course, ignored.  With this option, both
clients and servers can include extensions for multiple vendors, without
knowing ahead of time to whom they are making the request.

Does this seem feasible?  How can I move this forward?