IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6
draft-ietf-netext-pmipv6-sipto-option-12

[Ballot comment]
Discuss position cleared 2013-02-15.

While technically non-blocking, I would like the authors, the
shepherd and the WG to consider them carefully as the document is
revised.

In my opinion, the document overspecifies some aspects of the protocol
and includes redundant or otherwise unnecessary text.

For example, sections 3.1 and 3.2 go into far more detail than
required, and include unnecessary and untestable implementation
details.  Those two sections could be simply specified by text like:

  If the MAG is configured for offload, it includes an IPv4TS in its
  PBU sent to the LMA and installs the policy received in the IPv4TS
  in the PBA from the LMA.  The MAG may provide a suggested policy in
  the IPv4TS it sends to the LMA.  The MAG MUST install the policy
  received in the IPv4TS from the LMA, even if that policy is
  different from a suggested policy.

  The MAG MAY install a policy received in the IPv4TS in the PBA from
  the LMA if the MAG did not include an IPv4TS in the PBU.

  If the LMA receives a PBU that includes an IPv4TS, it determines
  the offload policy for the MN and returns it in an IPv4TS the PBA.
  The LMA MAY include an IPv4TS if the PBU does not include an
  IPv4TS.

As another example, the discussion of how IPv6 offload might work is
distracting.  Simply say it's out of scope for this document.

A nit in section 3:

  The parameters in the IP traffic selectors
  can be used to match against the header fields in the data packets.

"are used by the MAG"?  Otherwise, what's the point?

[Ballot discuss]
1. cleared

2. cleared

3. How does the offload routing work?  As I understand PMIP6:

  * inbound traffic to A is delivered to LMA-A, which has advertised
    the prefix to which A's IP address belongs
  * offloaded traffic to A will arrive at either the NAT or be
    generated by an internal source inside the NAT
  * how does this traffic (NAT or internal) get routed to the MAG
    instead of the LMA?

(edited 2013/02/14) Restating: I don't understand how traffic for
the MN gets routed from an internal host or the "internal" NAT
interface to the MAG to be forwarded to the MN.

4. cleared

[Ballot comment]
This version removes the really egregious uses of 2119 to impose particular implementation style. Thanks for that. There are some remaining silly ones in 3.2 and 3.3 that I hope you will fix:

3.2:

OLD
  o  If the mobile access gateway is configured to support IPv4 Traffic
      Offload support, then it SHOULD include the IPv4 Traffic Offload
      Selector option (Section 3.1) in the Proxy Binding Update message
      that it sends to the local mobility anchor.
NEW
  o  If the mobile access gateway is configured to support IPv4 Traffic
      Offload support, then it includes the IPv4 Traffic Offload
      Selector option (Section 3.1) in the Proxy Binding Update message
      that it sends to the local mobility anchor.

I don't really understand what the SHOULD was doing there in the first place. Are there circumstances where the MAG wouldn't include the selector? Either way, this is simply a description of actions to be taken, not a warning to implementers about what the MUST or SHOULD do.

OLD
        In this scenario, the
        IPv4 Traffic Offload Selector option that is carried in the
        Proxy Binding Update message MUST NOT include the Traffic
        Selector sub-option (Section 3.1) and the (M) flag Section 3.1
        in the option MUST be set to value of (0).
NEW
        In this scenario, the
        IPv4 Traffic Offload Selector option that is carried in the
        Proxy Binding Update message does not include the Traffic
        Selector sub-option (Section 3.1) and the (M) flag Section 3.1
        in the option is set to value of (0).

As above.

3.3:

OLD
  o  If the Proxy Binding Update message includes the IPv4 Traffic
      Offload Selector option, but if the local mobility anchor is not
      configured to support IPv4 Traffic Offload support, then the local
      mobility anchor MUST ignore the option and process the rest of the
      message as per [RFC5213].
NEW
  o  If the Proxy Binding Update message includes the IPv4 Traffic
      Offload Selector option, but the local mobility anchor is not
      configured to support IPv4 Traffic Offload support, then the local
      mobility anchor will ignore the option and process the rest of the
      message as per [RFC5213].

The LMA doesn't have to make a choice whether to ignore the option. It always ignores the option because it's not configured to support it. So telling it that it MUST ignore the option is silly.

