As per Relevance of the word procedure, we have this rfc below:
Network Working Group R.
Request for Comments: 2489 Bucknell
BCP: 29 January 1999
Category: Best Current
Procedure for Defining New DHCP
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
The Dynamic Host Configuration Protocol (DHCP) provides a
for passing configuration information to hosts on a TCP/IP network
Configuration parameters and other control information are carried
tagged data items that are stored in the 'options' field of the
message. The data items themselves are also called "options."
New DHCP options may be defined after the publication of the
specification to accommodate requirements for conveyance of
configuration parameters. This document describes the procedure
defining new DHCP options
1.
The Dynamic Host Configuration Protocol (DHCP) [1] provides
framework for passing configuration information to hosts on a TCP/
network. Configuration parameters and other control information
carried in tagged data items that are stored in the 'options'
of the DHCP message. The data items themselves are also
"options." [2]
This document describes the procedure for defining new DHCP options
The procedure will guarantee that
* allocation of new option numbers is coordinated from a
authority
* new options are reviewed for technical correctness
appropriateness,
* documentation for new options is complete and published
Droms Best Current Practice [Page 1]
RFC 2489 Defining New DCHP Options January 1999
As indicated in "Guidelines for Writing an IANA
Section in RFCs" (see references), IANA acts as a central
for assignment of numbers such as DHCP option codes. The
procedure outlined in this document will provide guidance to IANA
the assignment of new option codes
2. Overview and
The procedure described in this document modifies and clarifies
procedure for defining new options in RFC 2131 [2]. The
modification is to the time at which a new DHCP option is assigned
option number. In the procedure described in this document,
option number is not assigned until specification for the option
about to be published as an RFC
Since the publication of RFC 2132, the option number space
publically defined DHCP options (1-127) has almost been exhausted
Many of the defined option numbers have not been followed up
Internet Drafts submitted to the DHC WG. There has been a lack
specific guidance to IANA from the DHC WG as to the assignment
DHCP option
The procedure as specified in RFC 2132 does not clearly state
new options are to be reviewed individually for
correctness, appropriateness and complete documentation. RFC 2132
also does not require that new options are to be submitted to
IESG for review, and that the author of the option specification
responsible for bringing new options to the attention of the IESG
Finally, RFC 2132 does not make clear that newly defined options
not to be incorporated into products, included in
specifications or otherwise used until the specification for
option is published as an RFC
In the future, new DHCP option codes will be assigned by
consensus. New DHCP options will be documented in RFCs approved
the IESG, and the codes for those options will be assigned at
time the relevant RFCs are published. Typically, the IESG will
input on prospective assignments from appropriate sources (e.g.,
relevant Working Group if one exists). Groups of related options
be combined into a single specification and reviewed as a set by
IESG. Prior to assignment of an option code, it is not
to incorporate new options into products, include the
in other documents or otherwise make use of the new options
The DHCP option number space (1-254) is split into two parts.
site-specific options (128-254) are defined as "Private Use"
require no review by the DHC WG. The public options (1-127)
Droms Best Current Practice [Page 2]
RFC 2489 Defining New DCHP Options January 1999
defined as "Specification Required" and new options must be
prior to assignment of an option number by IANA. The details of
review process are given in the following section of this document
3.
The author of a new DHCP option will follow these steps to
approval for the option and publication of the specification of
option as an RFC
1. The author devises the new option
2. The author documents the new option, leaving the option code
"To Be Determined" (TBD), as an Internet Draft
The requirement that the new option be documented as an
Draft is a matter of expediency. In theory, the new option
be documented on the back of an envelope for submission; as
practical matter, the specification will eventually become
Internet Draft as part of the review process
3. The author submits the Internet Draft for review by the IESG
Preferably, the author will submit the Internet Draft to the
Working Group, but the author may choose to submit the
Draft directly to the IESG
Note that simply publishing the new option as an Internet
does not automatically bring the option to the attention of
IESG. The author of the new option must explicitly forward
request for action on the new option to the DHC WG or the IESG
4. The specification of the new option is reviewed by the IESG.
specification is reviewed by the DHC WG (if it exists) or by
IETF. If the option is accepted for inclusion in the
specification, the specification of the option is published as
RFC. It may be published as either a standards-track or a non
standards-track RFC
5. At the time of publication as an RFC, IANA assigns a DHCP
number to the new option
4.
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[2] Alexander, S. and R. Droms, "DHCP Options and BOOTP
Extensions", RFC 2132, March 1997.
Droms Best Current Practice [Page 3]
RFC 2489 Defining New DCHP Options January 1999
[3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information",
RFC 2142, November 1997.
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
5. Security
Information that creates or updates an option number assignment
to be authenticated
An analysis of security issues is required for all newly defined
options. The description of security issues in the specification
new options must be as accurate as possible. The specification for
new option may reference the "Security Considerations" section in
DHCP specification [1]; e.g. (from "NetWare/IP Domain Name
Information" [3]):
DHCP currently provides no authentication or security mechanisms
Potential exposures to attack are discussed in section 7 of
DHCP protocol specification [RFC 2131].
6. IANA
RFC 2132 provided guidance to the IANA on the procedure it
follow when assigning option numbers for new DHCP options.
document updates and replaces those instructions. In particular
IANA is requested to assign DHCP option numbers only for options
have been approved for publication as RFCs; i.e., documents that
been approved through "IETF consensus" as defined in RFC 2434 [4].
7. Author's
Ralph
Computer Science
323 Dana
Bucknell
Lewisburg, PA 17837
Phone: (717) 524-1145
EMail: droms@bucknell.
Droms Best Current Practice [Page 4]
RFC 2489 Defining New DCHP Options January 1999
8. Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Droms Best Current Practice [Page 5]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
