--- 1/draft-ietf-dhc-userclass-01.txt 2006-02-04 23:06:24.000000000 +0100 +++ 2/draft-ietf-dhc-userclass-02.txt 2006-02-04 23:06:24.000000000 +0100 @@ -1,18 +1,18 @@ Network Working Group Glenn Stump, IBM INTERNET DRAFT Ralph Droms, Bucknell University - March 1997 - Expires September 1997 + November 1997 + Expires May 1998 The User Class Option for DHCP - + Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any @@ -36,21 +36,21 @@ Throughout this document, the words that are used to define the significance of particular requirements are capitalized. These words are: o "MUST" This word or the adjective "REQUIRED" means that the item is an absolute requirement of this specification. -DRAFT The User Class Option for DHCP March 1997 +DRAFT The User Class Option for DHCP November 1997 o "MUST NOT" This phrase means that the item is an absolute prohibition of this specification. o "SHOULD" This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore @@ -84,21 +84,21 @@ A DHCP server of "server"is an Internet host that returns configuration parameters to DHCP clients. o "binding" A binding is a collection of configuration parameters, including at least an IP address, associated with or "bound to" a DHCP client. Bindings are managed by DHCP servers. -DRAFT The User Class Option for DHCP March 1997 +DRAFT The User Class Option for DHCP November 1997 3. User Class Information This option is used by a DHCP client to optionally identify the type or category of user or applications it represents. The information contained in this option is an NVT ASCII text object that represents the user class of which the client is a member. DHCP administrators may define specific user class identifiers to convey information about a client's software configuration or about @@ -132,21 +132,21 @@ 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 +DRAFT The User Class Option for DHCP November 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 @@ -175,30 +175,35 @@ 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 +DRAFT The User Class Option for DHCP November 1997 Security Considerations - Security issues are not discussed in this document. + DHCP currently provides no authentication or security mechanisms. + Potential exposures to attack are discussed is section 7 of the + protocol specification [1]. References - [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC1541, - October 1993 + [1] Droms, R., "Dynamic Host Configuration Protocol", RFC2131, March + 1997 + + [2] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, March 1997 Acknowledgments Author Information Glenn Stump IBM Networking Software Solutions 4205 South Miami Blvd. RTP, NC 27709 Phone: (919) 254-5616