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

Carlos Jesús Bernardos Cano <> Thu, 15 August 2013 01:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CE1D21E8056 for <>; Wed, 14 Aug 2013 18:39:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cUEuCQMThvRI for <>; Wed, 14 Aug 2013 18:38:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1A72711E80E0 for <>; Wed, 14 Aug 2013 18:38:54 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id AC940CD5373; Thu, 15 Aug 2013 03:38:53 +0200 (CEST)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from [] (unknown []) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id F26CECD52B2; Thu, 15 Aug 2013 03:38:52 +0200 (CEST)
Message-ID: <>
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <>
To: Brian Haberman <>
Date: Thu, 15 Aug 2013 03:38:47 +0200
In-Reply-To: <>
References: <>
Organization: Universidad Carlos III de Madrid
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.4.4-3
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-TM-AS-Product-Ver: IMSS-
Cc: "" <>,
Subject: Re: [netext] AD Review : draft-ietf-netext-pd-pmip
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Aug 2013 01:39:02 -0000

Hi Brian,

Thanks a lot for the review. We'll come back to you with our responses &
comments, and a revised version of the I-D for the WG to check soon.



On Wed, 2013-08-14 at 16:17 -0400, Brian Haberman wrote:
> All,
>       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 
> point-of-attachment.
> 6. How do the definitions in section 2 relate to the definitions in RFC 
> 4885?
> 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?
> Regards,
> Brian