idnits 2.17.1 draft-ietf-dhc-namedpool-00.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-26) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 3 longer pages, the longest (page 2) being 63 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Abstract' ) ** 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 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 108: '...P administrators MAY assign specific n...' RFC 2119 keyword, line 111: '.... A DHCP client MAY then be configure...' RFC 2119 keyword, line 113: '... server SHOULD assign an addr...' RFC 2119 keyword, line 117: '...fied by a client MUST ignore it. Othe...' RFC 2119 keyword, line 118: '... servers SHOULD respond with a...' (6 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 (November 1997) is 9659 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: 'RFC2131' is defined on line 150, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 155, but no explicit reference was found in the text Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Kelly McGrew, 3 INTERNET DRAFT CompuServe Inc. 4 May 1997 5 Expires November 1997 7 The Named Pool Request Option for DHCP 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are 13 working documents of the Internet Engineering Task Force 14 (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum 19 of six months and may be updated, replaced, or obsoleted 20 by other documents at any time. It is inappropriate to 21 use Internet-Drafts as reference material or to cite them 22 other than as ``work in progress.'' 24 To learn the current status of any Internet-Draft, please 25 check the ``1id-abstracts.txt'' listing contained in the 26 Internet-Drafts Shadow Directories on ftp.is.co.za 27 (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific 28 Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US 29 West Coast). 31 1. Abstract 33 This option is used by a DHCP client to optionally 34 identify the specific named pool from which it should be 35 assigned an IP address. The information contained in 36 this option is an ASCII text object that represents the 37 named pool from which the DHCP server assign an IP 38 address to the DHCP client. 40 2. Definitions 42 Throughout this document, the words that are used to 43 define the significance of particular requirements are 44 capitalized. These words are: 46 o "MUST" 48 This word or the adjective "REQUIRED" means that the 49 item is an absolute requirement of this specification. 51 DRAFT The Named Pool Request Option for DHCPMay 1997 53 o "MUST NOT" 55 This phrase means that the item is an absolute 56 prohibition of this specification. 58 o "SHOULD" 60 This word or the adjective "RECOMMENDED" means that 61 there may exist valid reasons in particular 62 circumstances to ignore this item, but the full 63 implications should be understood and the case 64 carefully weighed before choosing a different course. 66 o "SHOULD NOT" 68 This phrase means that there may exist valid reasons in 69 particular circumstances when the listed behavior is 70 acceptable or even useful, but the full implications 71 should be understood and the case carefully weighed 72 before implementing any behavior described with this 73 label. 75 o "MAY" 77 This word or the adjective "OPTIONAL" means that this 78 item is truly optional. One vendor may choose to 79 include the item because a particular marketplace 80 requires it or because it enhances the product, for 81 example; another vendor may omit the same item. 83 This document also uses the following terms: 85 o "DHCP client" 87 A DHCP client or "client" is an Internet host using 88 DHCP to obtain configuration parameters such as a 89 network address. 91 o "DHCP server" 93 A DHCP server of "server" is an Internet host that 94 returns configuration parameters to DHCP clients. 96 3. Named Pool Information 98 This option is used by a DHCP client to optionally 99 identify the specific named pool from which it should be 100 assigned an IP address. The information contained in 102 DRAFT The Named Pool Request Option for DHCPMay 1997 104 this option is an ASCII text object that represents the 105 named pool from which the DHCP server assign an IP 106 address to the DHCP client. 108 DHCP administrators MAY assign specific names to IP 109 address pools on a DHCP server. For example, pools may 110 be established for various departments or network 111 segments. A DHCP client MAY then be configured to 112 request an address from a specific named pool. A DHCP 113 server SHOULD assign an address from the requested named 114 pool to the DHCP client. 116 Servers not equipped to interpret the named pool 117 specified by a client MUST ignore it. Otherwise, DHCP 118 servers SHOULD respond with an IP address from the pool 119 corresponding to the named pool specified by the DHCP 120 client. If the DHCP server returns no address due to a 121 named pool's address range being depleted, the DHCP 122 client MAY resubmit another request with a different 123 named pool name. 125 Clients which do not which do not request a named pool 126 SHOULD be treated in a manner consistent with DHCP server 127 configuration. A DHCP server MAY be configured to 128 provide only named pool addresses, in which case a client 129 requesting an address without using the named pool option 130 from a DHCP server which supports solely this option MUST 131 be denied an address. A DHCP server MAY be configured to 132 automatically rotor to an alternative pool. The DHCP 133 server MAY then assign an address from this alternative 134 pool. 136 The code for this option is TBD. The minimum length for 137 this option is two. 139 Code Len text1 140 +-----+-----+-------------+----- 141 | TBD | N | named_pool | ... 142 +-----+-----+-------------+----- 144 Security Considerations 146 Security issues are not discussed in this document. 148 References 150 [RFC2131] Droms, R., "Dynamic Host Configuration 151 Protocol", RFC 2131, March 1997. 153 DRAFT The Named Pool Request Option for DHCPMay 1997 155 [RFC2132] S. Alexander, R. Droms, "DHCP Options and BOOTP 156 Vendor Extensions" 158 Acknowledgments 160 The author would like to thank Doug Dixon, Joe 161 Hirschinger, and Rick Ogg for commenting on and making 162 suggestions to this proposal. 164 Author Information 166 Kelly McGrew 167 CompuServe Inc. 168 3535 - 128th Avenue SE 169 Bellevue, WA 98006 170 Phone: (206) 957-8317 171 kmcgrew@csi.compuserve.com