Last Call Review of draft-ietf-netext-pmip-lr-
review-ietf-netext-pmip-lr-genart-lc-barnes-2012-02-21-00

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]