Update Notifications for Proxy Mobile IPv6
draft-ietf-netext-update-notifications-12

-09 fixes the IANA URI issue.  Thanks.

For the record, here is Carlos Pignataro's feedback, part of OPS-DIR. It's been worked on by Suresh

Minor comment:

This document specifies two configurable variables in Section 7. It clearly specifies that these variables need to survive reboots, and also specifies what it seems to be sensible defaults. However, it does not specify ranges or considerations for these two values. I'd suggest adding some more details about ranges. 

The MAX_UPDATE_NOTIFICATION_RETRANSMIT_COUNT default says it can be retransmitted once. The MIN_DELAY_BETWEEN_UPDATE_NOTIFICATION_REPLAY default is the minimum value, which means that retransmission delay cannot be less than a second. I expect this is OK, but would ask whether it makes sense to have the variable in milliseconds and the default as 1,000. The answer can perfectly be "no, does not make sense".

Also, a small nit in two IANA actions:

   o  Action-3: This specification defines a new registry for
      Notification Reasons.  Its called, "Update Notification Reasons
      Registry".  This registry should be created under "Mobile IPv6
      Parameters" registry at (https://www.iana.org/assignments/
      mobility-parameters/mobility-parameters.xhtml).  The Notification

   o  Action-4: This specification defines a new registry for Status.
      Its called, "Update Notification Acknowledgement Status Registry".
      This registry should be created under "Mobile IPv6 Parameters"
      registry at (https://www.iana.org/assignments/mobility-parameters/
      mobility-parameters.xhtml).  The status is a field in the Update

The URL should not point to the .xhtml pages, they should point to the extension-less URLs.

A question:

If the Status Codes are partitioned as 0-127 as success and 128-255 as error, why the error allocations start at 129?

      0 -  Success
      129 -  FAILED-TO-UPDATE-SESSION-PARAMETERS
      130 -  MISSING-VENDOR-SPECIFIC-OPTION
   
Should 128 be assigned?

Another protocol problem:

   o  If the local mobility anchor receives an Update Notification
      Acknowledgement message with a failure Status and the value of
      larger than 128, then it SHOULD log an error.

Why the status "larger" than 128 and not "larger than or equal to" 128? This needs to be fixed (> 127 or >= 128)

Hope these are clear and useful!

Carlos.

Robert Sparks raised a clarity issue in the document in his Gen-ART review, and there has been discussion with the authors to correct the issue, and the correction has made it to a private version of the draft. I wish that version would be published so that we could deal with as clean document as possible, free of issues that have already been resolved.

(If you had no other issues to resolve, I'd probably raise this as a discuss, because I'd want to avoid accidentally approving the document without the changes making it to the last version.)

Thanks for clarifying the relationship between netext and IPsec SAs.