Elwyn, I love the "NEW" paragraph below. We'll be sure to use that.
Thanks! Kim On Jul 17, 2013, at 10:41 AM, Elwyn Davies wrote: > Hi, Kim. > > Thanks for the reponses. > > Looks like we are pretty well agreed. Just these two points: > > On s7, item 6: Just a thought so I'll consider it irrelevant. > > On the last para of 7, I clearly failed to notice the date on the draft > for DHCPv4 failover protocol! [The hazards of an infinite archive for > I-Ds!] So I understand why this probably isn't going to go all the way > to an inter-operable protocol for either v4 or v6. Perhaps it might be > worth adding in a few words to explain this (and improve an editorial > nit I missed): > OLD: > Despite the lack of standardization of DHCPv4 failover, the > coexistence of DHCPv4 and DHCPv6 failover may be taken into > consideration. In particular, certain features that are common for > both IPv4 and IPv6, like DNS Update mechanism should be taken into > consideration. > NEW: > Although progress on a standardized inter-operable DHCPv4 failover > protocol has stalled, vendor-specific DHCPv4 failover protocols > have been deployed that meet these requirements to a large extent. > Accordingly it would be appropriate to take into account the likely > coexistence of DHCPv4 and DHCPv6 failover solutions. In particular, > certain features that are common to both IPv4 and IPv6 > implementations, such as any DNS Update mechanism, should be taken into > consideration to ensure compatible operation. > > Regards, > Elwyn > > On Tue, 2013-07-16 at 10:38 -0400, Kim Kinnear wrote: >> 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
