> Section 3: CAPWAP base protocol requires that all Request messages are odd 
numbers, and Responses even; these aren't.
Yes, this was raised already and will be addressed in the next rev.

> Section 3.1, "sent after the CAPWAP Configuration Update Request message 
(..) has been received by the WTP" probably 
> means "sent after the CAPWAP Configuration Update Response message has been 
received by the AC"?
> 
> Section 5.10: "Station QoS Profile" should be "IEEE 802.11 Station QoS 
Profile"
> 
> Section 6.1 and 6.21: are some of these 802.11 information elements 
optional, or are all of them always included?
> 
> Section 6.1 and 6.21: what do you put in "Key Status" if you're not using 
encryption at all?
> 
> Section 6.21: to avoid repetition of text, I'd suggest simply pointing to 
existing text in Section 6.1 for field 
> descriptions.
> 
> Section 6.1 and 6.21: "32 byte Session Key" -- length depends on "Key 
Length" field, right?
> 
> Section 6.2/10.6: is the "Combiner" a bit field or enumerated field?
> (And in the former case, an explicit bit diagram would be very useful to 
avoid confusion about bit numbering)
> 
> 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.
> 
> Section 6.15: The sentence "Note that AKM-Only is MAY be set..." would 
benefit for some clarification -- does 802.11 
> really drop all unencrypted EAPOL-Key frames if you have an encryption key? 
(it seems that would cause difficulties 
> when e.g. client reboots -- but I'm not sure what 802.11 does here)
> 
> Section 6.15: "MUST NOT be sent if the WTP had not specifically advertised 
support for the requested encryption 
> scheme": would be easier to understand if it said how the WTP advertises 
this (presumably, the Encryption Capabilities 
> field in the WTP Descriptor Message Element?)
> 
> 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).

> Section 6.16, "maximum value of 65535" -- the fields are 32 bits, so 
probably should be 4294967295?
> 
> 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?).
> 
> Section 6.22/10.9: is the "Tag Packets" a bit field or enumerated field?
> (In the former case, an explicit bit diagram would be very useful to avoid 
confusion about bit numbering.)
> 
> Section 6.23: "Country Code" field probably should be called "Country 
String" (since it contains other things than the 
> country code, and it's called "country string" in 802.11), and it should be 
3 octets instead of 4.
> 
> Section 6.23: The description of third octet of Country field doesn't quite 
match IEEE 802.11 (e.g. 'X' character is 
> missing, and the '255'
> entry is confusing).
> 
> Section 6.23: reference [ISO.3166.1984] should be to the latest edition, not 
1984 version:
> 
>    [ISO.3166-1] International Organization for Standardization, "Codes
>                 for the representation of names of countries and their
>                 subdivisions - Part 1: Country codes", ISO Standard
>                 3166-1:1997
> 
> Section 6.25: an explicit bit diagram would be useful for the "Radio Type" 
field, since it's not clear whether e.g. 
> "2" really means bit number 2, or perhaps bit number 6 (rest of the text 
suggests it's the latter).
> 
> Section 8.1: an explicit bit diagram would be useful (since bit numbering 
has been somewhat inconsistent in various 
> parts of the spec).
> 
> Section 8.1: WEP is missing from the list?
> 
> Section 8.1: there probably should be IANA considerations text about how the 
remaining bits are allocated.
> 
> Section 10.2, "defines 27 new Message Types" -> "defines 25 new Message 
Element Types"?