draft-ietf-dhc-userclass-00.txt		draft-ietf-dhc-userclass-01.txt
	Network Working Group Glenn Stump, IBM		Network Working Group Glenn Stump, IBM
	INTERNET DRAFT Ralph Droms, Bucknell University		INTERNET DRAFT Ralph Droms, Bucknell University
	November 1996		March 1997
	Expires May 1996		Expires September 1997
	The User Class Option for DHCP		The User Class Option for DHCP
	<draft-ietf-dhc-userclass-00.txt>		<draft-ietf-dhc-userclass-01.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	skipping to change at page 2, line 5		skipping to change at page 2, line 5
	Throughout this document, the words that are used to define the		Throughout this document, the words that are used to define the
	significance of particular requirements are capitalized. These words		significance of particular requirements are capitalized. These words
	are:		are:
	o "MUST"		o "MUST"
	This word or the adjective "REQUIRED" means that the		This word or the adjective "REQUIRED" means that the
	item is an absolute requirement of this specification.		item is an absolute requirement of this specification.
	DRAFT The User Class Option for DHCP April 1996		DRAFT The User Class Option for DHCP March 1997
	o "MUST NOT"		o "MUST NOT"
	This phrase means that the item is an absolute prohibition		This phrase means that the item is an absolute prohibition
	of this specification.		of this specification.
	o "SHOULD"		o "SHOULD"
	This word or the adjective "RECOMMENDED" means that there		This word or the adjective "RECOMMENDED" means that there
	may exist valid reasons in particular circumstances to ignore		may exist valid reasons in particular circumstances to ignore
	skipping to change at page 3, line 5		skipping to change at page 3, line 5
	A DHCP server of "server"is an Internet host that returns		A DHCP server of "server"is an Internet host that returns
	configuration parameters to DHCP clients.		configuration parameters to DHCP clients.
	o "binding"		o "binding"
	A binding is a collection of configuration parameters, including		A binding is a collection of configuration parameters, including
	at least an IP address, associated with or "bound to" a DHCP		at least an IP address, associated with or "bound to" a DHCP
	client. Bindings are managed by DHCP servers.		client. Bindings are managed by DHCP servers.
	DRAFT The User Class Option for DHCP April 1996		DRAFT The User Class Option for DHCP March 1997
	3. User Class Information		3. User Class Information
	This option is used by a DHCP client to optionally identify the type		This option is used by a DHCP client to optionally identify the type
	or category of user or applications it represents. The information		or category of user or applications it represents. The information
	contained in this option is an NVT ASCII text object that represents		contained in this option is an NVT ASCII text object that represents
	the user class of which the client is a member.		the user class of which the client is a member.
	DHCP administrators may define specific user class identifiers to		DHCP administrators may define specific user class identifiers to
	convey information about a client's software configuration or about		convey information about a client's software configuration or about
	skipping to change at page 3, line 41		skipping to change at page 3, line 41
	(and may announce they are doing so) in a degraded mode.		(and may announce they are doing so) in a degraded mode.
	The code for this option is 77. The minimum length for this option		The code for this option is 77. The minimum length for this option
	is two.		is two.
	Code Len text1		Code Len text1
	+-----+-----+-----+-----+-----		+-----+-----+-----+-----+-----
	| 77 | N | c1 | c2 | ...		| 77 | N | c1 | c2 | ...
	+-----+-----+-----+-----+-----		+-----+-----+-----+-----+-----
			Implemention Note: Simulating Multiple User Classes
			Although the user class option field only permits one NVT string, the
			working group envisions that multiple classes can be simulated by
			creating combination classes which map into a single class NVT
			string. For example, suppose a site desires to create multiple
			logical user classes, including:
			"mobile" -- These hosts receive short lease times
			and are assumed to dynamically update
			their own DNS records
			DRAFT The User Class Option for DHCP March 1997
			"engineer" -- These hosts are assigned a high-
			performance NFS file server
			For the above two classes, then, a combination class could look
			something like:
			"mobeng" -- hosts of this mobile-engineer combination
			class get assigned a high-performance
			file server and a short lease time, and
			a DNS proxy A record update is not attempted
			on their behalf.
			Thus, by mapping combinations of classes into single class names, you
			can effectively implement multiple user classing at a site using only
			the single NVT string field.
			Implementation Note: Serving Competing Option Values
			When servicing a request from a client of a particular user class, a
			DHCP server makes decisions about what collection of options to
			include in its response. These decisions are expected to consider
			options and values designated for the client host by virtue of its
			subnet/location, vendor class, user class, or client id.
			In cases where multiple option values are possible for return to the
			client due to multiple, overlapping "affiliations", DHCP server
			policy may dictate which values take precedence over others. A DHCP
			server implementation SHOULD provide flexibility in specifying DHCP
			option precedence policy so that DHCP administrators can customize a
			DHCP system to best suit their network environments.
			If flexibility in a server's option precedence policy is not
			implemented by a vendor (or is perhaps implemented but not exercised
			by an administrator), a recommended default policy is that option
			values of specific affiliations override those of less specific.
			That is, an option value designated for a specific client --
			sometimes known as a "reserved binding" -- SHOULD override option
			values designated for the client's user or vendor class, which SHOULD
			override option values designated for the client's vendor class,
			which SHOULD override option values for the client's subnet.
			DRAFT The User Class Option for DHCP March 1997
	Security Considerations		Security Considerations
	Security issues are not discussed in this document.		Security issues are not discussed in this document.
	References		References
	[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC1541,		[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC1541,
	October 1993		October 1993
	Acknowledgments		Acknowledgments
	DRAFT The User Class Option for DHCP April 1996
	Author Information		Author Information
	Glenn Stump		Glenn Stump
	IBM Networking Software Solutions		IBM Networking Software Solutions
	4205 South Miami Blvd.		4205 South Miami Blvd.
	RTP, NC 27709		RTP, NC 27709
	Phone: (919) 254-5616		Phone: (919) 254-5616
	email: glennstump@vnet.ibm.com		email: glennstump@vnet.ibm.com
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/