[netext] AD Review : draft-ietf-netext-pd-pmip

Brian Haberman <brian@innovationslab.net> Wed, 14 August 2013 20:17 UTC

Return-Path: <brian@innovationslab.net>
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 6185511E8118 for <netext@ietfa.amsl.com>; Wed, 14 Aug 2013 13:17:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Ka8L4EEufR4f for <netext@ietfa.amsl.com>; Wed, 14 Aug 2013 13:17:27 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com []) by ietfa.amsl.com (Postfix) with ESMTP id 35E1A21E80D6 for <netext@ietf.org>; Wed, 14 Aug 2013 13:17:27 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id DCFCA880A9; Wed, 14 Aug 2013 13:17:26 -0700 (PDT)
Received: from clemson.local (c-69-140-213-249.hsd1.md.comcast.net []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 806FA130003; Wed, 14 Aug 2013 13:17:26 -0700 (PDT)
Message-ID: <520BE5D5.7030801@innovationslab.net>
Date: Wed, 14 Aug 2013 16:17:25 -0400
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: draft-ietf-netext-pd-pmip@tools.ietf.org, "netext@ietf.org" <netext@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [netext] AD Review : draft-ietf-netext-pd-pmip
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, 14 Aug 2013 20:17:33 -0000

      I have performed my AD review of draft-ietf-netext-pd-pmip.  I 
apologize for it taking as long as it did.  Overall, I am supportive of 
this work, but I have some concerns.  I *think* most of my concerns have 
to do with a lack of clarity in the spec caused by the layout of the 
draft.  Of particular concern is the overabundance of bullet lists in 
sections 5.1.2.

      Please let me know if you need additional detail on any of these 
comments.  Otherwise, I will await a revised version that the WG is 
happy with.

1. In the Abstract, mention that prefix delegation is being described in 
relation to DHCPv6-PD

2. The Introduction says prefix delegation via DHCPv6 or through other 
mechanisms.  Later, the draft says DHCPv6 or static configuration.  I 
can see how both of those could be made to work, but I am leery of 
mentioning some future PD protocol.  How would that work?  How would you 
know which mechanism is being used?  Will the same PMIPv6
signaling suffice for a future PD protocol?  I think it makes sense to 
stick to what we know how to do today.

3. Figures 2-4 are never referenced in the text.

4. Intro uses MAG without expansion or definition.

5. Introduction defines egress and ingress interfaces, but should 
explicitly state these terms are defined from the perspective of the 
mobile network.  I would actually move these definitions to section 2 
and describe the MR function in relation to the mobile network and the 

6. How do the definitions in section 2 relate to the definitions in RFC 

7. Section 3.1 - any additional assumptions about how an MR knows which 
interface to use when making DHCPv6 requests?

8. Sections 3.2.1 and 3.2.2 are rather sparse in descriptive text.  It 
would be good to briefly describe the steps outlined in the 
corresponding figures.

9. Section 5.1.2 - Fourth bullet says the MAG MAY choose to send PBA 
after getting a DMNP_IN_USE return code.  Why would it (or not) do that?

10. The bullet lists in 5.1.2/5.2.2 (and child sections) are confusing. 
  The high-level bullets read like they should just be paragraphs.  The 
sub-list in bullet two and five are items that need to
be considered if stated conditions are met, correct?.  And am I correct 
in that there must be 3 instances of the DMNP option in the PBU?

11. Structure of is confusing.  Can DHCP-MAG Interactions be 
promoted to 5.1.3 and then have describe when MAG is DR and describe when LMA is DR?

12. Bullet 2 of the DR at the MAG scenario is confusing. If the DR and 
MAG are co-located, what interactions are beyond the scope of this 
document?  Or is this more of the interactions between two processes 
running on the same platform?

13. If the MR roams to a MAG that does not support PD, is there specific 
behavior the MR needs to exhibit wrt the LFNs?

14. Is there a preference (operational issues) for running the DR at the 
LMA rather than the MAG, or vice versa?  If so, should that be noted?