Last Call Review of draft-ietf-dhc-triggered-reconfigure-06

Request Review of draft-ietf-dhc-triggered-reconfigure
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-05-14
Requested 2013-05-02
Authors Mohamed Boucadair, Xavier Pougnard
Draft last updated 2013-05-10
Completed reviews Genart Last Call review of -05 by Robert Sparks (diff)
Genart Last Call review of -06 by Robert Sparks (diff)
Assignment Reviewer Robert Sparks 
State Completed
Review review-ietf-dhc-triggered-reconfigure-06-genart-lc-sparks-2013-05-10
Reviewed rev. 06 (document currently at 07)
Review result Ready
Review completed: 2013-05-10


Looks good to me. Thanks!


      On 5/6/13 3:02 AM, 

mohamed.boucadair at


Dear Robert,


I updated the document
            to cover the comments you raised. You can check the diff
            available at:





De :


dhcwg-bounces at


mailto:dhcwg-bounces at


De la part de

                  Robert Sparks

Envoyé :

 vendredi 26 avril 2013 17:42

À :


dhcwg at


ietf at

; General Area
                  Review Team;

draft-ietf-dhc-triggered-reconfigure at

Objet :

 [dhcwg] Gen-art review:


I am the
            assigned Gen-ART reviewer for this draft. For background on

            Gen-ART, please see the FAQ at 



            Please resolve these comments along with any other Last Call

            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: