[Gen-art] Gen-ART review:draft-ietf-netext-pmip-lr-08.txt

Mary Barnes <mary.ietf.barnes@gmail.com> Fri, 24 February 2012 21:42 UTC

Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851AA21F86D9 for <gen-art@ietfa.amsl.com>; Fri, 24 Feb 2012 13:42:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.476
X-Spam-Level:
X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=-1.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, RCVD_IN_DNSWL_LOW=-1, 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 H0BEy+kyIqZm for <gen-art@ietfa.amsl.com>; Fri, 24 Feb 2012 13:42:50 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C50F21F865F for <gen-art@ietf.org>; Fri, 24 Feb 2012 13:42:50 -0800 (PST)
Received: by vcbfk14 with SMTP id fk14so2156698vcb.31 for <gen-art@ietf.org>; Fri, 24 Feb 2012 13:42:50 -0800 (PST)
Received-SPF: pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.52.29.40 as permitted sender) client-ip=10.52.29.40;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.52.29.40 as permitted sender) smtp.mail=mary.ietf.barnes@gmail.com; dkim=pass header.i=mary.ietf.barnes@gmail.com
Received: from mr.google.com ([10.52.29.40]) by 10.52.29.40 with SMTP id g8mr2275501vdh.38.1330119770219 (num_hops = 1); Fri, 24 Feb 2012 13:42:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=zaphI5YU37/bGM5p0u+sCy9NZcyXAO6Aoyg0lofjHw8=; b=QndvE9jOXVBFq46CFTblsLjTInr1SRb5OvjqLdOY2YYRblPQVJm6Ep+avt0WO1GIVA yKnHDySedP490lc8IhILyg8310AQmnWo8S9w+0q2/1MbI8KIqOZ7o8Maxr+bO/Ie5pm7 l+uN1f+XUm9EQehnWdiTRIXTiwgG5z9m/ESyQ=
MIME-Version: 1.0
Received: by 10.52.29.40 with SMTP id g8mr1802111vdh.38.1330119770163; Fri, 24 Feb 2012 13:42:50 -0800 (PST)
Received: by 10.52.114.200 with HTTP; Fri, 24 Feb 2012 13:42:50 -0800 (PST)
Date: Fri, 24 Feb 2012 15:42:50 -0600
Message-ID: <CAHBDyN7azfTJnNa3uuTHSrss49q2TdosRAu3xw8baBHdfjHW7Q@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: draft-ietf-netext-pmip-lr.all@tools.ietf.org
Content-Type: multipart/alternative; boundary=20cf307ca41868c88804b9bca460
Cc: gen-art@ietf.org
Subject: [Gen-art] Gen-ART review:draft-ietf-netext-pmip-lr-08.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Feb 2012 21:42:51 -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>gt;.

Document: draft-ietf-netext-pmip-lr-08.txt
Reviewer:  Mary Barnes
Review Date:  24 Feb 2012
IETF LC End Date: 21 Feb 2012
IESG Telechat Date: 01 March 2012

Summary:  Almost ready.

Minor issues:

1) General: There is an inconsistent usage and lack of normative language
in parts of the document.  The following summarizes the majority of the
cases that I encountered:
- Section 4:
-- Text after Figure 2 (before section 4.1).  There is no normative
language in these paragraphs.
--- For example in the first paragraph, I would expect that the elements
that ought to be included in the messages should be specified as "MUST
contain…". And, rather than "The LMA sends…", I would think it would be
"The LMA MUST send…"
--- 2nd paragraph: I would expect to see "…MUST send an LRA with status
code…" , "MUST then create Localized Routing Entries…" .  There's also a
"should contain" that I think ought to be "SHOULD contain"
--- 5th paragraph:  First sentence:
"and responds with.."  -> "MUST respond with"
and it seems that there is some other normative language that could be
added throughout that paragraph.

- Section 4.1:
-- 1st para, 1st sentence:  "needs to be" -> "MUST be"

- Section 5:
-- Paragraph after Figure 3.  Similar comments as above.  There's only one
normative statement in that paragraph.
-- Section 5.1:  "needs to be" ->  "MUST be", "It will hence initiate" ->
 "It MUST initiate LR.

- Section 6:
-- First paragraph after Figure 5:  "routing has to be initialized" ->
"routing MUST be initialized"
-- 2nd paragraph:  It would seem that somewhere it should be stated that
the Status value MUST be set to zero.  Also, I don't the the last MUST in
that paragraph is normative.  I would think it could be a "can" and maybe
the "it can provide" is where the MUST should be.

- Section 6.1:
-- "needs to be" -> "MUST be"

- Section 7:
-- last sentence: should the recommended be upper case?

- Section 8: shouldn't  the "must add the IPv4 HOAs" be a "MUST"

- Section 9.1: "The LMA sends.." -> "The LMA MUST send", "The MAG may…" ->
"The MAG MAY…"

- Section 9.2: "The MAG sends…" -> "The MAG MUST send", "An LMA may send"
-> "An LMA MAY send"

- Section 11:  "using IPSEC is required" -> "using IPSEC is REQUIRED"



2) Section 4: last sentence of paragraph after Figure 1.   The use of the
EnableMAGLocalRouting flag seems key to whether this functionality is
applied in some of the cases. It's first introduced as a "Please note",
although, it is clearly (but not normatively) specified in the 2nd
paragraph after Figure 2.

I would think it would be helpful to introduce this functionality in
section 2, specifically in Section 2.1 by adding something like the
following after the first sentence of that paragraph:
  The MAG MUST set the EnableMAGLocalRouting to a value of 1.

3) IANA Considerations: My understanding is that IANA wants a list of the
necessary registrations in the same form as they would appear in the
registries (per RFC 5226)  - i.e., something like:

Value      Description                                      Reference
-----          -----------
 -----------------
TBD1       Localized Routing Initiation             [RFCXXXX]
TBD2       Localized Routing Acknowledgment [RFCXXXX]