<Resending> Hi Mary,
Thanks for the review. Please see inline. Sorry for the delay on this response. From: Mary Barnes <[email protected]<mailto:[email protected]>> Date: Friday, November 16, 2012 11:12 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Gen-ART review: draft-ietf-netext-pmipv6-sipto-option-07.txt Resent-From: <[email protected]<mailto:[email protected]>> Resent-To: <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, Sri Gundavelli <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>> 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
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
