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

From: Mary Barnes <[email-masked]>
Date: Fri, 24 Feb 2012 15:42:50 -0600

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]

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 27 Feb 2012 07:24:55 -0500

Hi Mary,
   Thanks for your review and comments. Please find responses inline.

On 02/24/2012 04:42 PM, Mary Barnes wrote:
> -- Paragraph after Figure 3.  Similar comments as above.  There's only
> one normative statement in that paragraph.
> 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:

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).

>    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

Sounds good. I will check with IANA for the format.

Thanks
Suresh