OLD
  o  If the Proxy Binding Update message has the IPv4 Traffic Offload
      Selector option and if the local mobility anchor is configured to
      support IPv4 Traffic Offload support, then the local mobility
      anchor MUST enable IPv4 Traffic Offload support for that mobility
      session.  The Proxy Binding Acknowledgement message that will be
      sent in response MUST include the IPv4 Traffic Offload Selector
      option.
NEW
  o  If the Proxy Binding Update message has the IPv4 Traffic Offload
      Selector option and the local mobility anchor accepts the request,
      then the local mobility anchor enables IPv4 Traffic Offload
      support for that mobility session and sends a Proxy Binding
      Acknowledgement message in response that includes the IPv4 Traffic
      Offload Selector option.

The first MUST worries me. You are not telling me that I can't build an LMA that ignores offload requests from certain MAGs, are you? I can't believe that this would be a protocol violation. The second MUST is just unnecessary.

[Ballot comment]

comments not updated for -09 so may be fixed already (or
wrong;-)

- 3.1 and elsewhere, it seems wrong to talk about configuration
variables like EnableIPTrafficOffloadSupport since that's
implementation specific. That would be better changed to say
e.g. "If the LMA is configured to turn on offloading..." or
similar.

- 3.1, last para: why is this only a SHOULD NOT and when would
it be ok to send back the selection option if it wasn't
requested by the MAG? Given that the MAG SHOULD ignore this
anyway (last para of 3.2) this seems to add complexity for no
real benefit.

- sections 3 & 4, "M" flag - why are these SHOULDs?  Wouldn't
all MUSTs be cleaner?

- section 4: repeating text from rfc 6089 is fine, but
shouldn't you say whether that or the text here takes
precedence in the event that e.g. 6089 is updated or obsoleted?
(And which is the repeated text anyway, that's not clear to me
at least.)

- Some examples would be good, esp. for something a bit complex
but likely to be wanted, e.g. offload all HTTP except these
servers on port 443, if that's supported. (Its not clear to me
to be honest.)

[Ballot discuss]
In section 3.1, it says:

  o  If the configuration variable, EnableIPTrafficOffloadSupport
      (Section 6) on the local mobility anchor is set to a value of (0),
      then the local mobility anchor SHOULD NOT...
     
      ...if the
      configuration variable, EnableIPTrafficOffloadSupport (Section 6)
      on the local mobility anchor is set to a value of (1), then the
      local mobility anchor SHOULD NOT...
     
and in section 3.2:

  o  If the configuration variable, EnableIPTrafficOffloadSupport on
      the mobile access gateway is set to a value of (0), then the
      mobile access gateway SHOULD NOT...

  o  If the configuration variable, EnableIPTrafficOffloadSupport on
      the mobile access gateway is set to a value of (1), then the
      mobile access gateway SHOULD...

What interoperability failure or network harm occurs if an implementation ignores the settings of these "configuration variables"? As far as I can tell, these are local configuration and implementation issues and not suitable for protocol requirements. Therefore, 2119 text should be removed.

I have a sneaking suspicion that most of the 2119 language in this document is being "used to try to impose a particular method on implementors where the method is not required for interoperability" [2119, section 6], which is inappropriate.

[Ballot discuss]

1. I don't see any description of how the LMA can dynamically update
the traffic selectors.

2. Is it true that a traffic selector installed as a result of MN A
attaching to a MAG might affect the traffic from MN B?  If I have that
right, it would be surprising (to me, anyway).

3. How does the offload routing work?  As I understand PMIP6:

  * inbound traffic to A is delivered to LMA-A, which has advertised
    the prefix to which A's IP address belongs
  * offloaded traffic to A will arrive at either the NAT or be
    generated by an internal source inside the NAT
  * how does this traffic (NAT or internal) get routed to the MAG
    instead of the LMA?

4. I agree with other Discuss positions that a mechanism through which
an LMA can know exactly what offload traffic selectors the MAG has
installed is probably required.  I'd like to know if the WG considered
that specific issue.  Experience with, e.g., DHCP has shown that in
some instances, it's critical to know exactly what the client (in this
case the MAG) has accepted as configuration.

[Ballot comment]
While technically non-blocking, I would like the authors, the
shepherd and the WG to consider them carefully as the document is
revised.

In my opinion, the document overspecifies some aspects of the protocol
and includes redundant or otherwise unnecessary text.

