idnits 2.17.1 draft-ietf-dhc-userclass-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. -- The draft header indicates that this document obsoletes draft-ietf-dhc-userclass-02.txt, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- No information found for rfcdraft-ietf-dhc-userclass-02.txt - is the name correct? -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 1999) is 9084 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Glenn Stump, IBM 3 INTERNET DRAFT Ralph Droms, Bucknell University 4 Obsoletes: draft-ietf-dhc-userclass-02.txt November 1998 5 Expires May 1999 7 The User Class Option for DHCP 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 25 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 26 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 Abstract 30 This option is used by a DHCP client to optionally identify the type 31 or category of user or applications it represents. The information 32 contained in this option is an NVT ASCII text object that represents 33 the user class of which the client is a member. 35 1. Requirements Terminology 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 39 document are to be interpreted as described in RFC 2119 [3]. 41 2. DHCP Terminology 43 o "DHCP client" 45 A DHCP client or "client" is an Internet host using DHCP to obtain 46 configuration parameters such as a network address. 48 DRAFT The User Class Option for DHCP November 1998 50 o "DHCP server" 52 A DHCP server of "server"is an Internet host that returns 53 configuration parameters to DHCP clients. 55 o "binding" 57 A binding is a collection of configuration parameters, including 58 at least an IP address, associated with or "bound to" a DHCP 59 client. Bindings are managed by DHCP servers. 61 3. User Class Information 63 This option is used by a DHCP client to optionally identify the type 64 or category of user or applications it represents. The information 65 contained in this option is an NVT ASCII text object that represents 66 the user class of which the client is a member. 68 This option is a DHCP option [1, 2]. 70 DHCP administrators may define specific user class identifiers to 71 convey information about a client's software configuration or about 72 its user's preferences. For example, an identifier may specify that 73 a particular DHCP client is a member of the class "accounting 74 auditors", which have special service needs such as a particular 75 database server. 77 Servers not equipped to interpret the user class specified by a 78 client MUST ignore it (although it may be reported). Otherwise, 79 servers SHOULD respond with the set of options corresponding to the 80 user class specified by the client. Further, if the server responds 81 with the set of options corresponding to the given user class, it 82 MUST return this option (with the given user class value) to the 83 client. 85 Clients which do not receive information for the user class requested 86 SHOULD make an attempt to operate without it, although they may do so 87 (and may announce they are doing so) in a degraded mode. 89 The code for this option is TBD. The minimum length for this option 90 is two. 92 Code Len text1 93 +-----+-----+-----+-----+----- 94 | TBD | N | c1 | c2 | ... 95 +-----+-----+-----+-----+----- 97 DRAFT The User Class Option for DHCP November 1998 99 DISCUSSION: Simulating Multiple User Classes 101 Although the user class option field only permits one NVT string, 102 the working group envisions that multiple classes can be simulated 103 by creating combination classes which map into a single class NVT 104 string. For example, suppose a site desires to create multiple 105 logical user classes, including: 107 "mobile" -- These hosts receive short lease times 108 and are assumed to dynamically update 109 their own DNS records 111 "engineer" -- These hosts are assigned a high- 112 performance NFS file server 114 For the above two classes, then, a combination class could look 115 something like: 117 "mobeng" -- hosts of this mobile-engineer combination 118 class get assigned a high-performance 119 file server and a short lease time, and 120 a DNS proxy A record update is not attempted 121 on their behalf. 123 Thus, by mapping combinations of classes into single class names, 124 you can effectively implement multiple user classing at a site 125 using only the single NVT string field. 127 DISCUSSION: Serving Competing Option Values 129 When servicing a request from a client of a particular user class, 130 a DHCP server makes decisions about what collection of options to 131 include in its response. These decisions are expected to consider 132 options and values designated for the client host by virtue of its 133 subnet/location, vendor class, user class, or client id. 135 In cases where multiple option values are possible for return to 136 the client due to multiple, overlapping "affiliations", DHCP 137 server policy may dictate which values take precedence over 138 others. A DHCP server implementation SHOULD provide flexibility 139 in specifying DHCP option precedence policy so that DHCP 140 administrators can customize a DHCP system to best suit their 141 network environments. 143 DRAFT The User Class Option for DHCP November 1998 145 If flexibility in a server's option precedence policy is not 146 implemented by a vendor (or is perhaps implemented but not 147 exercised by an administrator), a recommended default policy is 148 that option values of specific affiliations override those of less 149 specific. That is, an option value designated for a specific 150 client -- sometimes known as a "reserved binding" -- SHOULD 151 override option values designated for the client's user or vendor 152 class, which SHOULD override option values designated for the 153 client's vendor class, which SHOULD override option values for the 154 client's subnet. 156 4. Security Considerations 158 DHCP currently provides no authentication or security mechanisms. 159 Potential exposures to attack are discussed is section 7 of the 160 protocol specification [1]. 162 5. References 164 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 165 March 1997. 167 [2] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor 168 Extensions", RFC 2132, March 1997. 170 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 171 Levels," RFC 2119, March 1997. 173 DRAFT The User Class Option for DHCP November 1998 175 6. Author Information 177 Glenn Stump 178 IBM Networking Software 179 P.O. Box 12195 180 RTP, NC 27709 181 Phone: (919) 301-4277 182 email: stumpga@us.ibm.com 184 Ralph Droms 185 Computer Science Department 186 323 Dana Engineering 187 Bucknell University 188 Lewisburg, PA 17837 189 Phone: (717) 524-1145 190 email: droms@bucknell.edu 192 7. Expiration 194 This document will expire on May 31, 1999. 196 Full Copyright Statement 198 Copyright (C) The Internet Society (1998). All Rights Reserved. 200 This document and translations of it may be copied and furnished to 201 others, and derivative works that comment on or otherwise explain it 202 or assist in its implementation may be prepared, copied, published 203 and distributed, in whole or in part, without restriction of any 204 kind, provided that the above copyright notice and this paragraph are 205 included on all such copies and derivative works. However, this 206 document itself may not be modified in any way, such as by removing 207 the copyright notice or references to the Internet Society or other 208 Internet organizations, except as needed for the purpose of 209 developing Internet standards in which case the procedures for 210 copyrights defined in the Internet Standards process must be 211 followed, or as required to translate it into languages other than 212 English. 214 The limited permissions granted above are perpetual and will not be 215 revoked by the Internet Society or its successors or assigns. 217 This document and the information contained herein is provided on an 218 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 219 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 220 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 222 DRAFT The User Class Option for DHCP November 1998 224 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 225 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.