Robert, Thank you very much for your review. A big part of my document approval decisions are the Gen-ART reviews, and they help me greatly.
Thank you Mohamed for the revision! I plan to support the approval of this document in the IESG call tomorrow. Jari On May 6, 2013, at 7:09 PM, Robert Sparks <[email protected]> wrote: > Looks good to me. Thanks! > RjS > > On 5/6/13 3:02 AM, [email protected] wrote: >> Dear Robert, >> >> I updated the document to cover the comments you raised. You can check the >> diff available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-triggered-reconfigure-06 >> >> Cheers, >> Med >> >> De : [email protected] [mailto:[email protected]] De la part de >> Robert Sparks >> Envoyé : vendredi 26 avril 2013 17:42 >> À : [email protected]; [email protected]; General Area Review Team; >> [email protected] >> Objet : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05 >> >> 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-triggered-reconfigure-05 >> Reviewer: Robert Sparks >> Review Date: April 26, 2013 >> IETF LC End Date: May 6, 2013 >> IESG Telechat date: May 16, 2013 >> >> Summary: This draft is on the right track but has open issues, described in >> the review. >> >> Major issues: >> >> Overall, this document is solid, but I think there is a bug in section 6.3. >> I could be wrong, but If I'm right, this paragraph: >> >> When retransmission is required, the relay may decide to correct the content >> of RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier >> list). This decision is local to the relay (e.g., it may be based on >> observed events such as one or more clients were reconfigured on their own). >> >> introduces a race-condition that could lead to an erroneous state. If a >> relay's first message included client A, then the retransmission included >> clients A and B, but that retransmission crosses with a success >> RECONFIGURE-REPLY to the request that only included client A, the relay will >> think it succeeded in asking A and B to be reconfigured. >> >> Minor issues: >> >> This sentence: >> >> Furthermore, means to recover state in failure events must be supported, but >> are not discussed in this document. >> places a requirement on a relay (even though it's not using a 2119 MUST). Is >> there some other document that defines this requirement that you can >> reference? If not, the requirement should be discussed in this document. >> Alternatively, you could change the sentence to talk about the consequences >> of not having a proprietary means for recovering state. >> >> Nits/editorial comments: > > _______________________________________________ > dhcwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
