Pat Calhoun wrote:
> > I can't find any mention of "WMM Information Element" in IEEE
> > 802.11-2007 -- I assumed it's some extension that not everyone
> implements?
> 
> Yup - my bad. Now include a reference to the WMM web page on 
> www.wi-fi.org.

So the current binding isn't just IEEE Std 802.11-2007, but
802.11-2007 plus some Wi-Fi Alliance spec?  (That OK with me, but really needs 
to be said in the introduction section.)

> > BTW, how are you planning to update these rules without breaking 
> > backwards compatibility?
> 
> There are a couple of ways, but the most obvious one would be to have 
> the next binding use a new Wireless Binding Identifier (WBID).

With a 5-bit WBID field, and lots of activity in the 802.11xy/16xy space, this 
could mean running out of WBIDs...
<snip>

<snip>
> > In this case, it seems both "Update Station QoS" and "WTP Quality of 
> > Service" message elements apply to same packets -- how do they 
> > interact?
> 
> I have added addition verbage to make this clearer:
> 
> <new text>
> 6.20.  IEEE 802.11 Update Station QoS
> 
>    The IEEE 802.11 Update Station QoS message element is used to
>    change the Quality of Service policy on the WTP for a given
>    station.  The QoS tags included in this message element are to be
>    applied to packets received at the WTP from the station indicated
>    through the MAC Address field.  This message element overrides
>    the default values provided through the IEEE 802.11 WTP Quality
>    of Service message element (see Section 6.22.  Any tagging
>    performed by the WTP MUST be directly applied to the packets
>    receive from the station, as well as the CAPWAP tunnel, if the
>    packets are tunneled to the AC.

I think the tagging text still needs some details. Is the intent something 
like this?

1. If doing split MAC with native frame tunnel mode (instead of 802.3): 
   replace the TID subfield of the packet with the "802.1p Tag" value 
   (except if 'C' bit in IEEE 802.11 Station Session Key message
   element is set)
2. If doing local MAC: if the WTP adds an 802.1Q header for VLAN use
   (based on VLAN Name in the Add Station message element), place 
   the "802.1p Tag" value in the 802.1Q header.
3. If doing split MAC: if the WTP adds an 802.1Q header for VLAN  
   use (based on e.g. some local configuration), place the 
   "802.1p Tag" value in the 802.1Q header.
4. If the packet received from the STA is an IPv4 or IPv6 packet, 
   replace the DSCP field in the IP header with the "DSCP Tag" 
   value (except if 'C' bit is set)
5. For split MAC, place the "DSCP Tag" value in the IP header 
   added by the WTP for CAPWAP Data message.

Note that here step 1 seems unnecessary -- replacing the TID before the AC 
sees it doesn't seem to add value -- and step 4 is very likely to raise 
questions in IESG review (as it overwrites the DSCP tagging done by the STA).

(But perhaps I understood this wrong, and some other processing was intended?)

> 
> [...]
> 
> 6.22.  IEEE 802.11 WTP Quality of Service
> 
>    The IEEE 802.11 WTP Quality of Service message element value is 
> sent
>    by the AC to the WTP to communicate quality of service 
> configuration
>    information.  The QoS tag included in this message element are the
>    default QoS values to be applied to packets received by the WTP 
> from
>    stations on a particular radio.  Any tagging performed by the WTP
>    MUST be directly applied to the packets receive from the station, 
> as
>    well as the CAPWAP tunnel, if the packets are tunneled to the AC.
> </new text>

Same ambiguity here; perhaps instead of repeating the detail, a pointer to 
6.20 woul be sufficient.

> > I'm also slightly surprised to see the WTP modifying the contents of 
> > IP packets here -- I thought it was acting as Layer 2 device for 
> > user plane traffic (not making any assumptions about the Layer
> > 3 protocol carried in 802.3 frames). At the very least, the text 
> > should probably say the DSCP Tag applies only to packets with 
> > certain values in the 802.3 Type field.
> 
> OK, I can modify the text to specifically read:
> <new text>
>    DSCP Tag:   The 6 bit DSCP label to use if packets are 
>                eligible to be DSCP tagged (see [RFC2474]).
> </new text>

IMHO it would be clearer to say "if the packet received from the STA is an 
IPv4 or IPv6 packet" (if that's what's meant by "eligible to be DSCP

Best regards,
Pasi