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

Brian Haberman <brian@innovationslab.net> Thu, 10 October 2013 14:24 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 663C111E817B for <netext@ietfa.amsl.com>; Thu, 10 Oct 2013 07:24:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.578
X-Spam-Level:
X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 9sS26GiaFUsO for <netext@ietfa.amsl.com>; Thu, 10 Oct 2013 07:24:15 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 290AD11E8173 for <netext@ietf.org>; Thu, 10 Oct 2013 07:24:07 -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 E1D09880F3 for <netext@ietf.org>; Thu, 10 Oct 2013 07:24:03 -0700 (PDT)
Received: from 10252297.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 8C57A1368105 for <netext@ietf.org>; Thu, 10 Oct 2013 07:24:03 -0700 (PDT)
Message-ID: <5256B87F.4090004@innovationslab.net>
Date: Thu, 10 Oct 2013 10:23:59 -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: "netext@ietf.org" <netext@ietf.org>
References: <520BE5D5.7030801@innovationslab.net> <1381273240.4024.18.camel@acorde.it.uc3m.es>
In-Reply-To: <1381273240.4024.18.camel@acorde.it.uc3m.es>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Q7tDdmF4i26DeTqHoV4uMmQ1RLMPdriRw"
Subject: Re: [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: Thu, 10 Oct 2013 14:24:25 -0000

All,
     I would like the WG to review these changes and speak up if they
have any concerns with them.

Regards,
Brian


On 10/8/13 7:00 PM, Carlos Jesús Bernardos Cano wrote:
> Hi Brian, all,
> 
> Apologies for the late reaction on this.
> 
> We have just posted a new revision (-10) of the draft, addressing your
> comments. Please see inline below some answers.
> 
> 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.
> 
> [Authors] We have tried to reduce the use of the bullet lists, as well
> as to reorganize a bit the text.
> 
>>
>>       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.
>>
> 
> We would like to ask the WG to check whether they are happy with current
> revision of the document.
> 
>>
>> 1. In the Abstract, mention that prefix delegation is being described in 
>> relation to DHCPv6-PD
> 
> [Authors] Done.
> 
>>
>> 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.
> 
> [Authors] The specification focuses on DHCPv6-PD, but also allows for
> static configuration or access technology specific mechanisms. We have
> clarified the text, so we do not mention any future PD protocol.
> 
>>
>> 3. Figures 2-4 are never referenced in the text.
> 
> [Authors] Fixed.
> 
>>
>> 4. Intro uses MAG without expansion or definition.
> 
> [Authors] Fixed.
> 
>>
>> 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.
> 
> [Authors] Done.
> 
>>
>> 6. How do the definitions in section 2 relate to the definitions in RFC 
>> 4885?
> 
> [Authors] We have clarified this.
> 
>>
>> 7. Section 3.1 - any additional assumptions about how an MR knows which 
>> interface to use when making DHCPv6 requests?
> 
> [Authors] We assume the egress interface is used. We have explicitly
> added this in the text.
> 
>>
>> 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.
> 
> [Authors] Done.
> 
>>
>> 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?
> 
> [Authors] This was a typo. It should say "PBU". We have fixed it.
> 
>>
>> 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?
> 
> [Authors] We have made some changes there to make this more clear.
> 
>>
>> 11. Structure of 5.1.2.1 is confusing.  Can DHCP-MAG Interactions be 
>> promoted to 5.1.3 and then have 5.1.3.1 describe when MAG is DR and 
>> 5.1.3.2 describe when LMA is DR?
> 
> [Authors] Done.
> 
>>
>> 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?
> 
> [Authors] It is more on the interactions between the two processes. We
> have rewritten that piece of text to make it more clear.
> 
>>
>> 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?
> 
> [Authors] We have added some text on this. Basically, we assume that all
> MAGs supports PD. If not, that would make the MR loose the delegated
> prefixes, and therefore the LFNs would loose them. We mention that the
> MR may explicitly deprecate the addresses used by the LFNs or just leave
> them expire.
> 
>>
>> 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?
> 
> [Authors] Although we do not have a super strong preference, it is
> simpler to run the DR on the MAG. so a single protocol interface is used
> between the MAG and the LMA. We have added some text on this.
> 
>>
>>
>> Regards,
>> Brian
>