DHCPv6 Failover Requirements
Note: This ballot was opened for revision 06 and is now closed.
(Ted Lemon; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Benoît Claise; former steering group member) (was Discuss) No Objection
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.
(Brian Haberman; former steering group member) No Objection
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?
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) (was Discuss) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Richard Barnes; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) (was Discuss) No Objection
Thanks for handling my discuss points. S.
(Stewart Bryant; former steering group member) No Objection