[MEXT] Review of draft-laganier-mext-cga-01

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Tue, 22 February 2011 19:20 UTC

Return-Path: <cjbc@it.uc3m.es>
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC2813A6813 for <mext@core3.amsl.com>; Tue, 22 Feb 2011 11:20:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level:
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 4rPFMiK43gzE for <mext@core3.amsl.com>; Tue, 22 Feb 2011 11:20:34 -0800 (PST)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 4070B3A6800 for <mext@ietf.org>; Tue, 22 Feb 2011 11:20:33 -0800 (PST)
X-uc3m-safe: yes
Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id AF4C59959B1; Tue, 22 Feb 2011 20:21:08 +0100 (CET)
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es>
To: mext@ietf.org
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-km04lukWLIO0CSVCAkBt"
Organization: Universidad Carlos III de Madrid
Date: Tue, 22 Feb 2011 20:22:27 +0100
Message-ID: <1298402547.4584.105.camel@acorde.it.uc3m.es>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17972.000
Cc: Julien Laganier <julien.ietf@gmail.com>
Subject: [MEXT] Review of draft-laganier-mext-cga-01
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: cjbc@it.uc3m.es
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Feb 2011 19:20:37 -0000

Dear Julien,

With a huge delay from my side (I volunteered to do this in the last
IETF meeting), here is my review of your draft. Apologies for the delay.

- I agree with most of the comments from Jouni and Alper. In particular,
I think the draft is a useful piece that is worth to be improved and get
published. Major aspects IMHO to be improved:

	* Terminology section and in general the document: references to other
documents are provided and it's a bit hard to follow all the details
about how the protocol works. It's true that the protocol is probably
defined as is in the detail enough for a developer to implement it, but
for the reader is hard to understand everything without going back and
forth to check the relevant references. Maybe it'd be good to include
some of these details in your draft as well (even if this means we are
repeating text that is already there in another IETF document).

	* Section 5 (Usage scenarios). I think it'd be useful to describe/refer
to some real examples where your solution is useful.

	* The BU authorization issue pointed by Alper is definitely a very good
one.

- There is another comment that is probably out-of-the-scope of your
document and more related to MIPv6. I've always wondered why there is no
test on the care-of address of the MN during the home registration. I do
not know why it is assumed that a MN cannot try to fool its HA sending a
BU containing a fake CoA. Jari raised this issue in the MEXT interim
meeting that took place in Madrid (focused on NEMO RO) but somehow I
missed the outcome of that discussion. I see this more relevant to your
draft, because of the BU authorization issue pointed above.

- I also think that section on IPv4 support (at least in its current
form) does not really fit well in the document.

Thanks,

Carlos

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67