RE: [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05
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 : dhcwg-boun...@ietf.org [mailto:dhcwg-boun...@ietf.org] De la part de Robert Sparks Envoyé : vendredi 26 avril 2013 17:42 À : dh...@ietf.org; ietf@ietf.org; General Area Review Team; draft-ietf-dhc-triggered-reconfig...@tools.ietf.org 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/GenArtfaqhttp://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:
Re: [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05
Looks good to me. Thanks! RjS On 5/6/13 3:02 AM, mohamed.boucad...@orange.com 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 :*dhcwg-boun...@ietf.org [mailto:dhcwg-boun...@ietf.org] *De la part de* Robert Sparks *Envoyé :* vendredi 26 avril 2013 17:42 *À :* dh...@ietf.org; ietf@ietf.org; General Area Review Team; draft-ietf-dhc-triggered-reconfig...@tools.ietf.org *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. 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:
RE : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05
Dear Robert, Thank you for the review. Please see inline. Cheers, Med De : dhcwg-boun...@ietf.org [dhcwg-boun...@ietf.org] de la part de Robert Sparks [rjspa...@nostrum.com] Date d'envoi : vendredi 26 avril 2013 17:42 À : dh...@ietf.org; ietf@ietf.org; General Area Review Team; draft-ietf-dhc-triggered-reconfig...@tools.ietf.org 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/GenArtfaqhttp://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. 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). 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:
Re: RE : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05
On 4/26/13 10:58 AM, mohamed.boucad...@orange.com wrote: Dear Robert, Thank you for the review. Please see inline. Cheers, Med De : dhcwg-boun...@ietf.org [dhcwg-boun...@ietf.org] de la part de Robert Sparks [rjspa...@nostrum.com] Date d'envoi : vendredi 26 avril 2013 17:42 À : dh...@ietf.org; ietf@ietf.org; General Area Review Team; draft-ietf-dhc-triggered-reconfig...@tools.ietf.org 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/GenArtfaqhttp://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:
