Skip to main content

DHCPv4 Vendor-specific Message
draft-ietf-dhc-dhcpv4-vendor-message-01

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    dhc mailing list <dhcwg@ietf.org>, 
    dhc chair <dhc-chairs@tools.ietf.org>
Subject: Protocol Action: 'DHCPv4 Vendor-specific Message' to Proposed
Standard

The IESG has approved the following document:

- 'DHCPv4 Vendor-specific Message '
   <draft-ietf-dhc-dhcpv4-vendor-message-01.txt> as a Proposed Standard


This document is the product of the Dynamic Host Configuration Working
Group. 

The IESG contact persons are Ralph Droms and Jari Arkko.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv4-vendor-message-01.txt

Ballot Text

Technical Summary

	This document provides a standard mechanism for defining
	experimental messages in the DHCPv4 protocol.

Working Group Summary

	Standard DHCPv4 message codes are allocated by the IANA
	and require working group approval.   The current IANA
	procedure for message type code allocation requires that a
	document pass a working group last call before a code
	can be allocated.   Current practice among implementors of
	new or experimental DHCP messages is to simply bypass the
	IANA process and allocate a code.   Because this document
	provides a clear alternative, the working group hopes that
	no new DHCPv4 message type codes will be pirated by
	experimenters.

	One concern that was raised was that by providing an
	unreviewed mechanism for allocating new DHCP message types,
	implementors would have less of an incentive for consulting
	the working group when developing new DHCP messages.
	However, our experience has been that the people least likely
	to consult the working group are the same people who would
	feel free to simply make up a number and not tell anyone
	until a collision arises.   Hence, this mechanism is seen
	even by those who raised this objection as the lesser of
	two evils.

Document Quality

	The document has already been used for an implementation
	of an experimental authentication protocol at Cisco; the
	protocol in question is under consideration for
	standardization by the DHC working group.

Personnel

        The document shepherd is Ted Lemon <mellon@nominum.com>.  The
        responsible A-D is Ralph Droms.

RFC Editor Note

  (Insert RFC Editor Note here or remove section)

IRTF Note

  (Insert IRTF Note here or remove section)

IESG Note

  (Insert IESG Note here or remove section)

IANA Note

  (Insert IANA Note here or remove section)

RFC Editor Note