I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dhc-dhcpv6-failover-requirements-06.txt Reviewer: Elwyn Davies Review Date: 6 July 2013 IETF LC End Date: 17 July 2013 IESG Telechat date: (if known) - Summary: Almost ready. There are a few very minor issues and a fair number of editorial nits to fix but generally in good shape. Major issues: None Minor issues: s1, Introduction of Primary/Secondary terminology: The introduction talks about multiple servers (i.e., potentially > 2) but then in the last sentence of para 1 introduces primary and secondary servers. The initial impression this gives is that the number of servers has now been reduced to <= 2. Having read through the rest of the document I can see how I am supposed to interpret the last sentence of para 1, but things would be much clearer if an extra sentence or three describing the chosen model (and its intended extension) was added just before this last sentence. Maybe something like: The failover model, to which these requirements apply, will initially be a pairwise "hot standby" model (see Section 4.1) with a primary server used in normal operation switching over to a backup secondary server in the event of failure. Optionally, a secondary server may provide failover service for multiple primary servers. However the requirements will not preclude a future load-balancing extension where there is a symmetric failover relationship. s7: Related to the previous comment, perhaps it should be made explicit that the resulting protocol is "load-balancing friendly" to avoid rework if at all possible. Since both v4 and v6 load-balancing and v4 failover with load-balancing are in progress, it should be known how to avoid pitfalls by the time the v6 failover protocol is designed! s7, item 4, last sentence: "Long-lived connections must not be disturbed." I don't believe the DHCPv6 server or the failover protocol can either know that an address is in use for long lived connections or guarantee that they won't be disturbed beyond what is said earlier in this item. Presumably what is meant is something like: "Lease stability has the aim of avoiding disturbance to long-lived connections." s7, item 6: Maybe irrelevant thought: Presumably you could build a failover system using a shared, reliable database and a minimalistic version of the failover protocol instead of using lazy updates. Should this be explicitly an option? s7, last para: "Despite the lack of standardization of DHCPv4 failover...": It appears that work is in progress on this (http://tools.ietf.org/html/draft-ietf-dhc-failover-12)... so what is meant here? Nits/editorial comments: Global: s/i.e./i.e.,/ Global: s/e.g./e.g.,/ Abstract: s/any way/any way that/ s2: Expoand acronyms CPR, IA - even though IA is defined in RFC 3315, it would help readability to repeat the expansion. s2, lease: Should this mention something about length of time for which the lease will be valid? s3.1.1: Expand PXE acronym. s3.1.1, para 1: OLD Address and possibly other configuration parameters are used during boot process and are discarded afterwards. NEW: The address and possibly other configuration parameters are used during the boot process and are discarded thereafter. s3.1.1, para 2: s/distinct preference set/a distinct preference set/ s3.1.2, para 2: OLD: There are several well documented approaches how such deployment works. NEW: There are several well-documented approaches showing how such a deployment could work. s3.1.3, para 2: OLD: It is also essential to use only databases that are really distributed and do not have single point of failure themselves. NEW: It is also essential to use only a database system that provides equivalent reliability and failover capability. s4: This paragraph implies that the document defines a protocol contrary to its expressed intention and reality. OLD: These scenarios may be inside or outside of scope for DHCPv6 failover protocol as defined by this document. They are enumerated here to provide a common basis for discussion. NEW: These scenarios may be in or out of scope for the DHCPv6 failover model to which this document's requirements apply; they are enumerated here to provide a common basis for discussion. s5, para 2: s/General failover concept/The general failover concept/, s/in case of the primary server/in case of a primary server/, s/In case of just/In the case of just/, s/Had there be more than two partners/Were there more than two partners/ (subjunctive!) s5, para 2: OLD: there would be a third states in between (some partners updated their state, but some didn't). NEW: there would be intermediate, inconsistent states where some partners had updated their state and some had not. s4.1: s/Only one of partners/Only one of the partners/ s4.6, para 2: s/every time IPv6 address changes/every time an IPv6 address changes/ s4.6, para 3: s/having stable address/having a stable address/ s5.1, last sentence: This seems to imply that *this section* states whether the failure mode is in or out of scope for the protocol. It doesn't - that is postponed to s7. Either remove this sentence or redraft to refer to s7. s5.1.2, para 2: s/is that partner also detected/is that the partner also detected/ s5.2: s/synchronization methods/synchronization method/, s/familiarity with distributed database/familiarity with distributed database technology/ s5.2.1, para 1: s/response from partner/response from its partner/ s5.2.1, para 2: 'large' is an over-generalization. Maybe: s/a large performance penalty/typically a significant performance penalty/ s5.2.1, para 3: OLD: Due to advent of SSD disks or battery backed ram disks technology, NEW: Due to the advent of fast SSD (solid state disk) and battery-backed RAM (random access memory) disk technology, s5.2.2, para 2: s/if server crashes/if the server crashes/ s7, item 4: s/should pose/should have/ _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
