idnits 2.17.1 draft-ietf-dhc-new-options-05.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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. -- The draft header indicates that this document obsoletes draft-ietf-dhc-new-options-04.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 == Line 102 has weird spacing: '...ombined into ...' -- No information found for rfcdraft-ietf-dhc-new-options-04.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) -- Looks like a reference, but probably isn't: 'RFC 2131' on line 182 ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Droms 2 INTERNET-DRAFT Bucknell University 3 Obsoletes: draft-ietf-dhc-new-options-04.txt November 1998 4 Expires May 1999 6 Procedure for Defining New DHCP Options 7 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 24 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 25 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 27 Abstract 29 The Dynamic Host Configuration Protocol (DHCP) provides a framework 30 for passing configuration information to hosts on a TCP/IP network. 31 Configuration parameters and other control information are carried in 32 tagged data items that are stored in the 'options' field of the DHCP 33 message. The data items themselves are also called "options." 35 New DHCP options may be defined after the publication of the DHCP 36 specification to accommodate requirements for conveyance of new 37 configuration parameters. This document describes the procedure for 38 defining new DHCP options. 40 1. Introduction 42 The Dynamic Host Configuration Protocol (DHCP) [1] provides a 43 framework for passing configuration information to hosts on a TCP/IP 44 network. Configuration parameters and other control information are 45 carried in tagged data items that are stored in the 'options' field 46 of the DHCP message. The data items themselves are also called 47 "options." [2] 49 DRAFT Procedure for Defining New DHCP Options November 1998 51 This document describes the procedure for defining new DHCP options. 52 The procedure will guarantee that: 54 * allocation of new option numbers is coordinated from a single 55 authority, 56 * new options are reviewed for technical correctness and 57 appropriateness, and 58 * documentation for new options is complete and published. 60 As indicated in "Guidelines for Writing an IANA Considerations 61 Section in RFCs" (see references), IANA acts as a central authority 62 for assignment of numbers such as DHCP option codes. The new 63 procedure outlined in this document will provide guidance to IANA in 64 the assignment of new option codes. 66 2. Overview and background 68 The procedure described in this document modifies and clarifies the 69 procedure for defining new options in RFC 2131 [2]. The primary 70 modification is to the time at which a new DHCP option is assigned an 71 option number. In the procedure described in this document, the 72 option number is not assigned until specification for the option is 73 about to be published as an RFC. 75 Since the publication of RFC 2132, the option number space for 76 publically defined DHCP options (1-127) has almost been exhausted. 77 Many of the defined option numbers have not been followed up with 78 Internet Drafts submitted to the DHC WG. There has been a lack of 79 specific guidance to IANA from the DHC WG as to the assignment of 80 DHCP option numbers 82 The procedure as specified in RFC 2132 does not clearly state that 83 new options are to be reviewed individually for technical 84 correctness, appropriateness and complete documentation. RFC 2132 85 also does not require that new options are to be submitted to the 86 IESG for review, and that the author of the option specification is 87 responsible for bringing new options to the attention of the IESG. 88 Finally, RFC 2132 does not make clear that newly defined options are 89 not to be incorporated into products, included in other 90 specifications or otherwise used until the specification for the 91 option is published as an RFC. 93 In the future, new DHCP option codes will be assigned by IETF 94 consensus. New DHCP options will be documented in RFCs approved by 95 the IESG, and the codes for those options will be assigned at the 96 time the relevant RFCs are published. Typically, the IESG will seek 97 input on prospective assignments from appropriate sources (e.g., a 98 relevant Working Group if one exists). Groups of related options may 100 DRAFT Procedure for Defining New DHCP Options November 1998 102 be combined into a single specification and reviewed as a set by the 103 IESG. Prior to assignment of an option code, it is not appropriate 104 to incorporate new options into products, include the specification 105 in other documents or otherwise make use of the new options. 107 The DHCP option number space (1-254) is split into two parts. The 108 site-specific options (128-254) are defined as "Private Use" and 109 require no review by the DHC WG. The public options (1-127) are 110 defined as "Specification Required" and new options must be reviewed 111 prior to assignment of an option number by IANA. The details of the 112 review process are given in the following section of this document. 114 3. Procedure 116 The author of a new DHCP option will follow these steps to obtain 117 approval for the option and publication of the specification of the 118 option as an RFC: 120 1. The author devises the new option. 122 2. The author documents the new option, leaving the option code as 123 "To Be Determined" (TBD), as an Internet Draft. 125 The requirement that the new option be documented as an Internet 126 Draft is a matter of expediency. In theory, the new option could 127 be documented on the back of an envelope for submission; as a 128 practical matter, the specification will eventually become an 129 Internet Draft as part of the review process. 131 3. The author submits the Internet Draft for review by the IESG. 132 Preferably, the author will submit the Internet Draft to the DHC 133 Working Group, but the author may choose to submit the Internet 134 Draft directly to the IESG. 136 Note that simply publishing the new option as an Internet Draft 137 does not automatically bring the option to the attention of the 138 IESG. The author of the new option must explicitly forward a 139 request for action on the new option to the DHC WG or the IESG. 141 4. The specification of the new option is reviewed by the IESG. The 142 specification is reviewed by the DHC WG (if it exists) or by the 143 IETF. If the option is accepted for inclusion in the DHCP 144 specification, the specification of the option is published as an 145 RFC. It may be published as either a standards-track or a non- 146 standards-track RFC. 148 5. At the time of publication as an RFC, IANA assigns a DHCP option 150 DRAFT Procedure for Defining New DHCP Options November 1998 152 number to the new option. 154 4. References 156 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell 157 University, March 1997. 159 [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 160 Extensions", RFC 2132, Lachman Associates, March 1997. 162 [3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information", RFC 163 2142, November 1997. 165 [4] Narten, T. and H. T. Alvestrand, "Guidelines for Writing an IANA 166 Considerations Section in RFCs", RFC 2434, October 1998. 168 5. Security Considerations 170 Information that creates or updates an option number assignment needs 171 to be authenticated. 173 An analysis of security issues is required for all newly defined DHCP 174 options. The description of security issues in the specification of 175 new options must be as accurate as possible. The specification for a 176 new option may reference the "Security Considerations" section in the 177 DHCP specification [1]; e.g. (from "NetWare/IP Domain Name and 178 Information" [3]): 180 DHCP currently provides no authentication or security mechanisms. 181 Potential exposures to attack are discussed in section 7 of the 182 DHCP protocol specification [RFC 2131]. 184 6. IANA Considerations 186 RFC 2132 provided guidance to the IANA on the procedure it should 187 follow when assigning option numbers for new DHCP options. This 188 document updates and replaces those instructions. In particular, 189 IANA is requested to assign DHCP option numbers only for options that 190 have been approved for publication as RFCs; i.e., documents that have 191 been approved through "IETF consensus" as defined in RFC 2434 [4]. 193 DRAFT Procedure for Defining New DHCP Options November 1998 195 7. Author's Address 197 Ralph Droms 198 Computer Science Department 199 323 Dana Engineering 200 Bucknell University 201 Lewisburg, PA 17837 203 Phone: (717) 524-1145 204 EMail: droms@bucknell.edu 206 8. Expiration 208 This document will expire on May 31, 1999. 210 DRAFT Procedure for Defining New DHCP Options November 1998 212 9. Full Copyright Statement 214 Copyright (C) The Internet Society (1998). All Rights Reserved. 216 This document and translations of it may be copied and furnished to 217 others, and derivative works that comment on or otherwise explain it 218 or assist in its implementation may be prepared, copied, published and 219 distributed, in whole or in part, without restriction of any kind, 220 provided that the above copyright notice and this paragraph are 221 included on all such copies and derivative works. However, this 222 document itself may not be modified in any way, such as by removing 223 the copyright notice or references to the Internet Society or other 224 Internet organizations, except as needed for the purpose of developing 225 Internet standards in which case the procedures for copyrights defined 226 in the Internet Standards process must be followed, or as required to 227 translate it into languages other than English. 229 The limited permissions granted above are perpetual and will not be 230 revoked by the Internet Society or its successors or assigns. 232 This document and the information contained herein is provided on an 233 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 234 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 235 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 236 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 237 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.