Robert, Ted suggested a wording which is better than the one I proposed. I made the following changes my local copy: (1) OLD: 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). NEW: The relay MAY remove clients from the client identifier list in subsequent retransmissions, but MUST NOT add clients to the client identifier list. (2) OLD: Furthermore, means to recover state in failure events must be supported, but are not discussed in this document. NEW: Furthermore, means to recover state in failure events (e.g., [RFC5460]) must be supported, but are not discussed in this document. Is this better? Cheers, Med >-----Message d'origine----- >De : Bernie Volz (volz) [mailto:volz@xxxxxxxxx] >Envoyé : samedi 27 avril 2013 06:24 >À : Robert Sparks; BOUCADAIR Mohamed OLNC/OLN >Cc : dhcwg@xxxxxxxx; General Area Review Team; ietf@xxxxxxxx; draft-ietf- >dhc-triggered-reconfigure@xxxxxxxxxxxxxx >Objet : RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered- >reconfigure-05 > >Robert: > >The reason to allow this is that otherwise client A will be unnecessarily >reconfigured many times. (It is also possible that a client might Renew on >its own just as this is happening and thus it can also be removed from the >Reconfigure.) > >I think the text should be cleaned up to indicate that allowing removal of >already reconfigured clients is recommended (to prevent unnecessary >reconfigures) when retransmitting the Reconfigure-Request. > >Note that if clients are added, that is not a retransmission but requires a >"new" message (new XID). > >- Bernie > >-----Original Message----- >From: dhcwg-bounces@xxxxxxxx [mailto:dhcwg-bounces@xxxxxxxx] On Behalf Of >Robert Sparks >Sent: Friday, April 26, 2013 12:19 PM >To: mohamed.boucadair@xxxxxxxxxx >Cc: dhcwg@xxxxxxxx; General Area Review Team; ietf@xxxxxxxx; draft-ietf- >dhc-triggered-reconfigure@xxxxxxxxxxxxxx >Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered- >reconfigure-05 > >On 4/26/13 10:58 AM, mohamed.boucadair@xxxxxxxxxx wrote: >> Dear Robert, >> >> Thank you for the review. >> Please see inline. >> >> Cheers, >> Med >> ________________________________________ >> De : dhcwg-bounces@xxxxxxxx [dhcwg-bounces@xxxxxxxx] de la part de >> Robert Sparks [rjsparks@xxxxxxxxxxx] Date d'envoi : vendredi 26 avril >> 2013 17:42 À : dhcwg@xxxxxxxx; ietf@xxxxxxxx; General Area Review >> Team; draft-ietf-dhc-triggered-reconfigure@xxxxxxxxxxxxxx >> 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><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. >> >> Med: This example does not apply for that text. >Really? What text constrains how you change what's in the retransmission? >> In fact, the example should be the other way around. Perhaps, this can >be made clearer if we change "(e.g., update the Client Identifier list)" to >"(e.g., remove a client from the Client Identifier list)". >If I understand you correctly, you need more than just changing a >parenthetical e.g.. I think you're saying that you are constraining the >message changes to be such that if anything earlier in the retransmission >sequence succeeded, the request in the retransmission would also have >succeeded. But why do you need that much complexity? Do you have it already >with any other request? >> >> 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? >> >> Med: I'm not aware of any; but if there is one we can cite it. >> >> 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. >> >> Med: Will consider that option if you think this is really needed. >> >> Nits/editorial comments: > >_______________________________________________ >dhcwg mailing list >dhcwg@xxxxxxxx >https://www.ietf.org/mailman/listinfo/dhcwg