DHCPv6 Redundancy Deployment Considerations
draft-ietf-dhc-dhcpv6-redundancy-consider-03

I have no objection to the publication of this document that I found
readable.

The document title speaks of "redundancy" but the document is scoped to
"semi-redundant services" and makes a point of stressing how DHCPv6 does
not offer a redundancy protocol. It might be helpful to tune the title 
to match the document.

Nicely written. Thanks;
Minor editorial comments: please expand DUID  and PD

Regards, Benoit

I have a few comments/questions on this draft, all of which are non-blocking.

1. I lied.  I won't be sending along a list of editorial issues... There are a ton of linguistic/editorial issues that I don't have time to itemize.  I strongly suggest an editorial pass through this document by another WG participant to clean this up.

2. In bullet #3 of section 2, the second part talks about getting configuration information or options.  Is this information obtained via Stateful DHCPv6, Stateless DHCPv6, or a combination of the two?

3. I cannot cleanly parse the first sentence of bullet #4 in section 2.

4. Does the last paragraph of section 2 really refer to a DHCPv6 *redundancy* protocol being published?

5. Section 2.2 says that end-hosts will not use DHCP prefix delegation.  Do you have considerations to offer for when they do make such requests?

6. This question may be due to a hole in my knowledge of DHCPv6, but iss there really any difference in the two scenarios described in sections 4.1 and 4.2, other than a possible difference in the prefix length?

7. In section 5, bullet #1 discusses the need for each DHCPv6 server to use the same allocation algorithm to ensure that each IPv6 address is only allocated to a single client.  Does this require every DHCPv6 server to see all requests?  If so, would that be feasible in the two target deployment scenarios?

- There are too many places where the spelling isn't correct, i.e., some native reader should proof read it! 
- I'm not sure how useful this document is for network operators, but if the WG is fine with the draft, I won't object.
The draft did not add much for me on how to configure DHCPv6 servers to have some level of redundancy.

I don't object to publishing this document as BCP (so this is not a DISCUSS), but I would like to hear why this intended status was chosen over Informational. The document says it does not address a standards based solution (so it's not the kind of document described in the first paragraph of section 5.1 of RFC2026). It's not setting policy or defining the operation of an IETF function. It seems instead to say "here's a way you can do this thing, and here are some things to consider if you choose to do it". That really seems like an Informational document. What's in here that makes Informational the wrong choice? (Please consider paragraph four of section 5.1 in RFC2026 when answering that.)

Thinking forward, publishing this as BCP may make work harder for the IETF if/when it does produce a standard mechanism to address this problem.

  Please consider the editorial comments from the Gen-ART Review by
  Pete McCann on 24-Apr-2012.  The review can be found at:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07389.html

Thanks for the exensive editorial work.