[netext] Review of I-D: draft-ietf-netext-redirect-10

<Basavaraj.Patil@nokia.com> Fri, 09 September 2011 22:23 UTC

Return-Path: <Basavaraj.Patil@nokia.com>
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 B20E021F899D for <netext@ietfa.amsl.com>; Fri, 9 Sep 2011 15:23:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.638
X-Spam-Level:
X-Spam-Status: No, score=-102.638 tagged_above=-999 required=5 tests=[AWL=-0.039, 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 WWCcxAK06DA8 for <netext@ietfa.amsl.com>; Fri, 9 Sep 2011 15:23:10 -0700 (PDT)
Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id DE74B21F8564 for <netext@ietf.org>; Fri, 9 Sep 2011 15:23:09 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p89MP45P031749; Sat, 10 Sep 2011 01:25:04 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 10 Sep 2011 01:25:04 +0300
Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sat, 10 Sep 2011 00:25:04 +0200
Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0323.007; Sat, 10 Sep 2011 00:24:51 +0200
From: <Basavaraj.Patil@nokia.com>
To: <netext@ietf.org>
Thread-Topic: Review of I-D: draft-ietf-netext-redirect-10
Thread-Index: AQHMbz9K1OOVFC+yBEKKB/AJ5YQGcQ==
Date: Fri, 9 Sep 2011 22:24:50 +0000
Message-ID: <CA8FFC68.108EC%basavaraj.patil@nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.12.0.110505
x-originating-ip: [172.19.59.28]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E3754EF31F29F840B87514897CB01DDC@nokia.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 09 Sep 2011 22:25:04.0379 (UTC) FILETIME=[5272F4B0:01CC6F3F]
X-Nokia-AV: Clean
Cc: draft-ietf-netext-redirect@tools.ietf.org
Subject: [netext] Review of I-D: draft-ietf-netext-redirect-10
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: Fri, 09 Sep 2011 22:23:10 -0000

My WGLC review comments on Rev 10 of the I-D: draft-ietf-netext-redirect

1. Abstract can be improved. Rather than just mentioning the scope you
   could describe briefly the feature specified in this I-D.

2. Would be useful to describe in the introduction how runtime LMA
   assignment is different from the normal mode as specified in
   RFC5213 (which you do in Sec 5.2 1st paragraph)

3. s/assumed to have required Security Associations (SA)already set up
   in advance./assumed to have the required Security Associations (SA)
   pre-established.

4. In Section 4, it would be useful to explain (in brief) what is the
   functionality of a specific option. For example the
   'Redirect-Capability Mobility Option': The text has no explanation
   what this option is supposed to do in a message. You could add at
   least one sentence saying that it is used to indicate the redirect
   capability supported by the MAG, LMA entitied.

5. Missing the direction of the signaling flow message no 1 in fig 1.

6. s/There is no need to resend a PBU to the r2LMA after a successful
   runtime assignment./The MAG is not required to send a fresh PBU to
   the r2LMA after a successful runtime assignment.

7. s/The MAG MUST send subsequent binding refreshing PBUs and user
   traffic to the new r2LMA address./
   The MAG MUST send all user traffic to the r2LMA address. The MAG MUST
   send subsequent binding refresh PBUs to the r2LMA address.

-Raj