Jari, Elwyn, Elwyn -- thank you for the thoughtful review. My comments are indented below...
On Jul 16, 2013, at 3:36 AM, Jari Arkko wrote: > 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. Yes, this is a fine idea. Thanks for the sentence. >> >> 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! Sure, we'll put something in to deal with that. >> >> 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." Yes, we'll reword this as you suggest. >> >> 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? Well, this thought is explored in Section 3.1.3, but under the overall heading of "Alternatives to Failover". Is this an alternative *to* failover, or an option *for* failover (as you suggest might be appropriate)? Hard to say. I suppose that our design draft, already about to go to last call, influenced our thinking to some degree when we wrote this. I don't think the document would be substantively better were we to change it so that a distributed database solution is an option as opposed to an alternative. So, to be clear, I don't think changing this is a good idea. >> >> 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? The work in progress ended years ago. Many years ago. The document which you reference is ~132 pages long, and has requirements, design, and protocol all in one document. It was essentially too big and complicated to be digested by the IETF. We could not even get the AD at the time to review the entire document. In part this was because the problem was important to solve in an intra-vendor way, but inter-vendor capable failover was not important in the real world (i.e., nobody really cared to pay extra for failover that worked across two vendors servers). The experience gained during the v4 failover effort is the reason the v6 failover effort (of which the document under discussion is a part) has been split into three separate pieces: requirements, design, and (if sufficient interest exists), protocol. The hope is that these pieces will be individually digestible where the v4 effort was not. That said, the v6 failover design draft is already 50 pages, and it hasn't yet undergone WG last call, though it is very close to that point. Plus, it is possible that we will end with the design document, since that will have the basics of how you build a v6 failover capability. The protocol document is only really interesting if you want to have an inter-vendor failover capability. We don't yet know how that will play out, though we certainly expect to give it a try. >> >> Nits/editorial comments: Thank you for catching these. We will make all of these changes. Thanks again for your review! Regards -- Kim >> >> 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
