Last Call Review of draft-ietf-netext-update-notifications-07
review-ietf-netext-update-notifications-07-genart-lc-sparks-2013-08-22-00

Request Review of draft-ietf-netext-update-notifications
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-08-29
Requested 2013-08-15
Draft last updated 2013-08-22
Completed reviews Genart Last Call review of -07 by Robert Sparks (diff)
Genart Telechat review of -08 by Robert Sparks (diff)
Opsdir Early review of -12 by Carlos Pignataro
Assignment Reviewer Robert Sparks
State Completed
Review review-ietf-netext-update-notifications-07-genart-lc-sparks-2013-08-22
Reviewed rev. 07 (document currently at 12)
Review result Ready
Review completed: 2013-08-22

Review
review-ietf-netext-update-notifications-07-genart-lc-sparks-2013-08-22

  
  
    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-netext-update-notifications-07


    Reviewer: Robert Sparks
    


    Review Date: 2013-08-22


    IETF LC End Date: 2013-08-29


    IESG Telechat date: not scheduled





    Summary: This draft is ready for publication as Proposed Standard





    I had to read through this text several times to convince myself
    implementers could figure out what order they were required to take
    steps in vs where they had flexibility:




   o  Upon accepting the Update Notification message, the mobile access
      gateway MUST process the message and perform the actions based on
      the Notification Reason.
      *  If the (A) flag in the message is set to a value of (1), the
         mobile access gateway MUST first send an Update Notification
         Acknowledgement message and set the status code field according
         to the result of processing the Update Notification message.




    In particular, it's not immediately obvious if there is tension
    between that "MUST first" and having "the result of processing"
    available.


    Please consider rewording to make it clearer that this "result of
    processing" is not intended to include waiting for the result of
    some action processing this notification message might trigger.





    It might help readers understand the intended usual case
    retransmission mechanics if the expected default values listed in
    section 7 were called out earlier in the document.