Re: [Gen-art] Gen-ART review:draft-ietf-netext-pmip-lr-08.txt

[Suresh Krishnan <[e-mail]>]

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