draft-ietf-dhc-new-options-02.txt   draft-ietf-dhc-new-options-03.txt 
Network Working Group R. Droms Network Working Group R. Droms
INTERNET-DRAFT Bucknell University INTERNET-DRAFT Bucknell University
Obsoletes: draft-ietf-dhc-new-options-01.txt August 1998 Obsoletes: draft-ietf-dhc-new-options-02.txt September 1998
Expires February 1999 Expires March 1999
Procedure for Defining New DHCP Options Procedure for Defining New DHCP Options
<draft-ietf-dhc-new-options-02.txt> <draft-ietf-dhc-new-options-03.txt>
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 5 skipping to change at page 2, line 5
Introduction Introduction
The Dynamic Host Configuration Protocol (DHCP) [1] provides a The Dynamic Host Configuration Protocol (DHCP) [1] provides a
framework for passing configuration information to hosts on a TCP/IP framework for passing configuration information to hosts on a TCP/IP
network. Configuration parameters and other control information are network. Configuration parameters and other control information are
carried in tagged data items that are stored in the 'options' field carried in tagged data items that are stored in the 'options' field
of the DHCP message. The data items themselves are also called of the DHCP message. The data items themselves are also called
"options." [2] "options." [2]
DRAFT Procedure for Defining New DHCP Options August 1998 DRAFT Procedure for Defining New DHCP Options September 1998
This document describes the procedure for defining new DHCP options. This document describes the procedure for defining new DHCP options.
The procedure will guarantee that: The procedure will guarantee that:
* allocation of new option numbers is coordinated from a single * allocation of new option numbers is coordinated from a single
authority, authority,
* new options are reviewed for technical correctness and * new options are reviewed for technical correctness and
appropriateness, and appropriateness, and
* documentation for new options is complete and published. * documentation for new options is complete and published.
skipping to change at page 2, line 28 skipping to change at page 2, line 28
of numbers for new DHCP options. The new procedure outlined in this of numbers for new DHCP options. The new procedure outlined in this
document will provide guidance to IANA in the assignment of new document will provide guidance to IANA in the assignment of new
option numbers. option numbers.
Overview and background Overview and background
The procedure described in this document modifies and clarifies the The procedure described in this document modifies and clarifies the
procedure for defining new options in RFC 2131 [2]. The primary procedure for defining new options in RFC 2131 [2]. The primary
modification is to the time at which a new DHCP option is assigned an modification is to the time at which a new DHCP option is assigned an
option number. In the procedure described in this document, the option number. In the procedure described in this document, the
option number is not assigned until after the option has been option number is not assigned until specification for the option is
accepted as an Internet Standard and the specification is about to be about to be published as an RFC.
published as an RFC.
DISCUSSION:
Since the publication of RFC 2132, the option number space for Since the publication of RFC 2132, the option number space for
publically defined DHCP options (1-127) has almost been exhausted. publically defined DHCP options (1-127) has almost been exhausted.
Many of the defined option numbers have not been followed up with Many of the defined option numbers have not been followed up with
Internet Drafts submitted to the DHC WG. There has been a lack of Internet Drafts submitted to the DHC WG. There has been a lack of
specific guidance to IANA from the DHC WG as to the assignment of specific guidance to IANA from the DHC WG as to the assignment of
DHCP option numbers DHCP option numbers
The procedure as specified in RFC 2132 does not clearly state that The procedure as specified in RFC 2132 does not clearly state that
new options are to be reviewed individually for acceptance as new options are to be reviewed individually for acceptance as
Internet Standards and that the specifications for newly accepted Internet Standards and that the specifications for newly accepted
Standard options are to be published as separate RFCs. RFC 2132 Standard options are to be published as separate RFCs. RFC 2132 also
also does not require that new options are to be submitted to the does not require that new options are to be submitted to the DHC WG
DHC WG through the WG chair, and that the author of the option through the WG chair, and that the author of the option specification
specification is responsible for bringing new options to the is responsible for bringing new options to the attention of the WG
attention of the WG chair for WG review. Finally, RFC 2132 does chair for WG review. Finally, RFC 2132 does not make clear that
not make clear that newly defined options are not to be newly defined options are not to be incorporated into products,
incorporated into products, included in other specifications or included in other specifications or otherwise used until accepted as
otherwise used until accepted as Internet Standards. Internet Standards.
The Internet Standard DHCP options assigned as of March 1997 are The Internet Standard DHCP options assigned as of March 1997 are
defined in RFC 2132. In the future, new DHCP options will be defined in RFC 2132. In the future, new DHCP options will be
DRAFT Procedure for Defining New DHCP Options August 1998
reviewed individually by the DHC WG and the IETF for acceptance as reviewed individually by the DHC WG and the IETF for acceptance as
Internet Standards and the specifications will be published as Internet Standards and the specifications will be published as
separate RFCs. Groups of related options may be combined into a separate RFCs. Groups of related options may be combined into a
DRAFT Procedure for Defining New DHCP Options September 1998
single specification and reviewed as a set by the DHC WG. Prior to single specification and reviewed as a set by the DHC WG. Prior to
acceptance as an Internet Standard, it is not appropriate to acceptance as an Internet Standard, it is not appropriate to
incorporate new options into products, include the specification in incorporate new options into products, include the specification in
other documents or otherwise make use of the new options. other documents or otherwise make use of the new options.
DISCUSSION:
While the last statement is strong, if it is not included the IETF
may be presented with a "fait accompli" in which a new option is
defined and shipped prior to review by the WG.
The DHCP option number space (1-254) is split into two parts. The The DHCP option number space (1-254) is split into two parts. The
site-specific options (128-254) are defined as "Private Use" and site-specific options (128-254) are defined as "Private Use" and
require no review by the DHC WG. The public options (1-127) are require no review by the DHC WG. The public options (1-127) are
defined as "Specification Required" and new options must be reviewed defined as "Specification Required" and new options must be reviewed
prior to assignment of an option number by IANA. The details of the prior to assignment of an option number by IANA. The details of the
review process are given in the following section of this document. review process are given in the following section of this document.
Procedure Procedure
The author of a new DHCP option will follow these steps to obtain The author of a new DHCP option will follow these steps to obtain
acceptance of the option as a part of the DHCP Internet Standard: acceptance of the option as a part of the DHCP Internet Standard:
1. The author devises the new option. 1. The author devises the new option.
2. The author documents the new option, leaving the option code as 2. The author documents the new option, leaving the option code as
"To Be Determined" (TBD), as an Internet Draft. "To Be Determined" (TBD), as an Internet Draft.
DISCUSSION: The requirement that the new option be documented as an Internet
The requirement that the new option be documented as an Draft is a matter of expediency. In theory, the new option could
Internet Draft is a matter of expediency. In theory, the new be documented on the back of an envelope for submission; as a
option could be documented on the back of an envelope for practical matter, the specification will eventually become an
submission; as a practical matter, the specification will Internet Draft as part of the review process.
eventually become an Internet Draft as part of the review
process.
3. The author submits the Internet Draft for review through the IETF 3. The author submits the Internet Draft for review through the IETF
standards process as defined in "Internet Official Protocol standards process as defined in "Internet Official Protocol
Standards" (STD 1) [4] and "Internet Standards Process" (BCP 9) Standards" (STD 1) [4] and "Internet Standards Process" (BCP 9)
[6]. [6].
DISCUSSION:
Note that simply publishing the new option as an Internet Draft Note that simply publishing the new option as an Internet Draft
does not automatically enter the option into the Standards does not automatically enter the option into the Standards Track.
Track. The author of the new option must explicitly forward a The author of the new option must explicitly forward a request for
action on the new option to the DHC WG or the IESG.
DRAFT Procedure for Defining New DHCP Options August 1998
request for action on the new option to the DHC WG or the IESG.
4. The new option progresses through the IETF standards process. The 4. The new option progresses through the IETF standards process. The
specification of the new option is reviewed by the DHC WG (if it specification of the new option is reviewed by the DHC WG (if it
exists) or by the IETF. The option is considered for acceptance exists) or by the IETF. The option is considered for acceptance
as an Internet Standard. If the option is accepted as a Standard, as an Internet Standard. If the option is accepted as a Standard,
the specification for the option is published as a separate RFC. the specification for the option is published as a separate RFC.
5. At the time of acceptance as an Internet Standard and publication 5. At the time of publication as an RFC, IANA assigns a DHCP option
as an RFC, IANA assigns a DHCP option number to the new option. number to the new option.
DRAFT Procedure for Defining New DHCP Options September 1998
References References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell
University, March 1997. University, March 1997.
[2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, Lachman Associates, March 1997. Extensions", RFC 2132, Lachman Associates, March 1997.
[3] Narten, T. and H. T. Alvestrand, "Guidelines for Writing an IANA [3] Narten, T. and H. T. Alvestrand, "Guidelines for Writing an IANA
skipping to change at page 5, line 5 skipping to change at page 4, line 43
options. The description of security issues in the specification of options. The description of security issues in the specification of
new options must be as accurate as possible. The specification for a new options must be as accurate as possible. The specification for a
new option may reference the "Security Considerations" section in the new option may reference the "Security Considerations" section in the
DHCP specification [1]; e.g. (from "NetWare/IP Domain Name and DHCP specification [1]; e.g. (from "NetWare/IP Domain Name and
Information" [5]): Information" [5]):
DHCP currently provides no authentication or security mechanisms. DHCP currently provides no authentication or security mechanisms.
Potential exposures to attack are discussed in section 7 of the Potential exposures to attack are discussed in section 7 of the
DHCP protocol specification [RFC 2131]. DHCP protocol specification [RFC 2131].
DRAFT Procedure for Defining New DHCP Options August 1998
Author's Address Author's Address
Ralph Droms Ralph Droms
Computer Science Department Computer Science Department
323 Dana Engineering 323 Dana Engineering
Bucknell University Bucknell University
Lewisburg, PA 17837 Lewisburg, PA 17837
Phone: (717) 524-1145 Phone: (717) 524-1145
EMail: droms@bucknell.edu EMail: droms@bucknell.edu
DRAFT Procedure for Defining New DHCP Options September 1998
Expiration Expiration
This document will expire on February 2, 1999. This document will expire on March 31, 1999.
DRAFT Procedure for Defining New DHCP Options August 1998 DRAFT Procedure for Defining New DHCP Options September 1998
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/