[netext] Fwd: AD Evaluation : draft-ietf-netext-update-notifications

Brian Haberman <brian@innovationslab.net> Wed, 24 July 2013 18:21 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2619111E8252 for <netext@ietfa.amsl.com>; Wed, 24 Jul 2013 11:21:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I12npZVt5EOl for <netext@ietfa.amsl.com>; Wed, 24 Jul 2013 11:21:04 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE1711E8251 for <netext@ietf.org>; Wed, 24 Jul 2013 11:21:00 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 43D8A8814F for <netext@ietf.org>; Wed, 24 Jul 2013 11:21:00 -0700 (PDT)
Received: from 102526145.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 0E8F0130003 for <netext@ietf.org>; Wed, 24 Jul 2013 11:20:59 -0700 (PDT)
Message-ID: <51F01B0B.8030409@innovationslab.net>
Date: Wed, 24 Jul 2013 14:20:59 -0400
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: "netext@ietf.org" <netext@ietf.org>
References: <51F019FA.9060704@innovationslab.net>
In-Reply-To: <51F019FA.9060704@innovationslab.net>
X-Forwarded-Message-Id: <51F019FA.9060704@innovationslab.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [netext] Fwd: AD Evaluation : draft-ietf-netext-update-notifications
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Wed, 24 Jul 2013 18:21:11 -0000

-------- Original Message --------
Subject: AD Evaluation : draft-ietf-netext-update-notifications
Date: Wed, 24 Jul 2013 14:16:26 -0400
From: Brian Haberman <brian@innovationslab.net>
To: netext-chairs@tools.ietf.org <netext-chairs@tools.ietf.org>, 
draft-ietf-netext-update-notifications@tools.ietf.org

All,
      I have performed my AD evaluation of
draft-ietf-netext-update-notifications as a part of the RFC publication
process.  Thank you for a well-written document.  The following
comments/questions need to be addressed prior to issuing an IETF Last
Call for the draft.  Please let me know if there is any clarification I
can provide on these comments.

* Introduction

- The 2nd sentence in the 2nd paragraph is clunky.  I finally figured
out that what it is trying to say is that the MAG proxies all MIPv6
signaling on behalf of the mobile node and the LMA acts as a MIPv6 home
agent.  I would suggest re-writing the sentence to be clearer for those
readers who are not experts in the mobility protocols.

- The last sentence of the 2nd paragraph should say that PMIPv6 does not
*currently* have an LMA-to-MAG signaling mechanism.

- The first sentence in the 3rd paragraph is missing an article.  I
believe it should be "... re-register the mobility session..."

- The last sentence in the 3rd paragraph that discusses the use of
existing headers is confusing.  It starts off by saying it is possible
to use existing headers for this signaling and ends by saying they can't
be used.

* Section 4

- Is there any guidance needed on managing the wrapping of the Sequence #'s?

- Is it worth mentioning the Pad1 and PadN options given the alignment
requirements?

- Are there informative references that could be added for mobility
options other than the vendor-specific ones?

* Section 5

- The last bullet is extraneous since it simply points to the very next
sub-section.

- Can you provide an example of where an LMA would not request an ACK
for a UPN?

- I assume that the sequence numbers used in these messages are the same
sequence numbers used for other PMIPv6/MIPv6 messages.  It might be
worthwhile to mention that, if it is true.

* Section 5.2

- I am surprised by the use of SHOULD (SHOULD NOT) for re-transmission
rules.  When would you expect these rules to be ignored?

* Section 6.1

- The 2nd bullet is useless.  If an implementation does not support
these messages, they wouldn't know to look here for responses.  The base
PMIPv6 spec covers the response message for unknown message types.

- Should there be any validation performed on the sequence number?

* IANA

- I would like to see some more guidance given to IANA on where the new
registries should be placed in their protocol hierarchy.

Regards,
Brian