[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
- [netext] Fwd: AD Evaluation : draft-ietf-netext-u… Brian Haberman
- Re: [netext] Fwd: AD Evaluation : draft-ietf-nete… Brian Haberman
- Re: [netext] Fwd: AD Evaluation : draft-ietf-nete… Sri Gundavelli (sgundave)
- Re: [netext] Fwd: AD Evaluation : draft-ietf-nete… Brian Haberman
- Re: [netext] Fwd: AD Evaluation : draft-ietf-nete… Sri Gundavelli (sgundave)
- Re: [netext] Fwd: AD Evaluation : draft-ietf-nete… Sri Gundavelli (sgundave)
- Re: [netext] Fwd: AD Evaluation : draft-ietf-nete… Brian Haberman
- Re: [netext] Fwd: AD Evaluation : draft-ietf-nete… Sri Gundavelli (sgundave)