< draft-ietf-dhc-new-opt-msg-01.txt		draft-ietf-dhc-new-opt-msg-02.txt >
	Network Working Group R. Droms		Network Working Group R. Droms
	INTERNET-DRAFT Bucknell University		INTERNET-DRAFT Bucknell University
	Obsoletes: draft-ietf-dhc-new-opt-msg-00.txt June 2000		Obsoletes: draft-ietf-dhc-new-opt-msg-01.txt July 2000
	Expires December 2000		Expires December 2000
	Procedure for Defining New DHCP Options and Message Types		Procedures and IANA Guidelines for Definition of
	<draft-ietf-dhc-new-opt-msg-01.txt>		New DHCP Options and Message Types
			<draft-ietf-dhc-new-opt-msg-02.txt>
	Status of this memo		Status of this memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026. Internet-Drafts are working		all provisions of Section 10 of RFC2026. 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
	skipping to change at page 1, line 47 ¶		skipping to change at page 2, line 4 ¶
	option (option code 51). Each message type is defined by the data		option (option code 51). Each message type is defined by the data
	value carried in the 'DHCP Message Type' option.		value carried in the 'DHCP Message Type' option.
	New DHCP options and message types may be defined after the		New DHCP options and message types may be defined after the
	publication of the DHCP specification to accommodate requirements for		publication of the DHCP specification to accommodate requirements for
	conveyance of new configuration parameters or to accommodate new		conveyance of new configuration parameters or to accommodate new
	protocol semantics. This document describes the procedure for		protocol semantics. This document describes the procedure for
	defining new DHCP options and message types.		defining new DHCP options and message types.
	1. Introduction		1. Introduction
			DRAFT Procedures for New DHCP Options and Message Types July, 2000
	The Dynamic Host Configuration Protocol (DHCP) [1] provides a		The Dynamic Host Configuration Protocol (DHCP) [1] provides a
	DRAFT Defining New DHCP Options and Message Types June, 2000
	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]
	DHCP protocol messages are identified by the 'DHCP Message Type'		DHCP protocol messages are identified by the 'DHCP Message Type'
	option (option code 51). Each message type is defined by the data		option (option code 51). Each message type is defined by the data
	value carried in the 'DHCP Message Type' option.		value carried in the 'DHCP Message Type' option.
	skipping to change at page 2, line 33 ¶		skipping to change at page 2, line 33 ¶
	correctness and appropriateness, and		correctness and appropriateness, and
	* documentation for new options and message types is complete and		* documentation for new options and message types is complete and
	published.		published.
	As indicated in "Guidelines for Writing an IANA Considerations		As indicated in "Guidelines for Writing an IANA Considerations
	Section in RFCs" (see references), IANA acts as a central authority		Section in RFCs" (see references), IANA acts as a central authority
	for assignment of numbers such as DHCP option and message type codes.		for assignment of numbers such as DHCP option and message type codes.
	The new procedure outlined in this document will provide guidance to		The new procedure outlined in this document will provide guidance to
	IANA in the assignment of new option and message type codes.		IANA in the assignment of new option and message type codes.
			This document updates and replaces RFC 2489.
	2. Overview and background		2. Overview and background
	This document specifies procedures for defining new option codes and		This document specifies procedures for defining new option codes and
	message types.		message types.
	2.1 New DHCP option codes		2.1 New DHCP option codes
	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 specification for the option is		option number is not assigned until specification for the option is
	about to be published as an RFC.		about to be published as an RFC.
	Since the publication of RFC 2132, the option number space for		Since the publication of RFC 2132, the option number space for
	publicly defined DHCP options (1-127) has almost been exhausted.		publicly 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
	The procedure as specified in RFC 2132 does not clearly state that		DRAFT Procedures for New DHCP Options and Message Types July, 2000
	DRAFT Defining New DHCP Options and Message Types June, 2000		DHCP option numbers.
			The procedure as specified in RFC 2132 does not clearly state that
	new options are to be reviewed individually for technical		new options are to be reviewed individually for technical
	correctness, appropriateness and complete documentation. RFC 2132		correctness, appropriateness and complete documentation. RFC 2132
	also does not require that new options are to be submitted to the		also does not require that new options are to be submitted to the
	IESG for review, and that the author of the option specification is		IESG for review, and that the author of the option specification is
	responsible for bringing new options to the attention of the IESG.		responsible for bringing new options to the attention of the IESG.
	Finally, RFC 2132 does not make clear that newly defined options are		Finally, RFC 2132 does not make clear that newly defined options are
	not to be incorporated into products, included in other		not to be incorporated into products, included in other
	specifications or otherwise used until the specification for the		specifications or otherwise used until the specification for the
	option is published as an RFC.		option is published as an RFC.
	skipping to change at page 3, line 32 ¶		skipping to change at page 3, line 35 ¶
	relevant Working Group if one exists). Groups of related options may		relevant Working Group if one exists). Groups of related options may
	be combined into a single specification and reviewed as a set by the		be combined into a single specification and reviewed as a set by the
	IESG. Prior to assignment of an option code, it is not appropriate		IESG. Prior to assignment of an option code, it is not appropriate
	to incorporate new options into products, include the specification		to incorporate new options into products, include the specification
	in other documents or otherwise make use of the new options.		in other documents or otherwise make use of the new options.
	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 option codes [2] (128-254) are defined as "Private Use"		site-specific option codes [2] (128-254) are defined as "Private Use"
	and require no review by the DHC WG. Site-specific options codes		and require no review by the DHC WG. Site-specific options codes
	(128-254) MUST NOT be defined for use by any publicly distributed		(128-254) MUST NOT be defined for use by any publicly distributed
	DHCP server or client implementations. These option codes are		DHCP server, client or relay agent implementations. These option
	explicitly reserved for private definition and use within a site or		codes are explicitly reserved for private definition and use within a
	an organization.		site or an organization.
	The public option codes (0-127, 255) are defined as "Specification		The public option codes (0-127, 255) are defined as "Specification
	Required" and new options must be reviewed prior to assignment of an		Required" and new options must be reviewed prior to assignment of an
	option number by IANA. The details of the review process are given		option number by IANA. The details of the review process are given
	in the following section of this document.		in the following section of this document.
	2.2 New DHCP message types		2.2 New DHCP message types
	RFC2131 does not specify any mechanism for defining new DHCP message		RFC2131 does not specify any mechanism for defining new DHCP message
	types. In the future, new DHCP message types will be documented in		types. In the future, new DHCP message types will be documented in
	RFCs approved by the IESG, and the codes for these new message types		RFCs approved by the IESG, and the codes for these new message types
	will be assigned at the time the relevant RFCs are published.		will be assigned at the time the relevant RFCs are published.
	Typically, the IESG will seek input on new message types from		Typically, the IESG will seek input on new message types from
	appropriate sources (e.g., a relevant Working Group if one exists).		appropriate sources (e.g., a relevant Working Group if one exists).
	Prior to assignment of a message type code, it is not appropriate to		Prior to assignment of a message type code, it is not appropriate to
	incorporate new message types into products, include the		incorporate new message types into products, include the
	specification in other documents or otherwise make use of the new
	message types.
	DRAFT Defining New DHCP Options and Message Types June, 2000		DRAFT Procedures for New DHCP Options and Message Types July, 2000
	When the DHC WG has defined a procedure for the consideration and		specification in other documents or otherwise make use of the new
	review of changes to the DHCP specification that include the		message types.
	definition of new message types, that procedure will be followed
	prior to the acceptance of any new message types and the publication
	of the specification of those message types in RFCs.
	3. Procedure		3. Procedure
	The author of a new DHCP option or message type will follow these		The author of a new DHCP option or message type will follow these
	steps to obtain approval for the option and publication of the		steps to obtain approval for the option and publication of the
	specification of the option as an RFC:		specification of the option as an RFC:
	1. The author devises the new option or message type.		1. The author devises the new option or message type.
	2. The author documents the new option or message type, leaving the		2. The author documents the new option or message type, leaving the
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	the IESG. The specification is reviewed by the DHC WG (if it		the IESG. The specification is reviewed by the DHC WG (if it
	exists) or by the IETF. If the option or message type is accepted		exists) or by the IETF. If the option or message type is accepted
	for inclusion in the DHCP specification, the specification of the		for inclusion in the DHCP specification, the specification of the
	option or message type is published as an RFC. It may be		option or message type is published as an RFC. It may be
	published as either a standards-track or a non-standards-track		published as either a standards-track or a non-standards-track
	RFC.		RFC.
	5. At the time of publication as an RFC, IANA assigns a DHCP option		5. At the time of publication as an RFC, IANA assigns a DHCP option
	code or message type code to the new option or message type.		code or message type code to the new option or message type.
	DRAFT Defining New DHCP Options and Message Types June, 2000		DRAFT Procedures for New DHCP Options and Message Types July, 2000
	4. References		4. 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] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information", RFC		[3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information", RFC
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 5 ¶
	specification of new options or message types must be as accurate as		specification of new options or message types must be as accurate as
	possible. The specification for a new option or message type may		possible. The specification for a new option or message type may
	reference the "Security Considerations" section in the DHCP		reference the "Security Considerations" section in the DHCP
	specification [1]; e.g. (from "NetWare/IP Domain Name and		specification [1]; e.g. (from "NetWare/IP Domain Name and
	Information" [3]):		Information" [3]):
	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 Defining New DHCP Options and Message Types June, 2000		DRAFT Procedures for New DHCP Options and Message Types July, 2000
	7. IANA Considerations		7. IANA Considerations
	RFC 2132 provided guidance to the IANA on the procedure it should		RFC 2132 and RFC 2489 provided guidance to the IANA on the procedure
	follow when assigning option numbers for new DHCP options or message		it should follow when assigning option numbers for new DHCP options
	types. This document updates and replaces those instructions. In		or message types. This document updates and replaces those
	particular, IANA is requested to assign DHCP option codes or message		instructions. In particular, IANA is requested to assign DHCP option
	type codes only for options or message types that have been approved		codes or message type codes only for options or message types that
	for publication as RFCs; i.e., documents that have been approved		have been approved for publication as RFCs; i.e., documents that have
	through "IETF consensus" as defined in RFC 2434 [4].		been approved through "IETF consensus" as defined in RFC 2434 [4].
	8. Author's Address		8. 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: 570) 524-1145		Phone: (570) 524-1145
	EMail: droms@bucknell.edu		EMail: droms@bucknell.edu
	9. Expiration		9. Expiration
	This document will expire on December 31, 2000.		This document will expire on December 31, 2000.
	DRAFT Defining New DHCP Options and Message Types June, 2000		DRAFT Procedures for New DHCP Options and Message Types July, 2000
	10. Full Copyright Statement		10. Full Copyright Statement
	Copyright (C) The Internet Society (2000). All Rights Reserved.		Copyright (C) The Internet Society (2000). 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. 18 change blocks.
	31 lines changed or deleted		27 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/