Quality-of-Service Option for Proxy Mobile IPv6
draft-ietf-netext-pmip6-qos-12

Thanks to the authors for working out what needed to be done to address my Discuss. It went in a slightly different way than I expected, but the outcome is good.

In Sec 4.2.10, for the TS Format, are there any rules for allocating the values other than 0, 1, and 2?   Most other fields have really good information about this specified.  I realize that the formats are IPv4 and IPv6, so its hard to picture other values, but future-proofing is good.  Not being familiar with the formats, I don't have other examples to hand.

Does the IANA section need more details?  For instance Sec 4.1 has the Operational Code and allocates values and has some reserved for future allocation, but this is not mentioned in the IANA section.  Similarly, Sec 4.2.5 has Preemption capability and Preemption Vulnerability both have 0 and 1 defined and 2 and 3 reserved; how would those be allocated in the future?  Sec 4.2.10, the Traffic Selector Format is another example.

In Section 3.2, I think the emergency services example is over-promising a bit. Assuming that this is a hypothetical example, the idea that a service provider would have a condition imposed on it to "ensure the application traffic associated with emergency services is not impacted under any network condition" seems like a stretch. I would suggest editing this example along the following lines:

      An emergency service may require network
      resources in conditions when the network resources have been fully
      allocated to other users and the network may be experiencing
      severe congestion and in such cases the service provider may want
      to revoke resources that have been allocated and reassign them to
      emergency services.  The local mobility anchor and the mobile
      access gateway negotiate Allocation and Retention Priority (AARP)
      values for the IP sessions associated with the emergency
      applications.  The QoS option (Section 4.1) with the QoS
      Attribute, Allocation-Retention-Priority (Section 4.2.5) are used
      for this purpose.

In Section 4.2.5, the references to "QOS Traffic Selector attribute (Section 4.2.8)" should actually point to 4.2.10 where the QOS Traffic Selector attribute is defined.

In Section 4.2.10, "section 3.1 of [RFC6088]" resolves incorrectly to section 3.1 of the I-D itself, rather than section 3.1 of RFC 6088.

No objection for security, but do want to see the outcome of the other discusses.

- The document is very long and could have been shorter
I'd say. Too late now, but that's a pity.

- 4.2.1: If the n/w can set this, that provides a nice
kind of supercookie, assuming that any host (n/w) will
max out its allocated b/w sometimes. To track user X set
their max b/w to 24.01 Mbps and for their next-door user
Y set the max b/w to 24.09 Mbps. Not sure if you want to
note that but its just one example of many related things.

- I'm sympathetic with Ted's discuss to the effect that
this spec may not be within the WG's charter.

I'm dropping my DISCUSS based on conversations with other IESG members, particularly Brian.   I don't think I will be able to finish the review this morning, but here are my comments up to the point where I stopped:

In Introduction, paragraph 1:

   However, handover
   and IP Flow Mobility using alternative radio access technologies,
   such as IEEE802.16 and Wireless LAN according to the IEEE802.11
   specification, are being considered by the standards [TS23.402],
   whereas inter-working with the cellular architecture to establish QoS
   policies in alternative access networks has not received much
   attention so far.

What does it mean to be "considered by the standards"?   I don't understand this sentence.

In 2.2, the definition for AARP:
      AARP is used in congestion situations when there are no sufficient
      resources for meeting all services requests.  It is used primarily
      by the Admission Control function to determine whether a
      particular service request must be rejected due to lack of
      resources, or if it must be rejected by preempting an existing
      low-priority service.

The second clause of the last sentence looks wrong.   Shouldn't it be "or if it must be satisfied by preempting an existing low-priority service?"