[Gen-art] Gen-ART review of draft-ietf-mip4-multiple-tunnel-support-12
"Vijay K. Gurbani" <vkg@bell-labs.com> Fri, 15 May 2015 15:06 UTC
Return-Path: <vkg@bell-labs.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FA11A007F; Fri, 15 May 2015 08:06:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kfql3DIs9kI8; Fri, 15 May 2015 08:06:04 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6041A0078; Fri, 15 May 2015 08:06:01 -0700 (PDT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id A526FA75D328D; Fri, 15 May 2015 15:05:56 +0000 (GMT)
Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t4FF5v3O032053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2015 11:05:58 -0400
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.169]) by umail.lucent.com (8.13.8/TPES) with ESMTP id t4FF5rTS009304; Fri, 15 May 2015 10:05:54 -0500 (CDT)
Message-ID: <55560B9A.8080404@bell-labs.com>
Date: Fri, 15 May 2015 10:07:06 -0500
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: draft-ietf-mip4-multiple-tunnel-support@tools.ietf.org
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/n3wsqd2slYIc9Cds1DB7ETLk5d8>
Cc: mccap@petoni.org, General Area Review Team <gen-art@ietf.org>, draft-ietf-mip4-multiple-tunnel-support.ad@ietf.org, mip4-chairs@ietf.org
Subject: [Gen-art] Gen-ART review of draft-ietf-mip4-multiple-tunnel-support-12
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 May 2015 15:06:06 -0000
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-mip4-multiple-tunnel-support-12
Reviewer: Vijay K. Gurbani
Review Date: May-15-2015
IETF LC End Date: May-25-2015
IESG Telechat date: Not known
This document is ready as an Experimental Standard. A couple of points
below need addressing, though.
Major: 0
Minor: 2
Nits: 1
Minor:
1/ S4.1, second paragraph: "This extension is a non-skippable extension
and MAY be added by the mobile node to the Registration Request
message."
Two comments.
First, does "non-skippable" mean "MUST be present"? If so, why "non-
skippable"? At least I have not seen such a phrase in an IETF
document before. My suggestion would be to simply say that "This
extension MUST be present and ..."
Which brings us to the second comment.
"... and MAY be added by the mobile node ..." This extension is
"non-skippable" (?) but a mobile node MAY add it. If the extension
is "non-skippable", then why the MAY?
Furthermore, if the intent is for some other entity to add this
extension if the mobile node does not (hence the justification of
MAY), then you should spell out who this entity is. (Sort of
how you do it in S4.2, second paragraph, which contains almost
identical language to above without the qualifying last phrase
that informs the reader who will add the extension if not the
mobile node.)
2/ S4.2, second paragraph: Consider changing the "non-skippable"
to "MUST be present" (c.f., above comment).
Nits:
1/ S2.2, the following sentence does not read well:
A mobile node, when it registers multiple bindings with its home
agent, each using different care-of addresses, then each of those
bindings are given a unique identifier.
Suggested text:
When a mobile node registers multiple bindings with its home
agent, each using a different care-of address, then each of those
bindings are given a unique identifier.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
- [Gen-art] Gen-ART review of draft-ietf-mip4-multi… Vijay K. Gurbani
- Re: [Gen-art] Gen-ART review of draft-ietf-mip4-m… Henrik Levkowetz
- Re: [Gen-art] Gen-ART review of draft-ietf-mip4-m… Vijay K. Gurbani
- Re: [Gen-art] Gen-ART review of draft-ietf-mip4-m… Jari Arkko