Subject: Re: Colliding on Vendor Class Identification? - Not an

From: Rob Stevens <[email-masked]>
Date: Thu, 28 Jan 1999 16:42:13 -0500 (EST)

At 02:41 PM 1/28/99 -0500, Rhys Weatherley wrote:
>
>
>
>
>Mike Carney - SNT Internet Engineering wrote on Wed, 27 Jan 1999 21:13:24 GMT:
>
>     
>     >               Successful Vendor class support requires the ability to
>     >       configure a DHCP server to support a new vendor class by
>     >       associating that vendor class identifier with 253 options whose
>     >       types can then be defined by following the DHCP client's
>     >       documentation. Each group of 253 options has the "scope" of that
>     >       Vendor. For example, let's say we have the following two clients:
>
>If I'm reading this correctly, it appears that the only options that
>can be varied by the server on a vendor class basis are the encapsulated
>vendor-specific options.  It doesn't appear to allow regular DHCP
>options to be varied based on the vendor class.  However, varying the
>regular DHCP options is the most common use for the vendor class in
>the network computing space.
>
>As an example, x86-based NC's from NCI, and the JavaStation from Sun,
>both use the root path option (17) to specify the location of a root
>filesystem to obtain program binaries and related files from.  The
>root filesystems for these two client types are completely different.
>It isn't possible to use the root filesystem for one client type on
>another.......
>
>

Rhys

I don't read it that way and I'm sure that Mike doesn't intend it that way.

Servers can use the vendor class to determine the the appropriate
value for any of the "normal" or what one might call "class less"
DHCP options.  As you observe, using the vendor class is
essential, more and more, for selecting the proper values.

What Mike is saying that each non-null value for the vendor
class implies 253 other options which differ in type
and semantics from each other (although there may be
"accidental" coincidences e.g. one vendor may define
several vendor tags, but many of the options defined
under each tag are likely to be identical in type and
semantics (though quite possibly not in value). Nonetheless
one cannot assume this)

I think it is worth pointing out that although a vendor option
may be unique in terms of (type,semantics), its semantics
may dictate that its value 
nonetheless depend on other factors (such as what
network the client is attached to, or even the specific
client identifier).

Rob Stevens