Document: draft-ietf-dhc-rapid-commit-opt-05.txt
From: Spencer Dawkins
Date: 25 oktober 2004 

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.