[netext] review of draft-ietf-netext-pmipv6-sipto-option-03

[Marco Liebsch <[e-mail]>]

Please find some comments about the 3rd revision of draft-ietf-netext-pmipv6-sipto-option-03
below.

- Sect 1. Intro, 2nd paragraph: ..IP flows that needs to be.. -> ..that need to be..

- Sect 3. First paragraph: ..HTTP flows may be be offload.. -> ..may be offload..

- Sect 3. Second paragraph: talks about the traffic selector attributes which can be matched
against the fields in the 'IP packet header'. As the TS includes attributes from the
transport header or even deeper in the packet, matching against IP header is not
sufficient. Just write 'matched against the header fields in the data packets'.
Seems less confusing.

- Page 5, reference to the figure 1 should be a reference to Figure 2, as the text
mentions. 'operational sequence'. Then a reference to Figure 1 is missing, which
I would include to the first paragraph of Section 3.

Same page and paragraph: '..access link are not show here' -> '..not shown here..'

General comment:

The current procedure assumes pretty static offload rules. These can be either
recommended by the MAG and approved by the LMA or the LMA provides the
rules. Something like 'all port 80 traffic to be offloaded ', etc. This does not allow
a decision on a flow basis, as the rules are established with the PBU/PBA where no
flow has been initiated yet. Hence, beside well-known ports, information about
port numbers for TS is rather limited.

Maybe an extended use of the proposed option makes sense to support
dynamic decisions about traffic offload. After registration, the MAG may receive
an uplink packet of a new flow and takes decision about an offload policy or requests
the policy from the LMA. The same options can be used (now ports are clear), but
an additional PBU/PBA need to be sent to establish the dynamic rule. The specification
could just consider this in the MAG/LMA operations section.

marco