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 >
- [netext] AD Review : draft-ietf-netext-pd-pmip Brian Haberman
- Re: [netext] AD Review : draft-ietf-netext-pd-pmip Carlos Jesús Bernardos Cano
- Re: [netext] AD Review : draft-ietf-netext-pd-pmip Carlos Jesús Bernardos Cano
- Re: [netext] AD Review : draft-ietf-netext-pd-pmip Brian Haberman