Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt-00

From: Ralph Droms <[email-masked]>
Date: Mon, 05 Apr 2004 07:41:00 -0500

This message announces a WG last call on "Rapid Commit Option for DHCPv4"
<draft-ietf-dhc-rapid-commit-opt-00>.  The last call will conclude at 5PM
EST on 4/15/04.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.

draft-ietf-dhc-rapid-commit-opt-00 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.  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-rapid-commit-opt-00.txt

- Ralph Droms 

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

---

From: Ralph Droms <[email-masked]>
Date: Thu, 08 Apr 2004 09:20:45 -0400

I see that this draft includes a notice regarding IPR.  The Samsung IPR
statement appears to apply across all IETF submissions.  Can the authors
clarify if there are any IPR claims that apply specifically to this document?

The format of the option - specifically, option length == 0 - is consistent
with other DHCP options.  Will length 0 cause problems in practice with
deployed DHCP servers?

The document should be republished to include RFC 3667 boilerplate,
including the RFC 3667 IPR notification statement.

I have one editorial comment: the document should indicate that the use of
Rapid Commit is optional on the part of the client, under local (client)
admin control.  In section 3, I suggest changing the first sentence:

      A client that supports the Rapid Commit option SHOULD include it in
      DHCPDISCOVER messages that it sends.

to:

      If a client that supports the Rapid Commit option intends to use
      the rapid commit capability, it includes a Rapid Commit option in
      DHCPDISCOVER messages that it sends.

In section 3.1, list item 1, I suggest changing the first sentence:

         1. The client broadcasts a DHCPDISCOVER message on its local
            physical subnet and  SHOULD include the Rapid Commit option if
            it supports this option.

to:

         1. The client broadcasts a DHCPDISCOVER message on its local
            physical.  If the client supports the Rapid Commit option
            and intends to use the rapid commit capability, it includes
            a Rapid Commit option in the DHCPDISCOVER message.

---

From: "S. Daniel Park" <[email-masked]>
Date: Sat, 10 Apr 2004 09:13:26 +0900

Ralph, thanks your editorial comments on 
this draft and as Bernie indicated, I will also 
wait for additional comments during the WGLC.

Regarding IPR comment, I have no any hard
stance. Anyway I will also show a concrete
statement on that after WGLC.

- Daniel (Soohong Daniel Park)
- Mobile Platform Laboratory, SAMSUNG Electronics. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ralph Droms
> Sent: Thursday, April 08, 2004 10:21 PM
> To: [email-masked]
> Subject: Re: [dhcwg] dhc WG last call on 
> draft-ietf-dhc-rapid-commit-opt-00
> 
>