[Ballot comment]
This draft seems harmless, but I confess that I don't see the point -- both parties are supposed to check if the address is already in use via a timeout-based mechanism, and I'd think that that would take longer than an extra round trip.

[Ballot comment]
I do wonder about whether saving these 2 messages will really save any time.

Reviewed by Spencer Dawkins, Gen-ART

His review:

I'm reviewing this specification as a Working Group Submission for
Proposed Standard.

This document is mostly ready to go. I didn't even see nits. It's
well-written and explains its motivation clearly.

I have one comment - the example given in Figure 1 shows what happens
when you have two DHCP servers on a subnet, but only one of them
supports Rapid Commit. It would be really nice to have a second short
discussion that shows the same flow when both servers support Rapid
Commit. I THINK I know what's supposed to happen, based on side
comments in the discussion of Figure 1, and I even think that what's
supposed to happen would actually work, but it would be clearer if
this was broken out separately.

This is a nice short document, so I'll be a good sport and point out
that it makes sense to delete the discussion of "one server on a
subnet".

The discussion on "one server on a subnet" in this draft seems to be
skating along the edge of "wireless topology = IP subnet topology",
and this isn't true in the general case, except by accident. If
there's any part of this solution that relies on "one server on a
subnet", that's bad, because it will break the second you have
multipath reflection from another subnet, and it will also break the
second someone plugs in another router without wondering if there's
already a Rapid Commit router plugged in.

I don't THINK this will happen, but that's because the protocol
specified is safe whether or not the router is the only one on the
subnet or not.

IANA Last Call Comments: We understand upon approval of this document the IANA will assign a DHCPv4 option code for Rapid Commit.  This assignment will occur in the DHCP Options registry found at the following: <http://www.iana.org/assignments/bootp-dhcp-parameters>

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes and yes.

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

Yes and no.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

No.

4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

No.

5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

WG as a whole understands and agrees with the spec; this spec is an
adaptation of a feature in DHCPv6 back to DHCPv4.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

No.

7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes.

8) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary

This specification defines a new mechanism for DHCPv4, modeled on the
DHCPv6 Rapid Commit option and mechanism, for obtaining IP address and
configuration information using a 2 message exchange instead of the
usual 4 message exchange.

  - Working Group Summary

There was consensus in the WG for approval of the DHCPv4 rapid commit
option and associated mechanism.  It has been thoroughly reviewed by
the dhc WG and discussed in WG meetings and on the dhcwg mailing
list.  Samsung has published an IPR claim, in which it promises to
provide zero-cost licensing, related to this specification.

  - Protocol Quality

This extension to the DHCPv4 protocol and its specification is of high
quality and had been thoroughly reviewed by the dhc WG.  Several
vendors have expressed interest in implementing this extension to
DHCPv4.