Hi, INTRODUCTION:
>> Q2: In the Introduction, before the first sentence, shouldn't >> there be some background text, including some information about the >> problem that the document solves. I know there is something in the >> Abstract, but I think there should also be something in the >> Introduction, before jumping into the solution. >> >There's a whole RFC about it: RFC7031. It was intended as a gentle >introduction to the DHCP failover problem: what is in and outside of scope, >when failover is useful and >when it may not be the best tool. The DHC WG >decided to split it into separate document, because there are lots of things >to explain and the core document is already >obscenely large. This RFC is >clearly linked at the end of Introduction section. >Perhaps it would be more useful to move this reference to the front and add a >sentence or two of explanation? How about this text added as a first paragraph? > >This document defines a DHCPv6 failover protocol, which is a mechanism for >running two DHCPv6 servers with the capability for either server to take over >clients' leases in >case of server failure or network partition. For a general >overview of the DHCPv6 failover problems, use cases, benefits and >shortcomings, see RFC7031." Works for me. >> Q3: In the Introduction, I suggest adding a reference to the >> first occurrences of "DHCP service" and "DHCP server". >> >DHCP service is not a formal term. It was intended as a general description of >the DHCP server availability. How about we replace "or provide a DHCP service" >with "to >provide service to DHCP clients"? Works for me. >> Q4: In the Introduction, you switch between "This protocol" and >> "The failover protocol". Please use consistent terminology. This >> applies to the document in general. >> > There are 8 instances of "this protocol" and 20 of "the failover protocol". > We will go with the latter, ok? I can live with both, but the latter would be my preference too. SECTION 4: >> Q5: In the Abstract and Introduction it is said that DHCPv6 >> does not provide server redundancy. Then section 4 talks about >> failover concepts and mechanism. >> >> Are those concepts something used for DHCPv6 today, but for some >> reason do not fulfil the failover protocol requirements? >> >> OR, are these general concepts that will be supported by implementing >> the failover protocol? >> >> I think it would be good to have an introduction statement clarifying >> that. > > These are not being used by any non-failover DHCPv6 today. There is one > implementation of this draft that uses them. Most of those mechanisms are > required by any sane >failover design (e.g. any kind of failover-like > solution has to use lazy updates or it would be undeployable due to > performance), but some are specific to this particular >failover design (e.g. > the allocation algorithms). Would the following text added at the beginning > of Section 4 be sufficient? > >"The following section describes core concepts that are a foundation of this >failover protocol. Allocation strategies described in Section 4.2 are specific >to this particular >failover design, while the concept of Lazy updates >(Section 4.3) and MCLT (Section 4.4) seem to be necessary for any failover >design." Works for me. >Also, if you think it's useful, we can repeat a 7031 reference there, possibly >to Section 5.2 that discusses lazy updates >(update-after-response) and its alternative (update-before-response). I think that would be useful. Note that Kim had slightly different suggestions on how to address the issues. I am fine those, so I'll leave it up to you to decide which ones to adopt :) Thanks! Regards, Christer _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