For example, sections 3.1 and 3.2 go into far more detail than
required, and include unnecessary and untestable implementation
details.  Those two sections could be simply specified by text like:

  If the MAG is configured for offload, it includes an IPv4TS in its
  PBU sent to the LMA and installs the policy received in the IPv4TS
  in the PBA from the LMA.  The MAG may provide a suggested policy in
  the IPv4TS it sends to the LMA.  The MAG MUST install the policy
  received in the IPv4TS from the LMA, even if that policy is
  different from a suggested policy.

  The MAG MAY install a policy received in the IPv4TS in the PBA from
  the LMA if the MAG did not include an IPv4TS in the PBU.

  If the LMA receives a PBU that includes an IPv4TS, it determines
  the offload policy for the MN and returns it in an IPv4TS the PBA.
  The LMA MAY include an IPv4TS if the PBU does not include an
  IPv4TS.

As another example, the discussion of how IPv6 offload might work is
distracting.  Simply say it's out of scope for this document.

A nit in section 3:

  The parameters in the IP traffic selectors
  can be used to match against the header fields in the data packets.

"are used by the MAG"?  Otherwise, what's the point?

[Ballot discuss]
In section 3.1, it says:

  o  If the configuration variable, EnableIPTrafficOffloadSupport
      (Section 6) on the local mobility anchor is set to a value of (0),
      then the local mobility anchor MUST NOT...
     
      ...if the
      configuration variable, EnableIPTrafficOffloadSupport (Section 6)
      on the local mobility anchor is set to a value of (1), then the
      local mobility anchor SHOULD NOT...
     
and in section 3.2:

  o  If the configuration variable, EnableIPTrafficOffloadSupport on
      the mobile access gateway is set to a value of (0), then the
      mobile access gateway MUST NOT...

  o  If the configuration variable, EnableIPTrafficOffloadSupport on
      the mobile access gateway is set to a value of (1), then the
      mobile access gateway MUST...

What interoperability failure or network harm occurs if an implementation ignores the settings of these "configuration variables"? As far as I can tell, these are local configuration and implementation issues and not suitable for protocol requirements.

I have a sneaking suspicion that most of the 2119 language in this document is being "used to try to impose a particular method on implementors where the method is not required for interoperability" [2119, section 6], which is inappropriate, but I'd like to start with an explanation of why the above constitute a protocol requirement.

[Ballot comment]
Updated

I'd echo this draft was a bit of a challenge to follow.  if you look at the protocol flow in f2, I'd have expected to read about the MAG first since it starts the protocol instead you went with the LMA.  Then in the LMA section instead of going with what it has to deal with when it receives something from the MAG you go with what the LMA must not send.  Just a bit backward for me - but this is just a comment so do with it what you will.

If the definition for IP Flow from 5101 can't be used maybe the one from 3917?

I also didn't follow how you handle a case where an LMA overrides what the MAG tries to set up and the MAG doesn't support it.

drafts says:

"This option is carried like any other
  mobility header option as specified in [RFC5213] and does not require
  any special security considerations."

It's misleading IMHO. This option does require security considerations
since an attacker, by sending fake signaling messages, may prevent
a mobile network from offloading traffic which may lead to a DoS.
You'd better say something like:

"This option is carried like any other
  mobility header option as specified in [RFC5213].
  Therefore it inherits from [RFC5213] its security guidelines
  and does not require any additional security considerations."

Typos:
Section 1:
s/its only about IPv4/it is only about IPv4/

[Ballot comment]
I'd echo this draft was a bit of a challenge to follow.  if you look at the protocol flow in f2, I'd have expected to read about the MAG first since it starts the protocol instead you went with the LMA.  Then in the LMA section instead of going with what it has to deal with when it receives something from the MAG you go with what the LMA must not send.  Just a bit backward for me - but this is just a comment so do with it what you will.

If the definition for IP Flow from 5101 can't be used maybe the one from 3917?

I also didn't follow how you handle a case where an LMA overrides what the MAG tries to set up and the MAG doesn't support it.

[Ballot discuss]
It seems that the NAT function coexistent with the MAG would cause flows to break during mobility events between MAGs, which would sort of defeat the purpose entirely of using MIP technology to allow the same HoA to be used regardless of the current connection point.

The document does not seem to talk about mobility across MAGs and how that handover would be supported since there is now additional state being built-up in the MAGs.  The step-by-step process of how this works and what happens to the packet flows while it's happening seems to be completely missing.

