[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 [127.0.0.1]) 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-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 Ka8L4EEufR4f for <netext@ietfa.amsl.com>; Wed, 14 Aug 2013 13:17:27 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) 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 [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 DCFCA880A9; Wed, 14 Aug 2013 13:17:26 -0700 (PDT)
Received: from clemson.local (c-69-140-213-249.hsd1.md.comcast.net [69.140.213.249]) (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
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 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? 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
- [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