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

["Sri Gundavelli (sgundave)" <[e-mail]>]

<Resending>

Hi Mary,

Thanks for the review.  Please see inline. Sorry for the delay on this response.


From: Mary Barnes <[e-mail]<mailto:[e-mail]>>
Date: Friday, November 16, 2012 11:12 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Gen-ART review: draft-ietf-netext-pmipv6-sipto-option-07.txt
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, Sri Gundavelli <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Resent-Date: Friday, November 16, 2012 11:12 AM


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

[Sri]:  Ok. Will reword it per your suggestion.



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

[Sri] Its the mobile node. Rephrased as below.


 OLD:
   "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."

NEW:
 "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, the mobile node can choose to use an address from
   that prefix for IP traffic flows that require offload."


Section 2:
- 1st paragraph:  "abbreviations" should be "terms".

[Sri] Ok

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

[Sri] Ok. I can add RFC 2663 reference at the first usage of the term.


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"

[Sri]  Ok


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.

[Sri] Ok.


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

[Sri]  We tried to say that the MAG may also send its own traffic offload policy, this may be locally configured or can come from AAA. Now, when this MAG proposed policy is sent to the LMA, it must be sent using the IPv4 TS option.  How about the following text:


"The mobile access gateway MAY choose to send its proposed IPv4 traffic offload policy to the LMA by using the Traffic Selector sub-option. This IPv4 traffic offload policy may be locally configured at the mobile access gateway, or may have been obtained from the AAA. When this policy is included in the Proxy Binding Update message, it serves as a proposal to the local mobility anchor, which the  local mobility anchor can override with its own offload policy, or agree to the proposed policy that it received from the mobile access gateway."






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

[Sri] Ok


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

[Sri] Ok. Thanks


- 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"?

[Sri]  There is some typo/missing fragment. How about the following:


"The traffic selector sub-option includes the parameters used to match packets for a specific flow binding. The format of the Traffic Selector sub-option is defined in section 4.2.1.4 of [RFC6089]. This sub-option includes a TS Format field, which identifies the format of the flow specification included in that sub-option.  The values for that field are defined in section 3 of [RFC6089] and are repeated here for completeness.  When the value of TS Format field is set to (1), the format that follows is the IPv4 Binary Traffic Selector specified in section 3.1 of  [RFC6089] and that support is mandatory for this specification."



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?

[Sri] The term "Mobility option" is defined in RFC 6275. Its an option that is carried in the IPv6 Mobility Header extension and is generally referred to as "Mobile Header option". Will rephrase as "mobility option".



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

[Sri] Ok


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

[Sri] Ok

Thanks for the review and your help on improving the document quality.


Regards
Sri