[Ballot comment]
I share Benoit's readability concerns, and Stephen's concern with underspecification.

In Figure 1, I think it would be more clear for the LMA and NAT to connect to the same Internet cloud and show a CN at the other side of that cloud.

[Ballot comment]
Slightly puzzled...
In the IPv4 Traffic Offload Selector Option you have

      The traffic selector sub-option includes the parameters used to
      match packets for a specific flow binding.  This is an optional
      field when this option is used only a capability hint.

There is only one other field in the IPv4 Traffic Offload Selector
Option and that is the M bit which describes how to interpret the
traffic selector sub-option. So, it the traffic selector sub-option is
optional, then what is the purpose of the whole IPv4 Traffic Offload
Selector Option?

[Ballot discuss]
I found that draft extremely difficult to read: the reading flow is not logical. Multiple times while reading the draft, I found myself guessing.
Let me show you a few examples:

1. Starting from the abstract

  This specification defines a traffic offload mechanism and a related
  mobility option for carrying IPv4 Offload traffic selectors between a
  mobile access gateway and a local mobility anchor in a Proxy Mobile
  IPv6 domain. 

The direction is: from the LMA to MAG, to be synchronized on all MAGs where the user connects. I was already confused when reading the abstract.
And the following figure didn't make it clear, as the point 5 doesn't have a direction (I now understand that this is logical step, not a protocol step).

  MN    MAG(NAT)  LMA
  |------>|        |    1. Mobile Node Attach
  |      |------->|    2. Proxy Binding Update (IPv4TS)
  |      |<-------|    3. Proxy Binding Acknowledgement (IPv4TS)
  |      |========|    4. Tunnel/Route Setup
  |      +        |    5. Installing the traffic offload rules
  |------>|        |    6. IPv4 packet from mobile node
  |      +        |    7. Forwarding rule - Tunnel home/offload
  |      |        |

When reading this figure 2, it's not clear yet that the IPv4 Traffic Offload Selector option are in the Proxy Binding Acknowledgement message. So this is even confusing...


2. Another proof that the flow is not right
Section 3.2
 

    *  If the (M) flag of the IPv4 Traffic Offload Selector option in
        the received Proxy Binding Acknowledgement is set to a value
        (0), then the mobile access gateway SHOULD offload all the
        mobile node's IPv4 flows identified using the flow selectors
        present in the Traffic Selector Sub-option.  The mobile access
        gateway SHOULD tunnel all other mobile node's IPv4 flows to the
        local mobility anchor.

And I will only know about the flag in a later section.

3. And a final proof

4. IPv4 Traffic Offload Selector Option

  A new mobility option, IPv4 Traffic Offload Selector option, is
  defined for using it in Proxy Binding Update (PBU) and Proxy Binding
  Acknowledgement (PBA) messages exchanged between a mobile access
  gateway and a local mobility anchor.

In section 4, I finally learned that "is defined for using it in Proxy Binding Update (PBU) and Proxy Binding Acknowledgement (PBA)"

A logical flow would be:
    which problem do we try to solve? use cases
    protocol limitations
    goal: we will define a Traffic Selector sub-option in the IPv4 Traffic Offload Selector option.
    how it work: protocol spec.
    LMA considerations
    MAG considerations
    limitations: IPv4, encryption
Half through the draft, I had to call a friend to give some background information. 

Coming back to the use cases:

    -  "Currently, there is no mechanism for allowing some of the subscriber's IP flows to be offloaded in the access network."
    "Example of such non-essential traffic is entirely a policy decision".

However, it would be more interesting with a least one specific use case.
You mentioned:

  For example, all the HTTP flows may be
  offloaded at the mobile access gateway and all the other flows for
  that mobility session are tunneled back to the local mobility anchor.

But what is the use case? Improved QoE?
Another way to express my concern. The figure mentions "Services requiring mobility, or service treatment", but what are those services that require mobility?

- As mentioned by Scott Bradner in his OPS-Diretorate review:

Performing an IPv4 traffic offload, by definition, means that at least some IPv4 to and from a mobile node will not be exchanged with
the Internet through the home network and any firewall and other protections that are operated by the home network.
This exposes the mobile node to some security risks.  I suggest that some mention of this be made in the Security Considerations section.

- As mentioned by Scott Bradner in his OPS-Diretorate review:

Doing traffic offload may complicate debugging of connectivity issues.  Filtering at the remote site (access network) could mean
that IPv4 connectivity is different than IPv4 connectivity through the home network (this is a variant of the first issue but
focused on debugging problems not the security implications.  It might be helpful to include a short section discussing this issue.

I do a traceroute: which route shall it take? Some applications will take the offload path, and some other won't.
Now I use active probing (OWAMP, TWAMP, or IP SLA): if I don't match exactly the selector fields, the active probing will not take the same path as the application.
If I go one step further, i.e. using this offload mechanism per DPI application (because I guess this is the end goal), this implies that the active probing will not work any longer to emulate a specific application.
Hence, one of my question about the use case: QoE
My active probing tests will test me: your QoE is fine, while in practice, it's not...

I really would like to view an "operational aspects" section discussing those aspects.

[Ballot comment]
- Instead of having a new IP Flow definition, does the RFC5101 one satisfies your need?

- Are you sure that you will never need this for IPv6

EnableIPTrafficOffloadSupport

        This flag indicates whether or not IPv4 Traffic Offload support
        needs to be enabled

Don't you want to call that EnableIPv4TrafficOffloadSupport

- Section 6

If the flag is set to a
value of (0), the mobile access gateway MUST NOT enable IPv4
        Traffic Offload support for any mobility session.  It MUST NOT
        include the IPv4 Traffic Offload Selector option in the Proxy
        Binding Update.

General comment on section 6: Why do you repeat what you have already specified in section 3.1 (and section 3.2).

[Ballot comment]
This was a difficult read.  I have to strongly agree with the document shepherd, who says in the writeup, "The readbility of the document could be improved. As part of the chair review this has been suggested to the authors."  That said, I think the RFC Editor can deal with the situation, and I have no objection to approving this document.  Just some non-blocking comments that I'd like the authors to consider:

-- Section 1 --
  A given operator may choose
  to offload all traffic except that which requires QoS services (Ex:
  Voice over IP traffic), or may choose to offload all HTTP traffic.

It's not clear whether VoIP is an example of what the operator *would* offload, or of what they wouldn't.  I gather it's the latter.  It's also possible to read this as having to choose one of these options or the other (everything except QoS traffic, or HTTP traffic).  In fact, you're just giving examples.  Why not try this?:

NEW
  One operator might choose
  to offload everything except traffic (such as Voice over IP) that
  requires QoS services.  Another might choose to offload only HTTP
  traffic.


-- Section 1 --
  This approach has one limitation with respect to
  identifying encrypted traffic.  IPsec encrypted traffic with no
  visibility into the application payload cannot be selected for
  offload.

The first sentence introduces the second, and the second specifies what's said in the first (they're not two independent things).  In this case, it's better to write them as one sentence with a colon, rather than as two sentences:

NEW
  This approach has one limitation with respect to
  identifying encrypted traffic: IPsec encrypted traffic with no
  visibility into the application payload cannot be selected for
  offload.


-- Section 1, Last paragraph --
Is there a reference you can cite for prefix coloring work?


-- Section 3 --
You should refer to Figure 1 somewhere in the text.


-- Section 5 --
I recommend adding a second paragraph, to make sure this isn't forgotten:

  RFC Editor: please replace "" in Section 4 with the
  assigned value, and remove this paragraph.

[Ballot discuss]

Maybe I'm confused, (fairly likely with me:-) but the protocol
seems to be underspecified in at least these respects:

(1) Are MAGs (and LMAs) supposed to fully implement all the
IPv4 parts of 6088/6089 for this? E.g. 6088 allows one to
specify protocol numbers - what if PIM were to be offloaded?
What about all of UDP or just DHCP? What about
dest=255.255.255.255?  Do you need text about that kind of
thing and specifically about what kinds of offloading need to
be supported at the MAG?

(2) How do you handle a case where an LMA asks for stuff to be
offloaded that a MAG doesn't support?

[Ballot comment]

- 3.1 and elsewhere, it seems wrong to talk about configuration
variables like EnableIPTrafficOffloadSupport since that's
implementation specific. That would be better changed to say
e.g. "If the LMA is configured to turn on offloading..." or
similar.

- 3.1, last para: why is this only a SHOULD NOT and when would
it be ok to send back the selection option if it wasn't
requested by the MAG? Given that the MAG SHOULD ignore this
anyway (last para of 3.2) this seems to add complexity for no
real benefit.

- sections 3 & 4, "M" flag - why are these SHOULDs?  Wouldn't
all MUSTs be cleaner?

- section 4: repeating text from rfc 6089 is fine, but
shouldn't you say whether that or the text here takes
precedence in the event that e.g. 6089 is updated or obsoleted?
(And which is the repeated text anyway, that's not clear to me
at least.)

- Some examples would be good, esp. for something a bit complex
but likely to be wanted, e.g. offload all HTTP except these
servers on port 443, if that's supported. (Its not clear to me
to be honest.)

IANA has reviewed draft-ietf-netext-pmipv6-sipto-option-07 and has
the following comments:

IANA understands that, upon approval of this document, there is
a single action which IANA must complete.

In the Mobility Options subregistry of the Mobile IPv6 Parameters registry
located at:

http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xml

A new Mobility Option is to be registered as follows:

Value: [ tbd ]
Description: IPv4 Traffic Offload Selector
Reference [ RFC-to-be ]

IANA understands that, upon approval of this document, this is the only
action that IANA is required to complete.

Note: The actions requested in this document will not be completed until
the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6) to Proposed Standard


The IESG has received a request from the Network-Based Mobility
Extensions WG (netext) to consider the following document:
- 'IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-11-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This specification defines a traffic offload mechanism and a related
  mobility option for carrying IPv4 Offload traffic selectors between a
  mobile access gateway and a local mobility anchor in a Proxy Mobile
  IPv6 domain.  Based on the negotiated IPv4 traffic offload flow
  selectors with the local mobility anchor, a mobile access gateway can
  enable offload traffic rule on the selected IPv4 flows.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netext-pmipv6-sipto-option/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netext-pmipv6-sipto-option/ballot/


No IPR declarations have been submitted directly on this I-D.

All,
    I have performed my initial AD review of this document as a part of the publication process.  Below you will find my comments/questions on this draft.  I will put the draft in "Revised ID needed" state, but feel free to discuss with me any/all points raised below.

Substantive
-----------

1. Section 1, 3rd paragraph: Will describing the NAT as an "anchor point" cause any confusion?  Are there any functions performed by an LMA that are generally expected that will be lost when offloading is in use?

2. Section 2.2 : Would it make sense to leverage the definition of IP Flow that has been standardized within the IPFIX community?  That definition is in RFC 5101 and seems to fit with what is currently in this draft.

3. Section 3 : Do you really expect that 100% of all offloaded IPv4 traffic will need to be NATted?  If so, it would be good to provide some justification (e.g., impact on routing/forwarding).  If not, how would the MAG know if a NAT is needed?

4. Figure 2 : I think it would be worthwhile to note that the Proxy Binding Update can include the IPTS Option.  That makes the message exchange illustration match the text in sections 3.1 and 3.2.

5. Section 3.1 : For completeness, I would change the first bullet to say that the LMA MUST not respond with an IPTS Option if its EnableIPTrafficOffloadSupport flag has a value of 0, regardless of whether an IPTS Option exists in the Update message or not.

6. Section 3.2 : I would suggest re-organizing the points in the bulleted list.  The first bullet should simply discuss what the MAG can do if its configuration variable is 0.  The remaining text (starting with the sentence "Otherwise, the option...") should be in a separate bullet describing the actions if the config variable is 1.  The current 2nd bullet and the last sentence of the current first bullet should be sub-bullets that describe the structure of the option with the various possible values of the TS Format field.  The fourth bullet of this section is a little loose.  It currently says that identified flows "have to be offloaded".  I would tighten this up with a 2119 keyword (MUST or SHOULD).  The fifth bullet seems confusing. If the MAG is not capable of performing offloading or is configured to not offload, why is the guidance to ignore the option a SHOULD?

7. IANA Considerations : Does Action-2 relate to the TS Format field values?  I don't see a mention of Sub-type in the IPTS Option definition.

Editorial
---------

1. The second sentence of the Introduction is a fragment.

2. 2nd Paragraph of Introduction:
    * s/where ever/wherever/
    * s/as supposed/as opposed/
    * s/potentially deliver/deliver/
    * s/except that requires/except that which requires

