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

Request Review of draft-ietf-netext-pmip-lr
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-02-21
Requested 2012-02-09
Other Reviews Secdir Last Call review of - by Carl Wallace (diff)
Review State Completed
Reviewer Mary Barnes
Review review-ietf-netext-pmip-lr-genart-lc-barnes-2012-02-21
Posted at http://www.ietf.org/mail-archive/web/gen-art/current/msg07218.html
Draft last updated 2012-02-21
Review completed: 2012-02-21

Review
review-ietf-netext-pmip-lr-genart-lc-barnes-2012-02-21

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]