Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-rapid-commit-opt-02.txt

From: [email-masked]
Date: Tue, 20 Apr 2004 10:55:01 -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		: Rapid Commit Option for DHCPv4
	Author(s)	: P. Kim, et al. 
	Filename	: draft-ietf-dhc-rapid-commit-opt-02.txt
	Pages		: 11
	Date		: 2004-4-19
	
This document defines a new DHCPv4 option, modeled on the DHCPv6      
Rapid Commit option, for obtaining IP address and configuration      
information using a 2-message exchange rather than the usual 4-
message exchange, expediting client configuration.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-rapid-commit-opt-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-rapid-commit-opt-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-rapid-commit-opt-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: "Kostur, Andre" <[email-masked]>
Date: Tue, 20 Apr 2004 22:59:35 -0700

> From: S. Daniel Park [mailto:[email-masked]]
> Sent: Tuesday, April 20, 2004 10:13 PM
> To: 'Kostur, Andre'; [email-masked]
> Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-rapid-commit-opt-02.txt
>  
> Thanks Kostur and see my inline comments.
> 
> >The second step talks about using the client identifier or chaddr 
> >plus assigned network address as the identifier for the lease.  
> >I believe this puts it in conflict with RFC 2131 (which talks about
> using
> >a subnet address, not necessarily the address of the lease), and 
> >RFC 3046 which adds in the Remote ID.  I believe that this 
> draft should
> 
> >probably reference RFC 3046 on this topic.
> 
> I am not sure why it occurs confliction with RFC2131.

Maybe "conflict" is too strong of a word...

I guess to me specifying the lease address implies that a unique identifier
(ClientID/CHADDR + RemoteID) may have multiple leases on the same subnet.
By specifying a subnet address instead, this implies that a unique
identifier may have only one lease on a subnet.  If a client wished to have
multiple leases on the same subnet, then it would need to mutate it's client
ID, and thus effectively becoming a distinct client (from the DHCP server's
point of view).

> >Section 4: 
> >This states that a client SHOULD include this option in a discover if
> it's 
> >prepared to perform the DISCOVER-ACK exchange.  Shouldn't that be 
> >a MUST since there is that if clause at the end?
> 
> I thought MUST is too hard, but I have no hard stance to replace it
> if we agree that.

I think that SHOULD is too loose in this case.  The statement is modified by
saying "if the device is prepared to perform the DISCOVER-ACK exchange".
With a SHOULD this would imply that the device may be prepared to perform
the DISCOVER-ACK exchange, but isn't required to supply the Rapid Commit
option.  Which would lead to the question of how else would the device
inform the server that it is prepared to do Rapid Commit?