[Gen-art] Gen-ART review: draft-ietf-netext-pmipv6-sipto-option-07.txt

[Mary Barnes <[e-mail]>]

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

Please resolve these comments along with any other Last Call comments you
may receive.

Document: draft-ietf-netext-pmipv6-sipto-option-07.txt
Reviewer:  Mary Barnes
Review Date:  16 Nov 2012
IETF LC End Date: 26 Nov 2012

Summary:  Almost Ready - comments/nits.

Minor comments/nits:
--------------------------

Section 1:
- 2nd paragraph
   I don't quite understand the intent of this sentence:
   "Example of such non-essential
   traffic is entirely a policy decision."
   I think you're trying to say that "It's a policy decision as to which
   traffic an operator deems as non-essential."
- 3rd paragraph
   I'm not quite sure what is "it" in the last clause in this sentence
below. Is the "it" the mobile node or the access network?  The "it" should
be replaced with whichever for readability.  Also, adding a "," before the
"which" might help as well.

   "If there is
   proper prefix coloring marking in the Router Advertisement messages
   which allows the mobile node to identify the IPv6 prefix assigned
   from the local access network, it can choose to use an address from
   that prefix for IP traffic flows that require offload."

Section 2:
- 1st paragraph:  "abbreviations" should be "terms".
- It also seems to me that this document doesn't need to define NAT unless
the term is being used in a manner different from the usual meaning. I
think a reference to RFC 2633 at the first usage of NAT would be sufficient.

Section 3:
- 1st paragraph - this sentence needs some fixes:
OLD:
   It is possible, the NAT function is co-located with
   the mobile access gateway, or its located some where in the edge of
   the access network.
NEW:
   It is possible for the NAT function to be co-located with
   the mobile access gateway or located somewhere in the edge of
   the access network.
 - 1st paragraph: "collacted" -> "co-located"

Section 3.2:
- 1st sub-bullet in the second bullet.
I'm not sure what this is trying to say.  Maybe the following change would
help.
OLD:
         Including the IPv4 Traffic Offload
         Selector option in the Proxy Binding Update, but without the
         Traffic Selector Sub-option serves as an indication that the
         mobile access gateway is not proposing any specific offload
         policy for that mobility session, but a request to the local
         mobility anchor to provide the IPv4 traffic offload flow
         selectors for that mobility session.
NEW:
         Including the IPv4 Traffic Offload
         Selector option in the Proxy Binding Update without the
         Traffic Selector Sub-option serves as an indication that the
         mobile access gateway is not proposing any specific offload
         policy for that mobility session, but rather it indicates
         a request to the local
         mobility anchor to provide the IPv4 traffic offload flow
         selectors for that mobility session.

- 2nd sub-bullet in the second bullet, 3rd sentence. I'm not sure what "In
that scenario" is referring to in this sentence:
         In that scenario, the Traffic Selector
         sub-option MUST be present in the IPv4 Traffic Offload Selector
         option (Section 4).
The previous sentence talks about two ways in which the policy may be
configured. Is it referring to one of those specific ways or is it
referring to the 1st sentence - i.e., In the case that the MAG includes its
proposed policy?

- 3rd bullet, 1st sentence - not clear.  Does the following reflect the
intent?
OLD:
      If there is no IPv4 Traffic Offload Selector option in the
      corresponding Proxy Binding Acknowledgement message, that the
      mobile access gateway receives in response to a Proxy Binding
      Update, it serves as an indication that the local mobility anchor
      did not enable IPv4 Traffic Offload support for that mobility
      session, and hence the local mobility anchor did not deliver IPv4
      flow selectors for that mobility session.

NEW:
      Lack of a IPv4 Traffic Offload Selector option in the
      corresponding Proxy Binding Acknowledgement message received by the
      mobile access gateway in response to a Proxy Binding
      Update indicates that the local mobility anchor
      did not enable IPv4 Traffic Offload support for that mobility
      session, and hence the local mobility anchor did not deliver IPv4
      flow selectors for that mobility session.

5th bullet: This one very long sentence needs some work for clarity with
one suggestion below (if I've interpreted the intent correctly):
OLD:
      If configuration variable, EnableIPTrafficOffloadSupport is set to
      a value of (0), and if the mobile access gateway has not included
      the IPv4 Traffic Offload Selector option in the Proxy Binding
      Update, but if the received Proxy Binding Acknowledgement message
      has the IPv4 Traffic Offload Selector option, then the mobile
      access gateway SHOULD ignore the option and process the rest of
      the message as per [RFC5213].
NEW:
      If the configuration variable EnableIPTrafficOffloadSupport
      is set to a value of (0) and the mobile access gateway has not
      included the IPv4 Traffic Offload Selector option in the Proxy
      Binding Update, but has received a Proxy Binding
      Acknowledgement message that has the IPv4 Traffic Offload Selector
      option, then the mobile access gateway SHOULD ignore the option
      and process the rest of the message as per [RFC5213].

- Traffic Selector Sub-option. It's not clear what this sentence is trying
to say:
      "This is an optional
      field when this option is used only a capability hint."
What is a "capability hint"?  That's not mentioned elsewhere in this
document. Also the phrase "is used only a" doesn't make sense.  Should it
be "is used only as a"?

IANA considerations:
- I could not find a definition of a "mobility header option" in RFC 6275.
I believe you are wanting to update the "Mobility Options" registry:
http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xml#mobility-parameters-2
So, really, you are defining a new "Option Type" in the "Mobility Options"
namespace.  Is that correct?

- Note, you also should add a note to section 4 that the RFC editor should
replace <IANA-1> with the number that gets assigned.

Section 6:
- 1st paragraph, 1st sentence: "that control" -> "that controls"