[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/>