DHCPv6 Failover Requirements
draft-ietf-dhc-dhcpv6-failover-requirements-07

My DISCUSS was:
This DISCUSS resolution might be a simple as educating a clueless AD, having a forward pointer (from the intro to section 6), reorganizing the sections, or clearly explaining what is specific to DHCPv6 versus common to DHCPv4/DHCPv6.
 "Why are these requirementis specific to DHCPv6?" I asked myself while reading this document.
All of section 3, 4, and 5 (except maybe 4.5 and 4.6) is common for IPv4 and IPv6, right?
It's only when I arrived at section 6 that I somehow understood. I should have paid more attention to the table of content. Proposal: the introduction could introduce a sentence or two, with a forward reference to section 6.
However, I was wondering "There is surely a RFC for DHCPv4 failover!", but I could not find anything, except an old draft http://tools.ietf.org/html/draft-ietf-dhc-failover-12.
Slightly confused, should be missing something ...

I cleared my DISCUSS on the basis that the following text is in.

       The DHCPv6 failover concept borrows heavily from its DHCPv4
       counterpart [dhcpv4-failover] that never completed standardization
       process, but has several successful, operationally proven vendor-
       specific implementations. For a discussion about commonalities and
       differences, see Section 6.

What would be very nice (more of a COMMENT type of feedback) is to label which sections/requirements are specific to IPv6.

- Question: have you been thinking about all operational questions/requirements from RFC 5706 appendix A?

-
      A binding (or client binding) is a group of server data records
      containing the information the server has about the addresses in
      an IA or configuration information explicitly assigned to the
      client. 

What is "an IA"?

-  "A notable example is a PXE scenario where hosts require an address during boot."
No idea what a PXE scenario is

- in order to match the statement

 2.   For each prefix or address pool, a server must not participate
        in more than one failover relationship.

I believe you want
OLD:
   4.  Servers participating in multiple failover relationships for any
       given pool.

NEW:
   4.  Servers participating in multiple failover relationships for any
       given prefix or address pool.

I have no issues with the publication of this document.  I do have some comments that I think will make it stronger.

1. There are instances of acronyms without expansion on the first use (e.g., PXE).

2. The models described in sections 4.1 & 4.2 talk about two servers remaining in contact with one another.  I assume this is through messages outside of DHCP.  If that is the case, it may be worthwhile to explicitly state that.

3. For completeness, are there scenarios that would involve cold (or warm) standby servers?

4. The discussion in 5.2.2 misses a key point.  Lazy updates paired with Split Prefixes can be very efficient since there is little risk in overlapping assignments.

5. I find the wording in section 7, a little distressing.  This document is just "an attempt to define requirements"?

6. Requirement 1 in section 7 is confusing for several reasons.  The first sentence makes it sound like a DHCP server can have 2 failover partners.  The next sentence says that a particular resource is protected by a pair-wise relationship between two servers.  I don't understand the rationale for limiting the number of failover partners in a requirements statement.  Additionally, this requirement is confusing given that section 4.4. talked about having m-to-m failover relationships.

7. It is unclear why section 7.1 is in this document.  The requirements in section 7 describe the *minimum* set of functionality that has to be in the protocol.  Why rule out other functionality?

Thanks for handling my discuss points.

S.