3. 3rd Paragraph of Introduction:
    * s/IP traffic flows need to be/IP traffic flows may need to be/

4. 1st Paragraph of Section 3:
    * s/collocated/co-located/

5. Section 3.1 : expand first use of PCRF

6. Section 4
    * s/defined for using it in/defined for use in/


Regards,
Brian

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Type of RFC being requested: Proposed Standard
The I-D proposes a new option to be included for use in Proxy Mobile
IPv6 signalng (RFC5213) and hence a proposed standard status is being
requested for the document.
The title page header of the I-D requests a Proposed standard status
for the RFC.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  This specification defines a mechanism and a related mobility option
  for carrying IPv4 Offload traffic selectors between a mobile access
  gateway and a local mobility anchor in a Proxy Mobile IPv6 domain.
  Based on the received offload flow selectors from the local mobility
  anchor, a mobile access gateway can enable offload traffic rule on
  the selected IPv4 flows.

  The intent of the option being defined in this I-D is to enable
  IPv4 traffic associated with a mobile node to be routed from the
  access network itself instead of having to tunnel it back to the
  home network (Local Mobility Agent).

Working Group Summary:

Was there anything in WG process that is worth noting? For example,
was there controversy about particular points or were there decisions
where the consensus was particularly rough?

There is nothing unusual about this I-D or WG process w.r.t this I-D
that is noteworthy. The I-D has been presented and discussed at
various IETF meetings and has been reviewed by several WG members and
chair. Since one of the co-authors (Rajeev Koodli) is also a Netext WG
chair, he has recused himself from the review or shepherding process
and I am acting as the sole chair with responsibility for this I-D.

Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Document shepherd: Basavaraj Patil (NetExt WG Co-chair)
Responsible AD: Brian Haberman

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I (Basavaraj Patil) have reviewed the I-D multiple times and provided
feedback to the authors. The authors have made efforts to address my
comments and resolve them. The current version of the I-D is ready to
be progressed to the IESG since the proposed option/extension to Proxy
MIP6 signaling is quite clear as specified in the I-D. The authors are
likely to revise the I-D further based on some additional comments
that I have sent them. However I believe that the I-D in its current
state is ready for IESG review.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. The I-D has been reviewed by WG members who understand the
protocol well as well as people outside the WG.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

There is some ambiguity regarding the interaction with policy servers
and protocols used for such. However the I-D clearly indicates that
such interaction is out of scope of this I-D. The focus of this I-D is
to specify the option that allows selective IPv4 traffic offloading
using NAT functionality in the access network. And hence the policy
aspects which are described in the I-D are not part of the core
functionality being specified here.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

As document shepherd, I have expressed some reservations about parts
of the I-D which explain how an LMA sets the traffic selectors or how
a MAG chooses the traffic selectors to be sent as a proposal in the
request. The WG has discussed these issues in the past and I have
raised the same with the authors. There are no concerns about these
scenarios and it is okay to advance the document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

Each author has confirmed that all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and 79
have been met.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

There is strong WG consensus behind this I-D. While a few are very
vocal and strongly support it the WG as a whole understands its need and
supports it.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

None.

As per IDnits tool:  Summary: 0 errors (**), 0 warnings (==), 1 comment
(--).

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

The document does not define any MIBS, media types or URI types.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

No. All normative references are existing RFCs.

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

No.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

No. Publication of this document will not change the status of
existing Proxy Mobile IPv6 RFCs. This is an extension to RFC5213 and
does not affect the base protocol.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

I have reviewed the IANA considerations section and it is consistent
with the body of the document. The instructions for assignment by IANA
are clear.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

No new IANA registries are needed or require expert review for future
allocations.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Document does not specify any XML code, BNF rules or, MIB definitions
and hence no such reviews have been performed.

Hello,

This is the working group last call for the I-D:
IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6


Abstract

  This specification defines a mechanism and a related mobility option
  for carrying IPv4 Offload traffic selectors between a mobile access
  gateway and a local mobility anchor in a Proxy Mobile IPv6 domain.
  Based on the received offload flow selectors from the local mobility
  anchor, a mobile access gateway can enable offload traffic rule on
  the selected IPv4 flows.

The I-D is intended for publication as a proposed standard.
The deadline for receiving reviews, comments, feedback is June 8th,
2012.

Please send your review comments to the mailing list, chairs or,
authors.

-Chairs