Overview
========

  In order to fix 5028977, this case proposes to slightly change the current
  algorithm used to map a platform name to a DHCP vendor class identifier.

  The new format is identical to the old format, with one exception: the DHCP
  vendor class identifier is only prefixed with "SUNW." if the platform name
  does *not* already contain a stock symbol, which is identified as a string
  delimited by a comma.  The affected systems are:

	Fujitsu, whose platform names start with "FJSV,"
	Naturetech, whose platform names start with "NATE,"
	Tadepole, whose platform names start with "Tadpole_"

  That last one will still be "SUNW.Tadpole_" after the change, but there's
  not much we can do about systems that don't use the defacto format.

  Further, this case also proposes to document the format in dhcpagent(1M).
  We also propose to classify the format as "Evolving".

  The requested release binding is minor.

Details
=======

  The DHCP vendor class identifier is one of a set of identifiers the DHCP
  client provides to the DHCP server during lease negotiation.  The DHCP
  server uses the class identifier to help decide what vendor options are
  applicable to the client, and what the values of those options should be.

  RFC 2132, which documents the vendor class identifier, does not specify any
  particular format, but just states:

     This option is used by DHCP clients to optionally identify the vendor
     type and configuration of a DHCP client.  The information is a string
     of n octets, interpreted by servers.  Vendors may choose to define
     specific vendor class identifiers to convey particular configuration
     or other identification information about a client.  For example, the
     identifier may encode the client's hardware configuration.  

  However, Solaris has an established de-facto format that we have been using
  since Solaris 2.6: STOCK-SYMBOL.Platform-Name -- e.g.: SUNW.Ultra-60.

  One will note that this is the same as "uname -i | tr , ." with one
  exception: i86pc.  To accomodate i86pc, we added code to the DHCP client
  which automatically prepends "SUNW." if the returned platform name does not
  already include it.  This is done to increase the probability that the
  client class identifier is globally unique across all operating systems
  that the DHCP server may be serving.

  Unfortunately, this algorithm failed to consider that it might run on
  platforms sold by other vendors.  As such, on Fujitsu machines, the DHCP
  client uses a bogus vendor class identifier of "SUNW.FJSV.platform-name",
  rather than the correct "FJSV.platform-name".

  Thus, we propose to revise the algorithm so that the DHCP vendor class
  identifier is only prefixed with "SUNW." if the platform name does *not*
  already contain a stock symbol.

Compatibility
=============

  This change will not affect Sun SPARC systems, since all such platform names
  already start with "SUNW,", and will not affect x86 systems since all
  systems have the unprefixed platform name of "i86pc".  Thus, the change is
  isolated to Fujitsu systems.

  While some that DHCP servers which serve Fujitsu systems will have to be
  updated to reflect the new class identifier, the impact is mitigated
  because:
    
	* The vendor class identifier is primarily used for DHCP-based
	  net installs.  However, the Fujitsu PROM's have always properly
	  identified their machines as FJSV.platform-name.  Thus, DHCP
	  servers have historically included entries for both vendor
	  class identifiers.

	* DHCP is more prevalent on desktop systems.  Since Fujitsu has
	  targeted the server market, we expect comparatively few Fujitsu
	  systems are configured as DHCP clients.

  Still, we understand that some systems will be affected.  Unfortunately,
  since the DHCP server will necessarily be serving a variety of different
  operating systems (and thus, different releases of Solaris), and may itself
  be running on a previous release of Solaris, there is no transparent way to
  handle systems which are affected by this change.  However, we feel it's
  best we correct this mistake now, before it sediments further.

Documentation
=============

  We propose to add the following to dhcpagent(1M):

	   All DHCP packets sent by dhcpagent include a vendor class
	   identifier (RFC 2132, option code 60).  This identifier is
	   the same as the platform name returned by "uname -i", except:

		* Any commas in the platform name are changed to
		  periods.

		* If the name does not start with a stock symbol and
		  a comma, it is automatically prefixed with "SUNW."