idnits 2.17.1 draft-ietf-dhc-new-opt-msg-02.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. ** 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 127: '... (128-254) MUST NOT be defined for u...' -- The draft header indicates that this document obsoletes draft-ietf-dhc-new-opt-msg-01.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 119 has weird spacing: '...ombined into ...' -- No information found for rfcdraft-ietf-dhc-new-opt-msg-01.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 (December 2000) is 8523 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 238 ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2489 (ref. '5') (Obsoleted by RFC 2939) Summary: 9 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-opt-msg-01.txt July 2000 4 Expires December 2000 6 Procedures and IANA Guidelines for Definition of 7 New DHCP Options and Message Types 8 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt, and the list of 25 Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 The Dynamic Host Configuration Protocol (DHCP) provides a framework 31 for passing configuration information to hosts on a TCP/IP network. 32 Configuration parameters and other control information are carried in 33 tagged data items that are stored in the 'options' field of the DHCP 34 message. The data items themselves are also called "options." 36 DHCP protocol messages are identified by the 'DHCP Message Type' 37 option (option code 51). Each message type is defined by the data 38 value carried in the 'DHCP Message Type' option. 40 New DHCP options and message types may be defined after the 41 publication of the DHCP specification to accommodate requirements for 42 conveyance of new configuration parameters or to accommodate new 43 protocol semantics. This document describes the procedure for 44 defining new DHCP options and message types. 46 1. Introduction 47 DRAFT Procedures for New DHCP Options and Message Types July, 2000 49 The Dynamic Host Configuration Protocol (DHCP) [1] provides a 50 framework for passing configuration information to hosts on a TCP/IP 51 network. Configuration parameters and other control information are 52 carried in tagged data items that are stored in the 'options' field 53 of the DHCP message. The data items themselves are also called 54 "options." [2] 56 DHCP protocol messages are identified by the 'DHCP Message Type' 57 option (option code 51). Each message type is defined by the data 58 value carried in the 'DHCP Message Type' option. 60 This document describes the procedure for defining new DHCP options 61 and message types. The procedure will guarantee that: 63 * allocation of new option numbers and message type numbers is 64 coordinated from a single authority, 65 * new options and message types are reviewed for technical 66 correctness and appropriateness, and 67 * documentation for new options and message types is complete and 68 published. 70 As indicated in "Guidelines for Writing an IANA Considerations 71 Section in RFCs" (see references), IANA acts as a central authority 72 for assignment of numbers such as DHCP option and message type codes. 73 The new procedure outlined in this document will provide guidance to 74 IANA in the assignment of new option and message type codes. 76 This document updates and replaces RFC 2489. 78 2. Overview and background 80 This document specifies procedures for defining new option codes and 81 message types. 83 2.1 New DHCP option codes 85 The procedure described in this document modifies and clarifies the 86 procedure for defining new options in RFC 2131 [2]. The primary 87 modification is to the time at which a new DHCP option is assigned an 88 option number. In the procedure described in this document, the 89 option number is not assigned until specification for the option is 90 about to be published as an RFC. 92 Since the publication of RFC 2132, the option number space for 93 publicly defined DHCP options (1-127) has almost been exhausted. 94 Many of the defined option numbers have not been followed up with 95 Internet Drafts submitted to the DHC WG. There has been a lack of 96 specific guidance to IANA from the DHC WG as to the assignment of 98 DRAFT Procedures for New DHCP Options and Message Types July, 2000 100 DHCP option numbers. 102 The procedure as specified in RFC 2132 does not clearly state that 103 new options are to be reviewed individually for technical 104 correctness, appropriateness and complete documentation. RFC 2132 105 also does not require that new options are to be submitted to the 106 IESG for review, and that the author of the option specification is 107 responsible for bringing new options to the attention of the IESG. 108 Finally, RFC 2132 does not make clear that newly defined options are 109 not to be incorporated into products, included in other 110 specifications or otherwise used until the specification for the 111 option is published as an RFC. 113 In the future, new DHCP option codes will be assigned by IETF 114 consensus. New DHCP options will be documented in RFCs approved by 115 the IESG, and the codes for those options will be assigned at the 116 time the relevant RFCs are published. Typically, the IESG will seek 117 input on prospective assignments from appropriate sources (e.g., a 118 relevant Working Group if one exists). Groups of related options may 119 be combined into a single specification and reviewed as a set by the 120 IESG. Prior to assignment of an option code, it is not appropriate 121 to incorporate new options into products, include the specification 122 in other documents or otherwise make use of the new options. 124 The DHCP option number space (1-254) is split into two parts. The 125 site-specific option codes [2] (128-254) are defined as "Private Use" 126 and require no review by the DHC WG. Site-specific options codes 127 (128-254) MUST NOT be defined for use by any publicly distributed 128 DHCP server, client or relay agent implementations. These option 129 codes are explicitly reserved for private definition and use within a 130 site or an organization. 132 The public option codes (0-127, 255) are defined as "Specification 133 Required" and new options must be reviewed prior to assignment of an 134 option number by IANA. The details of the review process are given 135 in the following section of this document. 137 2.2 New DHCP message types 139 RFC2131 does not specify any mechanism for defining new DHCP message 140 types. In the future, new DHCP message types will be documented in 141 RFCs approved by the IESG, and the codes for these new message types 142 will be assigned at the time the relevant RFCs are published. 144 Typically, the IESG will seek input on new message types from 145 appropriate sources (e.g., a relevant Working Group if one exists). 146 Prior to assignment of a message type code, it is not appropriate to 147 incorporate new message types into products, include the 149 DRAFT Procedures for New DHCP Options and Message Types July, 2000 151 specification in other documents or otherwise make use of the new 152 message types. 154 3. Procedure 156 The author of a new DHCP option or message type will follow these 157 steps to obtain approval for the option and publication of the 158 specification of the option as an RFC: 160 1. The author devises the new option or message type. 162 2. The author documents the new option or message type, leaving the 163 option code or message type code as "To Be Determined" (TBD), as 164 an Internet Draft. 166 The requirement that the new option or message type be documented 167 as an Internet Draft is a matter of expediency. In theory, the 168 new option or message type could be documented on the back of an 169 envelope for submission; as a practical matter, the specification 170 will eventually become an Internet Draft as part of the review 171 process. 173 3. The author submits the Internet Draft for review by the IESG. 174 Preferably, the author will submit the Internet Draft to the DHC 175 Working Group, but the author may choose to submit the Internet 176 Draft directly to the IESG. 178 Note that simply publishing the new option or message type as an 179 Internet Draft does not automatically bring the option to the 180 attention of the IESG. The author of the new option or message 181 type must explicitly forward a request for action on the new 182 option to the DHC WG or the IESG. 184 4. The specification of the new option or message type is reviewed by 185 the IESG. The specification is reviewed by the DHC WG (if it 186 exists) or by the IETF. If the option or message type is accepted 187 for inclusion in the DHCP specification, the specification of the 188 option or message type is published as an RFC. It may be 189 published as either a standards-track or a non-standards-track 190 RFC. 192 5. At the time of publication as an RFC, IANA assigns a DHCP option 193 code or message type code to the new option or message type. 195 DRAFT Procedures for New DHCP Options and Message Types July, 2000 197 4. References 199 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell 200 University, March 1997. 202 [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 203 Extensions", RFC 2132, Lachman Associates, March 1997. 205 [3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information", RFC 206 2142, November 1997. 208 [4] Narten, T. and H. T. Alvestrand, "Guidelines for Writing an IANA 209 Considerations Section in RFCs", RFC 2434, October 1998. 211 [5] Droms, R., "Procedure for Defining New DHCP Options", RFC 2489, 212 January 1999. 214 5. Changes from RFC2489 216 This document extends the procedures for defining new DHCP options 217 specified in RFC 2489 [5] to include the definition of new DHCP 218 message types. The language reserving site-specific option codes 219 has been strengthened to emphasize the requirement that site- 220 specific option codes must not be encoded in publicly distributed 221 DHCP implementations. 223 6. Security Considerations 225 Information that creates or updates an option code or message type 226 code assignment needs to be authenticated. 228 An analysis of security issues is required for all newly defined DHCP 229 options or message types. The description of security issues in the 230 specification of new options or message types must be as accurate as 231 possible. The specification for a new option or message type may 232 reference the "Security Considerations" section in the DHCP 233 specification [1]; e.g. (from "NetWare/IP Domain Name and 234 Information" [3]): 236 DHCP currently provides no authentication or security mechanisms. 237 Potential exposures to attack are discussed in section 7 of the 238 DHCP protocol specification [RFC 2131]. 240 DRAFT Procedures for New DHCP Options and Message Types July, 2000 242 7. IANA Considerations 244 RFC 2132 and RFC 2489 provided guidance to the IANA on the procedure 245 it should follow when assigning option numbers for new DHCP options 246 or message types. This document updates and replaces those 247 instructions. In particular, IANA is requested to assign DHCP option 248 codes or message type codes only for options or message types that 249 have been approved for publication as RFCs; i.e., documents that have 250 been approved through "IETF consensus" as defined in RFC 2434 [4]. 252 8. Author's Address 254 Ralph Droms 255 Computer Science Department 256 323 Dana Engineering 257 Bucknell University 258 Lewisburg, PA 17837 260 Phone: (570) 524-1145 261 EMail: droms@bucknell.edu 263 9. Expiration 265 This document will expire on December 31, 2000. 267 DRAFT Procedures for New DHCP Options and Message Types July, 2000 269 10. Full Copyright Statement 271 Copyright (C) The Internet Society (2000). All Rights Reserved. 273 This document and translations of it may be copied and furnished to 274 others, and derivative works that comment on or otherwise explain it 275 or assist in its implementation may be prepared, copied, published and 276 distributed, in whole or in part, without restriction of any kind, 277 provided that the above copyright notice and this paragraph are 278 included on all such copies and derivative works. However, this 279 document itself may not be modified in any way, such as by removing 280 the copyright notice or references to the Internet Society or other 281 Internet organizations, except as needed for the purpose of developing 282 Internet standards in which case the procedures for copyrights defined 283 in the Internet Standards process must be followed, or as required to 284 translate it into languages other than English. 286 The limited permissions granted above are perpetual and will not be 287 revoked by the Internet Society or its successors or assigns. 289 This document and the information contained herein is provided on an 290 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 291 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 292 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 293 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 294 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.