Subject: Re: Colliding on Vendor Class Identification? - Not an attachment (Fwd)

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Wed, 27 Jan 1999 23:13:19 -0500 (EST)

Here it is again, this time not an attachment. (sorry for the duplication)

>----------------Begin Forwarded Message----------------<

	i) Clarify use of Vendor class identifier (form)
	================================================

		a) What characters are legal? (some new clients have
		   spaces in their identifier, which broke some
		   implementations with configuration file records
		   delimited by white-space).

		b) What is the form of the name space? (originally
		   (1541 time-frame), we had discussed using
		   "Stock symbol/Organization...." form to prevent
		   collisions between vendors. E.g.: "SUNW.foo.bar" or
		   "CMU.foo.bar". This text should be included in 2132.

		c) Text describing each unique vendor class identifier
		   can support a 253 unique encapsulated option name
		   space. Some folks think that there is only one 253
		   unique encapsulated option name space, and return
		   the same values to *any* client returning *any*
		   vendor class identifier. Obviously, we should include
		   text to clarify the relationship between Vendor Class
		   identifier and the encapsulated Vendor option.

		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.

		Here is some more text regarding vendor options from
	a previous note I wrote regarding the use of Vendor class /
	encapsulated options:

		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:

	Vendor Class "SunBeam.Toaster.2slots"

		Options for this class:
		Code	Len	Data
		1	2	Darkness setting

		Darkness setting is a 2 byte integer.

	Vendor Class "GE.Answering.Machine"

		Options for this class:
		Code	Len	Data
		1	X	Outgoing message

		Outgoing message is an ASCII string, X bytes long,
	consisting of the text of the answer message.

		Both clients are on the same network "Kitchen", and are
	clients of the same DHCP server. Note that both use Encapsulated
	option code 1. Looks like a conflict, but it isn't.

		In the syntax of the DHCP server's configuration table,
	I configure two new options, each which has the "scope" of the
	vendor class. What this means is that when the toaster boots,
	the dhcp server only returns vendor class options associated
	with the "SunBeam.Toaster.2slots" class. When the answering
	machine boots, it only seens vendor class options associated
	with the "GE.Answering.Machine" class. Clients of vendor classes
	not currently configured on the server don't see any
	encapsulated vendor options, since the server hasn't been
	configured to support that vendor class. The dhcp server can
	make this distinction based upon:

		a) The client identifies it's vendor class.

		b) The server can be (and has been) configured to
		   associate each client's vendor options with the
		   client's class identifier.

---

From: Rhys Weatherley <[email-masked]>
Date: Thu, 28 Jan 1999 14:37:49 -0500 (EST)

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

But option 17 is a regular DHCP option, not an encapsulated option.
Without using the vendor class to distinguish the two client types
in the server, it is necessary to manually configure MAC addresses
for every single client.  A daunting task for 1000's of clients.

Now, I realize that the vendor class was only supposed to pertain
to the encapsulated options in the original formulation of the
standard.  But common practice seems to have moved away from that,
since most clients only need standard options, but still need to be
recognized as different by the server.

Is it necessary to get the standard's wording altered to reflect
common practice, or should we instead come up with another mechanism
for determing the differences in the regular options that are returned?

Another option, "user class", does exist and could be used to
distinguish client types.  However, I have yet to come across
any clients that support it.  It also doesn't have the same
meaning in my mind.  I see user class as being useful to
distinguish two or more groups of users that are using the
same vendor's clients, but need to use slightly different
software.  The vendor class would be the primary identifier,
and the user class the secondary identifier, when trying to
locate boot information for a network computing client.

To the original question: using the vendor's company name or
the name of some common standard that the client adheres
to (e.g. "PXEClient"), should be sufficient to prevent
collisions.  The advantage of the string ID model used
in Internet standards over the number-based model used
in OSI standards has always been that any ordinary human
can usually devise a unique string, without having to
consult a central repository of knowledge, as long as
the human follows a few very obvious naming rules.

Cheers,

Rhys.

---

From: Warren Belfer <[email-masked]>
Date: Thu, 28 Jan 1999 16:39:01 -0500 (EST)

> Date: Thu, 28 Jan 1999 14:41:11 -0500 (EST)
> Originator: [email-masked]
> From: Rhys Weatherley <[email-masked]>
> To: Multiple recipients of list <[email-masked]>
> Subject: Re: Colliding on Vendor Class Identification? - Not an attachment (Fwd)
> X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
> X-Comment: Discussion of DHCP for IPv4
> Mime-Version: 1.0
> Content-Transfer-Encoding: 7bit
> 
> 
> 
> 
> 

Although Mike's example deals with the vendor encapsualted options, the server can be 
configured to send any of the DHCP options to clients that identify themselves with a 
given vendor class identifier. The ability to do that might be server specific, but for 
example, the Sun dhcp server can be easily configured to send a different root path 
option depending on the vendor class identifier. In fact, that's exactly the way we do 
that with our various NC models. 

Warren Belfer
Sun Microsystems