idnits 2.17.1 draft-dittert-host-sys-char-02.txt: 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-24) 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. ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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 are 6 instances of too long lines in the document, the longest one being 36 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 105: '... DHCP clients SHOULD include this op...' RFC 2119 keyword, line 109: '... use this option MAY include the optio...' RFC 2119 keyword, line 111: '... the option MUST denote a system arc...' RFC 2119 keyword, line 112: '...d. DHCP servers MUST NOT include this...' RFC 2119 keyword, line 134: '... DHCP clients SHOULD include this op...' (9 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 (July 31, 1998) is 9399 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) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Mike Henry 3 Eric Dittert 4 Intel Corp. 5 July 31, 1998 7 DHCP Options For Host System Characteristics 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 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a "working 21 draft" or "work in progress." 23 Please check the "1id-abstracts.txt" listing contained in the 24 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 25 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net 26 (US East Coast), or ftp.isi.edu (US West Coast). 28 Notice 29 All product and company names mentioned herein might be trademarks 30 of their respective owners. 32 Abstract 34 The interoperability of configuration services based on the Dynamic 35 Host Configuration Protocol (DHCP) [1] in an environment of 36 heterogeneous clients depends on clients accurately identifying 37 themselves and their relevant characteristics to configuration 38 servers. The class identifier provided through DHCP option 60 [2] 39 helps in this regard, but such identifiers essentially only enable 40 clients and servers that are 'good friends' to find each other. This 41 draft proposes the definition of two options that convey particular, 42 generally useful information about the client system. This enables 43 all servers to recognize this information, and is a step toward a 44 richer form of interoperability for configuration services. 46 June 16, 1998 48 The proposed options are 49 * Client System Architecture 50 * Client Network Device Interface 51 * UUID/GUID-based Client Identifier 53 1.0 Introduction 55 The use of DHCP to provide clients with configuration information in 56 general, and boot images in particular can be complicated by several 57 circumstances. Among these are 58 1) clients in the same service domain with different system 59 architectures or hardware configurations 60 2) clients in the same service domain for which different software 61 configurations are desired 62 3) the desire to have clients and servers provided by different 63 vendors successfully interact 64 (By "clients in the same service domain" we mean clients, requests 65 from which can reach the same server.) A key element in enabling the 66 successful use of DHCP in such circumstances is the provision of 67 mechanisms by which clients can accurately identify themselves and 68 their relevant characteristics to a server. 70 For identifying characteristics of the client that are relevant to 71 the selection of a boot image, the currently available mechanisms are 72 the DHCP class identifier option (code 60) and the DHCP vendor 73 specific information option (code 43). By definition, the vendor 74 specific information option does not address the problem of enabling 75 interoperability of clients and servers provided by different 76 vendors. Information conveyed by the class identifier option could 77 enable interoperability, provided that a sufficiently specific and 78 complete set of class identifiers were defined and agreed to. 80 We suggest using an alternate approach, in which new, specific 81 options are used to convey the characteristics of the client that 82 determine which boot image(s) could run on the client, and the class 83 identifier is used as a (site-specific) designation of the desired 84 software configuration for the client. Section 2 defines two new 85 options that are useful for conveying the client's hardware 86 configuration. 88 For identifying the client as a unique entity, the currently 89 available mechanism is the DHCP client identifier option (code 61) 90 [2]. Section 3 of this draft defines an alternative option (code 97) 91 identifier type based on generated GUIDs - identifiers that are 92 guaranteed to be, or are very, very likely to be unique across time 93 and all clients. 95 June 16, 1998 97 2.0 Client Characteristics Options 99 The options defined in this section provide the server with explicit 100 knowledge about the client system that is generally useful in 101 selecting an executable that the client can use as a boot image. 103 2.1 Client System Architecture Option 105 DHCP clients SHOULD include this option in DHCPDISCOVER and 106 DHCPREQUEST messages. Doing so provides the server with explicit 107 knowledge of the client's system architecture. 109 DHCP servers that use this option MAY include the option in 110 responses that contain a bootfile name. If included, the value of 111 the option MUST denote a system architecture for which the bootfile 112 named is valid. DHCP servers MUST NOT include this option in 113 responses that do not contain a bootfile name. 115 The format for this option is as follows: 117 Code Len System Arch Code 118 +-----+-----+-----+-----+ 119 | 93 | 2 | s1 | s2 | 120 +-----+-----+-----+-----+ 122 The currently defined types and their codes are 124 System Architecture Code 125 ------------------- ---- 126 Intel Architecture PC 0 127 NEC PC-9800 1 128 Intel Architecture 64 PC 2 129 DEC Alpha 3 130 ARCx86 4 132 2.2 Client Network Device Interface Option 134 DHCP clients SHOULD include this option in DHCPDISCOVER and 135 DHCPREQUEST messages. Doing so provides the server with explicit 136 knowledge of the client's network device. 138 DHCP servers that use this option MAY include the option in 139 responses that contain a bootfile name. If included, the value of 140 the option MUST denote a network device for which the bootfile named 141 is valid. DHCP servers MUST NOT include this option in responses 142 that do not contain a bootfile name. 144 June 16, 1998 146 Three types of network device specifications are defined for use with 147 this option: 148 * devices that support the Universal Network Driver Interface 149 (UNDI), as described in "Network PC System Design Guidelines: A 150 Reference for Designing Net PC Systems for Use with the 151 Microsoft Windows and Windows NT Operating Systems" [3] 152 * Plug-and-Play devices [4] 153 * PCI devices [5] 155 Each device that supports (UNDI) MUST be specified as an UNDI 156 device, regardless of whether it is also a Plug-and-Play device or a 157 PCI device. To specify an UNDI device, the option contains a type 158 code of 1 and the major and minor UNDI version numbers: 160 Code Len Type Major Minor 161 +-----+-----+-----+-----+-----+ 162 | 94 | 3 | 1 | m1 | m2 | 163 +-----+-----+-----+-----+-----+ 165 To specify a PCI network device, a type code of 2 is used, and the 166 vendor ID, device ID, class code, and revision are included: 168 Code Len Type Vendor ID Device ID Class code Rev 169 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 170 | 94 | 9 | 2 | v1 | v2 | d3 | d4 | c1 | c2 | c3 | r1 | 171 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 173 To specify a Plug-and-Play network device, a type code of 3 is used, 174 and the EISA device ID and the class code are included: 176 Code Len Type EISA device ID Class code 177 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 178 | 94 | 8 | 3 | e1 | e2 | e3 | e4 | c1 | c2 | c3 | 179 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 181 June 16, 1998 183 3.0 Unique Client Identifier 185 This option (code 97) provides a unique client identifier. Type 0 of 186 this identifier is defined to be in UUID/GUID format. A client 187 identifier option containing a type code of 0 MUST contain a 128-bit 188 GUID as follows: 190 Code Len Type Client GUID 191 +------+------+-----+------+------+------+ 192 | 97 | 17 | 0 | g1 | g2 | ... | 193 +------+------+-----+------+------+------+ 195 The format of the GUID MUST be as specified in the design guidelines 196 for Net PCs [3]. 198 A client machine providing this option MUST use the same GUID value 199 each time the option is used. That is, the GUID MUST be static. 201 DHCP clients SHOULD include this option in all DHCP messages. Doing so provides the server with a unique 202 and static identifier for the client platform. 204 4.0 References 206 [1] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131 208 [2] Alexander,S. and Droms, R., "DHCP Options and BOOTP Vendor 209 Extension" RFC 2132. 211 [3] "Network PC System Design Guidelines: A Reference for 212 Designing Net PC Systems for Use with the Microsoft Windows 213 and Windows NT Operating Systems", 214 http://www.intel.com/managedpc 216 [4] Intel Corp. and Microsoft Corp., "Plug and Play ISA 217 Specification", Version 1.0a, May 5, 1994 219 [5] Peripheral Component Interconnect Special Interest Group, 220 "Peripheral Component Interconnect Specification", Revision 221 2.1, available through PCISIG, 222 http://www.pcisig.com/specs.html 224 June 16, 1998 226 5.0 Authors' Addresses 228 Mike Henry 229 Intel Corporation, MS JF3-408 230 5200 NE Elam Young Pkwy 231 Hillsboro, OR 97124 233 Phone: (503) 264-9689 234 Email: Mike_Henry@ccm.jf.intel.com 236 Eric Dittert 237 Intel Corporation, MS JF3-206 238 5200 NE Elam Young Pkwy 239 Hillsboro, OR 97124 241 Phone: (503) 264-8461 242 Email: Eric_Dittert@ccm.jf.intel.com