I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . 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]