> > > Section 6.1 and 6.21: are some of these 802.11 information elements 
> > > optional, or are all of them always included?
> > Always, since the text states:
> > 
> > <current text>
> >    The inclusion of this message
> >    element MUST also include the IEEE 802.11 Information 
> >    Element message
> >    element, containing the following 802.11 IEs:
> > </current text>
> 
> Does this mean that e.g. all WTPs MUST support WMM? (since the AC MUST 
always send the WMM information element) And 
> MUST support WPA forever (in addition to RSN)?
> 

Well... We are 2007, and I'm not sure how much we need to care about hardware 
out there that is unable to support IEEE 802.11-2007. If there is ever a new 
IEEE standard for securing, then the list of IEs would have to change, but 
that would be post IEEE 802.11-2007 anyhow. The CAPWAP specification could 
publish an updated set of rules of what IEs need to be present.

<snip>
> > > Section 6.1 and 6.21: what do you put in "Key Status" if you're not 
> > > using  encryption at all?
> >
> > Well... Good question. The way it works is that the absence of a key 
> > means that the key status field is irrelevant, but perhaps it would be 
> > good to define a new "unused" value. However, this *could* create a 
> > backward compatibility problem. Alternatively, we could add text that 
> > simply states that this field is ignored if the key field has a zero 
> > length, and then it really doesn't matter what value was used.
> > 
> > OK?
> 
> I'm fine with either approach.
> 

I've chosen the latter, so the text now reads:

<new text>
   Key Status:   A 1 byte value that specifies the state and usage of
      the key that has been included.  Note this field is ignored if the
      Key Length field is set to zero (0).  The following values
      describe the key usage and its status:
</new text>

<snip>
> > > Section 6.14, 6.20, and 6.22: the 802.1p Tag field should probably 
> > > be shown as 3 bits in the diagram, to make it unambiguous about 
> > > which bits are not used.
> > 
> > Well... That would truncate a packet on a non-byte boundary. Do you 
> > really believe that would help clear things up?
> 
> No need to truncate the packet on a non-byte boundary; just show where the 
unused padding bits are. Something like this ("Z" is unused):
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          MAC Address          |Z|Z| DSCP Tag  |Z|Z|Z|Z|Z|8021p|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> or this:
> 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          MAC Address          | DSCP Tag  |Z|Z|Z|Z|Z|Z|Z|8021p|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> or this:
> 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          MAC Address          | DSCP Tag  |Z|Z|8021p|Z|Z|Z|Z|Z|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> depending on which you meant...

Oh, I see. Well, that makes sense. Here is the new text:

<new text>
6.20.  IEEE 802.11 Update Station QoS
[...]
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |                  MAC Address                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          MAC Address          |   DSCP Tag    | Reserved|8021p|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[...]
   Reserved:   All implementations complying with this protocol MUST set
      to zero any bits that are reserved in the version of the protocol
      supported by that implementation.  Receivers MUST ignore all bits
      not defined for the version of the protocol they support.

   8021p:   The three bit 802.1p priority value to use if packets are to
      be IEEE 802.1p tagged.
</new text>

<snip>
> > > Sections 6.20 and 6.22: the DSCP Tag field should probably be shown 
> > > as 6 bits in the diagram, to make it unambiguous how it's sent in 
> > > IPv4/IPv6 header (and which bits are unused).
> > 
> > See above. I think showing fragments of a byte is even harder to 
> > understand. I have never seen RFCs to that.
> 
> See above.

Ditto

<snip>
> > > Section 6.20 and 6.22: "if packets are to be DSCP tagged" would
> > benefit of
> > > clarifying what packets are meant (I guess it means CAPWAP Data 
> > > packets sent from the WTP to the AC?).
> > 
> > New text:
> > <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 by the station.
> 
> By "packets received by the station", do you mean "packets sent by the WTP 
to the station"? (In this case, including DSCP here is slightly unexpected -- 
those packets aren't necessarily even IP?)

Hmmm... Should have read: "applied to packets received at the WTP from the 
station."

> > [...]
> > 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 to be applied to packets received by the WTP from
> >    station on a particular radio.
> > </new text>
> 
> By "applied to packets received by the WTP from the station", do you mean 
the tagging is applied to the headers received by the WTP, or to the headers 
added by WTP for CAPWAP data tunneling?
> (If it's the former, the comment above about DSCP applies)
> 
I am proposing adding the following sentence to both sections 6.20 and 6.22:

<new text>
   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>

<snip>
> > > Section 8.1: WEP is missing from the list?
> > 
> > Given that WEP was introduced so long ago, it was just assumed that 
> > WTPs support it. However, with TKIP and AES possibly requiring changes 
> > to the ASIC, we wanted to allow WTPs to advertise these capabilities.
> 
> Well, some new WTPs might decide *not* to support WEP anymore -- perhaps not 
yet, but five year from now..? (But if support of WEP is required, the 
document should say so)

Understood, but IEEE 802.11-2007 still requires the AP support it.