Thank you for your review, Elwyn. Do the authors have any thoughts on the issues that Elwyn raises here?
Jari On Jul 6, 2013, at 3:01 PM, Elwyn Davies <[email protected]> wrote: > 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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
