Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-vendor-02.txt

From: [email-masked]
Date: Tue, 18 May 2004 15:32:38 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: Vendor-Identifying Vendor Options for DHCPv4
	Author(s)	: J. Littlefield
	Filename	: draft-ietf-dhc-vendor-02.txt
	Pages		: 9
	Date		: 2004-5-18
	
The DHCP options for Vendor Class and Vendor-Specific Information can
be ambiguous when a DHCP client represents multiple vendors.  This
document defines two new options, modeled on the IPv6 options for
vendor class and vendor-specific information, which contain
Enterprise Numbers to remove ambiguity.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-vendor-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-vendor-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-vendor-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Richard Barr Hibbs" <[email-masked]>
Date: Tue, 18 May 2004 17:54:04 -0700

Josh--

here's an excerpt from section 3:

   "This option contains information corresponding to one or
more
   Enterprise Numbers.  Multiple instances of this option
may be
   present, and MUST be concatenated in accordance with RFC
3396 [4].
   An Enterprise Number SHOULD only occur once among all
instances of
   this option.  Behavior is undefined if an Enterprise
Number occurs
   multiple times.  The information for each Enterprise
Number is
   treated independently, regardless or whether it occurs in
an option
   with other Enterprise Numbers, or in a separate option."

While I agree that it is very difficult to specify
appropriate behavior of the server if a client sends
[apparently] ambiguous data (i.e., multiple instances of an
Enterprise Number), I'm becoming less and less favorably
disposed towards protocol behavior that is undefined or
implementation-dependent.  I'd prefer to see something like
the following:

   "An Enterprise Number MUST only occur once among all
instances of this
   option.  If an Enterprise Number occurs more than once,
despite this
   restriction, a DHCPv4 server SHOULD process only the LAST
instance."

I suggest this wording because I believe that the MUST is
what you really intend in this section, and the second
proposed sentence specifies what would happen if a client
violates the restriction.

I'm open to suggestions and other opinions about this,
however.

--Barr

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg