Subject: Re: [Gen-art] [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

From: <[email-masked]>
Date: Mon, 6 May 2013 10:02:53 +0200

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-masked] [mailto:[email-masked]] De la part de Robert Sparks
Envoyé : vendredi 26 avril 2013 17:42
À : [email-masked]; [email-masked]; General Area Review Team; [email-masked]
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:

---

From: Robert Sparks <[email-masked]>
Date: Mon, 06 May 2013 11:09:44 -0500

Looks good to me. Thanks!
RjS

On 5/6/13 3:02 AM, [email-masked] 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-masked] [mailto:[email-masked]] *De la 
> part de* Robert Sparks
> *Envoyé :* vendredi 26 avril 2013 17:42
> *À :* [email-masked]; [email-masked]; General Area Review Team; 
> [email-masked]
> *Objet :* [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05
>
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> 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:
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 15 May 2013 23:36:28 +0300

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-masked]> wrote:

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg