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"
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
