[netext] Benoit Claise's No Objection on draft-ietf-netext-update-notifications-08: (with COMMENT)

["Benoit Claise" <[e-mail]>]

Benoit Claise has entered the following ballot position for
draft-ietf-netext-update-notifications-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.