:-) On Wed, 2013-07-17 at 11:38 -0400, Kim Kinnear wrote: > 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
