[netext] #2: AD review comments on LR PS I-D
"netext issue tracker" <trac+netext@trac.tools.ietf.org> Wed, 02 March 2011 22:13 UTC
Return-Path: <trac+netext@trac.tools.ietf.org>
X-Original-To: netext@core3.amsl.com
Delivered-To: netext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1CD43A6889 for <netext@core3.amsl.com>; Wed, 2 Mar 2011 14:13:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGxwdOIkCsdg for <netext@core3.amsl.com>; Wed, 2 Mar 2011 14:13:41 -0800 (PST)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2439C3A68DA for <netext@ietf.org>; Wed, 2 Mar 2011 14:13:41 -0800 (PST)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac+netext@trac.tools.ietf.org>) id 1PuuJT-0005iQ-Gk; Wed, 02 Mar 2011 14:14:31 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: netext issue tracker <trac+netext@trac.tools.ietf.org>
X-Trac-Version: 0.11.7
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.7, by Edgewall Software
To: liebsch@neclab.eu, basavaraj.patil@nokia.com
X-Trac-Project: netext
Date: Wed, 02 Mar 2011 22:14:31 -0000
X-URL: http://tools.ietf.org/netext/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/netext/trac/ticket/2
Message-ID: <066.bd004dcbf6b92d5e3c4e63cc5fefdf64@trac.tools.ietf.org>
X-Trac-Ticket-ID: 2
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: liebsch@neclab.eu, basavaraj.patil@nokia.com, draft-ietf-netext-pmip6-lr-ps@tools.ietf.org, netext@ietf.org
X-SA-Exim-Mail-From: trac+netext@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: netext@ietf.org, draft-ietf-netext-pmip6-lr-ps@tools.ietf.org
Subject: [netext] #2: AD review comments on LR PS I-D
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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, 02 Mar 2011 22:13:42 -0000
#2: AD review comments on LR PS I-D Below is the review by Jari Arkko. Please address the issues raised by Jari. Propose revised text as needed. " I have reviewed this draft. It is a well written draft and focuses on the right things. I have no major concerns and I have sent the document forward to an IETF last call and eventually an IESG evaluation (currently scheduled for March 17th). I did have a couple of comments, however, and I let the authors decide if they want to address them. Feel free to update the document even as it is beginning its last call period. Jari >Maintaining local forwarding between the MN and the >regular IPv6 CN gets more complex in case the MN performs a >handover >to a different MAG. Such use case is not considered in the >specification and out of scope of this problem statement. This >document focuses on use cases, where both nodes, the MN and the CN, >are each registered with an LMA and both obtain PMIPv6 mobility >service. I think you need to be clearer here. I think the point is that PMIP hosts are always regular IPv6 CNs but you only consider the case where both endpoints are *within a PMIP network* and in the area served by an LMA in a *domain of LMAs*. Section 4 seems to be missing some kind of a policy function. I think most deployments would need a way to control whether route optimization is desired or not. In some cases it might not be, e.g., if some accounting or firewall functions reside in the LMA. Section 6 should start with a short statement about the security concerns that a security solution for route optimization should help mitigate. For instance, it seems that an insecure route optimization mechanism would allow compromised network components or bad roaming partners to hijack or block any traffic for any mobile node. In insecure route optimization mechanism might also also outsiders (e.g., Internet hosts) to do the same, which would be even worse. There may also be some DoS issues. " -- ---------------------------------------+------------------------------------ Reporter: basavaraj.patil@… | Owner: liebsch@… Type: defect | Status: new Priority: major | Milestone: Component: pmip6-lr-ps | Version: Severity: Submitted WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/2> netext <http://tools.ietf.org/netext/>
- [netext] #2: AD review comments on LR PS I-D netext issue tracker