idnits 2.17.1 draft-ietf-dhc-userclass-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages 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. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 111: '... client MUST ignore it (although it ...' RFC 2119 keyword, line 112: '... servers SHOULD respond with the set...' RFC 2119 keyword, line 115: '... MUST return this option (with the g...' RFC 2119 keyword, line 119: '... SHOULD make an attempt to operate w...' RFC 2119 keyword, line 171: '...r implementation SHOULD provide flexib...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (September 1997) is 9710 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) == Unused Reference: 'DHCP' is defined on line 193, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1541 (ref. 'DHCP') (Obsoleted by RFC 2131) Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 2 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 March 1997 5 Expires September 1997 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 learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 1. 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 2. Definitions 37 Throughout this document, the words that are used to define the 38 significance of particular requirements are capitalized. These words 39 are: 41 o "MUST" 43 This word or the adjective "REQUIRED" means that the 44 item is an absolute requirement of this specification. 46 DRAFT The User Class Option for DHCP March 1997 48 o "MUST NOT" 50 This phrase means that the item is an absolute prohibition 51 of this specification. 53 o "SHOULD" 55 This word or the adjective "RECOMMENDED" means that there 56 may exist valid reasons in particular circumstances to ignore 57 this item, but the full implications should be understood and 58 the case carefully weighed before choosing a different course. 60 o "SHOULD NOT" 62 This phrase means that there may exist valid reasons in 63 particular circumstances when the listed behavior is acceptable 64 or even useful, but the full implications should be understood 65 and the case carefully weighed before implementing any behavior 66 described with this label. 68 o "MAY" 70 This word or the adjective "OPTIONAL" means that this item is 71 truly optional. One vendor may choose to include the item 72 because a particular marketplace requires it or because it 73 enhances the product, for example; another vendor may omit the 74 same item. 76 This document also uses the following terms: 78 o "DHCP client" 80 A DHCP client or "client" is an Internet host using DHCP to obtain 81 configuration parameters such as a network address. 83 o "DHCP server" 85 A DHCP server of "server"is an Internet host that returns 86 configuration parameters to DHCP clients. 88 o "binding" 90 A binding is a collection of configuration parameters, including 91 at least an IP address, associated with or "bound to" a DHCP 92 client. Bindings are managed by DHCP servers. 94 DRAFT The User Class Option for DHCP March 1997 96 3. User Class Information 98 This option is used by a DHCP client to optionally identify the type 99 or category of user or applications it represents. The information 100 contained in this option is an NVT ASCII text object that represents 101 the user class of which the client is a member. 103 DHCP administrators may define specific user class identifiers to 104 convey information about a client's software configuration or about 105 its user's preferences. For example, an identifier may specify that 106 a particular DHCP client is a member of the class "accounting 107 auditors", which have special service needs such as a particular 108 database server. 110 Servers not equipped to interpret the user class specified by a 111 client MUST ignore it (although it may be reported). Otherwise, 112 servers SHOULD respond with the set of options corresponding to the 113 user class specified by the client. Further, if the server responds 114 with the set of options corresponding to the given user class, it 115 MUST return this option (with the given user class value) to the 116 client. 118 Clients which do not receive information for the user class requested 119 SHOULD make an attempt to operate without it, although they may do so 120 (and may announce they are doing so) in a degraded mode. 122 The code for this option is 77. The minimum length for this option 123 is two. 125 Code Len text1 126 +-----+-----+-----+-----+----- 127 | 77 | N | c1 | c2 | ... 128 +-----+-----+-----+-----+----- 130 Implemention Note: Simulating Multiple User Classes 132 Although the user class option field only permits one NVT string, the 133 working group envisions that multiple classes can be simulated by 134 creating combination classes which map into a single class NVT 135 string. For example, suppose a site desires to create multiple 136 logical user classes, including: 138 "mobile" -- These hosts receive short lease times 139 and are assumed to dynamically update 140 their own DNS records 142 DRAFT The User Class Option for DHCP March 1997 144 "engineer" -- These hosts are assigned a high- 145 performance NFS file server 147 For the above two classes, then, a combination class could look 148 something like: 150 "mobeng" -- hosts of this mobile-engineer combination 151 class get assigned a high-performance 152 file server and a short lease time, and 153 a DNS proxy A record update is not attempted 154 on their behalf. 156 Thus, by mapping combinations of classes into single class names, you 157 can effectively implement multiple user classing at a site using only 158 the single NVT string field. 160 Implementation Note: Serving Competing Option Values 162 When servicing a request from a client of a particular user class, a 163 DHCP server makes decisions about what collection of options to 164 include in its response. These decisions are expected to consider 165 options and values designated for the client host by virtue of its 166 subnet/location, vendor class, user class, or client id. 168 In cases where multiple option values are possible for return to the 169 client due to multiple, overlapping "affiliations", DHCP server 170 policy may dictate which values take precedence over others. A DHCP 171 server implementation SHOULD provide flexibility in specifying DHCP 172 option precedence policy so that DHCP administrators can customize a 173 DHCP system to best suit their network environments. 175 If flexibility in a server's option precedence policy is not 176 implemented by a vendor (or is perhaps implemented but not exercised 177 by an administrator), a recommended default policy is that option 178 values of specific affiliations override those of less specific. 179 That is, an option value designated for a specific client -- 180 sometimes known as a "reserved binding" -- SHOULD override option 181 values designated for the client's user or vendor class, which SHOULD 182 override option values designated for the client's vendor class, 183 which SHOULD override option values for the client's subnet. 185 DRAFT The User Class Option for DHCP March 1997 187 Security Considerations 189 Security issues are not discussed in this document. 191 References 193 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC1541, 194 October 1993 196 Acknowledgments 198 Author Information 200 Glenn Stump 201 IBM Networking Software Solutions 202 4205 South Miami Blvd. 203 RTP, NC 27709 204 Phone: (919) 254-5616 205 email: glennstump@vnet.ibm.com 207 Ralph Droms 208 Computer Science Department 209 323 Dana Engineering 210 Bucknell University 211 Lewisburg, PA 17837 212 Phone: (717) 524-1145 213 email: droms@bucknell.edu