idnits 2.17.1 draft-ietf-dhc-new-opt-msg-00.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: ---------------------------------------------------------------------------- ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 118 has weird spacing: '...ombined into ...' -- 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 2000) is 8556 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 224 ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 3 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 May 2000 4 Expires November 2000 6 Procedure for Defining New DHCP Options and Message Types 7 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 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 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt, and the list of 24 Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 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 DHCP protocol messages are identified by the 'DHCP Message Type' 36 option (option code 51). Each message type is defined by the data 37 value carried in the 'DHCP Message Type' option. 39 New DHCP options and message types may be defined after the 40 publication of the DHCP specification to accommodate requirements for 41 conveyance of new configuration parameters or to accommodate new 42 protocol semantics. This document describes the procedure for 43 defining new DHCP options and message types. 45 1. Introduction 47 The Dynamic Host Configuration Protocol (DHCP) [1] provides a 49 DRAFT Defining New DHCP Options and Message Types June, 2000 51 framework for passing configuration information to hosts on a TCP/IP 52 network. Configuration parameters and other control information are 53 carried in tagged data items that are stored in the 'options' field 54 of the DHCP message. The data items themselves are also called 55 "options." [2] 57 DHCP protocol messages are identified by the 'DHCP Message Type' 58 option (option code 51). Each message type is defined by the data 59 value carried in the 'DHCP Message Type' option. 61 This document describes the procedure for defining new DHCP options 62 and message types. The procedure will guarantee that: 64 * allocation of new option numbers and message type numbers is 65 coordinated from a single authority, 66 * new options and message types are reviewed for technical 67 correctness and appropriateness, and 68 * documentation for new options and message types is complete and 69 published. 71 As indicated in "Guidelines for Writing an IANA Considerations 72 Section in RFCs" (see references), IANA acts as a central authority 73 for assignment of numbers such as DHCP option codes. The new 74 procedure outlined in this document will provide guidance to IANA in 75 the assignment of new option and message type codes. 77 2. Overview and background 79 This document specifies procedures for defining new option codes and 80 message types. 82 2.1 New DHCP option codes 84 The procedure described in this document modifies and clarifies the 85 procedure for defining new options in RFC 2131 [2]. The primary 86 modification is to the time at which a new DHCP option is assigned an 87 option number. In the procedure described in this document, the 88 option number is not assigned until specification for the option is 89 about to be published as an RFC. 91 Since the publication of RFC 2132, the option number space for 92 publically defined DHCP options (1-127) has almost been exhausted. 93 Many of the defined option numbers have not been followed up with 94 Internet Drafts submitted to the DHC WG. There has been a lack of 95 specific guidance to IANA from the DHC WG as to the assignment of 96 DHCP option numbers 98 The procedure as specified in RFC 2132 does not clearly state that 100 DRAFT Defining New DHCP Options and Message Types June, 2000 102 new options are to be reviewed individually for technical 103 correctness, appropriateness and complete documentation. RFC 2132 104 also does not require that new options are to be submitted to the 105 IESG for review, and that the author of the option specification is 106 responsible for bringing new options to the attention of the IESG. 107 Finally, RFC 2132 does not make clear that newly defined options are 108 not to be incorporated into products, included in other 109 specifications or otherwise used until the specification for the 110 option is published as an RFC. 112 In the future, new DHCP option codes will be assigned by IETF 113 consensus. New DHCP options will be documented in RFCs approved by 114 the IESG, and the codes for those options will be assigned at the 115 time the relevant RFCs are published. Typically, the IESG will seek 116 input on prospective assignments from appropriate sources (e.g., a 117 relevant Working Group if one exists). Groups of related options may 118 be combined into a single specification and reviewed as a set by the 119 IESG. Prior to assignment of an option code, it is not appropriate 120 to incorporate new options into products, include the specification 121 in other documents or otherwise make use of the new options. 123 The DHCP option number space (1-254) is split into two parts. The 124 site-specific options (128-254) are defined as "Private Use" and 125 require no review by the DHC WG. The public options (1-127) are 126 defined as "Specification Required" and new options must be reviewed 127 prior to assignment of an option number by IANA. The details of the 128 review process are given in the following section of this document. 130 2.2 New DHCP message types 132 RFC2131 does not specify any mechanism for defining new DHCP message 133 types. In the future, new DHCP message types will be document in RFCs 134 approved by the IESG, and the codes for these new message types will 135 be assigned at the time the relevant RFCs are published. 137 Typically, the IESG will seek input on new message types from 138 appropriate sources (e.g., a relevant Working Group if one exists). 139 Prior to assignment of a message type code, it is not appropriate to 140 incorporate new message types into products, include the 141 specification in other documents or otherwise make use of the new 142 message types. 144 When the DHC WG has defined a procedure for the consideration and 145 review of changes to the DHCP specification that include the 146 definition of new message types, that procedure will be followed 147 prior to the accepatance of any new message types and the publication 148 of the specification of those message types in RFCs. 150 DRAFT Defining New DHCP Options and Message Types June, 2000 152 3. Procedure 154 The author of a new DHCP option or message type will follow these 155 steps to obtain approval for the option and publication of the 156 specification of the option as an RFC: 158 1. The author devises the new option or message type. 160 2. The author documents the new option or message type, leaving the 161 option code or message type code as "To Be Determined" (TBD), as 162 an Internet Draft. 164 The requirement that the new option or message type be documented 165 as an Internet Draft is a matter of expediency. In theory, the 166 new option or message type could be documented on the back of an 167 envelope for submission; as a practical matter, the specification 168 will eventually become an Internet Draft as part of the review 169 process. 171 3. The author submits the Internet Draft for review by the IESG. 172 Preferably, the author will submit the Internet Draft to the DHC 173 Working Group, but the author may choose to submit the Internet 174 Draft directly to the IESG. 176 Note that simply publishing the new option or message type as an 177 Internet Draft does not automatically bring the option to the 178 attention of the IESG. The author of the new option or message 179 type must explicitly forward a request for action on the new 180 option to the DHC WG or the IESG. 182 4. The specification of the new option or message typeis reviewed by 183 the IESG. The specification is reviewed by the DHC WG (if it 184 exists) or by the IETF. If the option or message type is accepted 185 for inclusion in the DHCP specification, the specification of the 186 option or message type is published as an RFC. It may be 187 published as either a standards-track or a non-standards-track 188 RFC. 190 5. At the time of publication as an RFC, IANA assigns a DHCP option 191 code or message type code to the new option or message type. 193 4. References 195 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell 196 University, March 1997. 198 [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 199 Extensions", RFC 2132, Lachman Associates, March 1997. 201 DRAFT Defining New DHCP Options and Message Types June, 2000 203 [3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information", RFC 204 2142, November 1997. 206 [4] Narten, T. and H. T. Alvestrand, "Guidelines for Writing an IANA 207 Considerations Section in RFCs", RFC 2434, October 1998. 209 5. Security Considerations 211 Information that creates or updates an option code or message type 212 code assignment needs to be authenticated. 214 An analysis of security issues is required for all newly defined DHCP 215 options or message types. The description of security issues in the 216 specification of new options or message types must be as accurate as 217 possible. The specification for a new option or message typemay 218 reference the "Security Considerations" section in the DHCP 219 specification [1]; e.g. (from "NetWare/IP Domain Name and 220 Information" [3]): 222 DHCP currently provides no authentication or security mechanisms. 223 Potential exposures to attack are discussed in section 7 of the 224 DHCP protocol specification [RFC 2131]. 226 6. IANA Considerations 228 RFC 2132 provided guidance to the IANA on the procedure it should 229 follow when assigning option numbers for new DHCP options or message 230 types. This document updates and replaces those instructions. In 231 particular, IANA is requested to assign DHCP option codes or message 232 type codes only for options or message types that have been approved 233 for publication as RFCs; i.e., documents that have been approved 234 through "IETF consensus" as defined in RFC 2434 [4]. 236 7. Author's Address 238 Ralph Droms 239 Computer Science Department 240 323 Dana Engineering 241 Bucknell University 242 Lewisburg, PA 17837 244 Phone: 570) 524-1145 245 EMail: droms@bucknell.edu 247 8. Expiration 249 This document will expire on November 30, 2000. 251 DRAFT Defining New DHCP Options and Message Types June, 2000 253 9. Full Copyright Statement 255 Copyright (C) The Internet Society (2000). All Rights Reserved. 257 This document and translations of it may be copied and furnished to 258 others, and derivative works that comment on or otherwise explain it 259 or assist in its implementation may be prepared, copied, published and 260 distributed, in whole or in part, without restriction of any kind, 261 provided that the above copyright notice and this paragraph are 262 included on all such copies and derivative works. However, this 263 document itself may not be modified in any way, such as by removing 264 the copyright notice or references to the Internet Society or other 265 Internet organizations, except as needed for the purpose of developing 266 Internet standards in which case the procedures for copyrights defined 267 in the Internet Standards process must be followed, or as required to 268 translate it into languages other than English. 270 The limited permissions granted above are perpetual and will not be 271 revoked by the Internet Society or its successors or assigns. 273 This document and the information contained herein is provided on an 274 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 275 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 276 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 277 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 278 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.