[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>. 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]
- [Gen-art] Gen-ART review:draft-ietf-netext-pmip-l… Mary Barnes
- Re: [Gen-art] Gen-ART review:draft-ietf-netext-pm… Suresh Krishnan