Last Call Review of draft-ietf-dhc-triggered-reconfigure-05
review-ietf-dhc-triggered-reconfigure-05-genart-lc-sparks-2013-04-30-00

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-06
Requested 2013-04-25
Other Reviews Genart Last Call review of -06 by Robert Sparks (diff)
Review State Completed
Reviewer Robert Sparks
Review review-ietf-dhc-triggered-reconfigure-05-genart-lc-sparks-2013-04-30
Posted at http://www.ietf.org/mail-archive/web/gen-art/current/msg08491.html
Reviewed rev. 05 (document currently at 07)
Review result On the Right Track
Draft last updated 2013-04-30
Review completed: 2013-04-30

Review
review-ietf-dhc-triggered-reconfigure-05-genart-lc-sparks-2013-04-30

  
  
    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: