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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
