Hi Mary, Thanks for your review and comments. Please find responses inline.
On 02/24/2012 04:42 PM, Mary Barnes wrote:
- 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"
Will fix these.
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.
Right. This is because the flag is not specified in this document. It is inherited from the PMIPv6 base specification (RFC5213).
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.
This is actually not required. The localized routing will take place anyway, if needed. The flag only determines whether the MAG will independently initiate localized routing or will it wait for LMA instruction to do so. This document only specifies the behavior when the flag is set to 0 in the A11 case. The behavior for the flag set to 1 in the A11 case is specified in RFC5213.
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]
Sounds good. I will check with IANA for the format. Thanks Suresh _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
