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

"Benoit Claise" <bclaise@cisco.com> Thu, 26 September 2013 10:05 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2D97211E8188; Thu, 26 Sep 2013 03:05:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.581
X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ekynYXccVxWx; Thu, 26 Sep 2013 03:05:40 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6E921F9399; Thu, 26 Sep 2013 03:05:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: "Benoit Claise" <bclaise@cisco.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 4.72
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20130926100537.29653.10844.idtracker@ietfa.amsl.com>
Date: Thu, 26 Sep 2013 03:05:37 -0700
Cc: cpignata@cisco.com, draft-ietf-netext-update-notifications@tools.ietf.org, netext-chairs@tools.ietf.org, netext@ietf.org
Subject: [netext] Benoit Claise's No Objection on draft-ietf-netext-update-notifications-08: (with COMMENT)
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Sep 2013 10:05:42 -0000

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:


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. 

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
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!