I read capwap-protocol-binding-ieee80211-07 on my way to Dublin;
here are some comments/observations.
Substantial topics first:
I was under the impression that 802 (or at least 802.11) required (or
assumed) strict in-order delivery -- but perhaps I remember this wrong?
(Obvious, tunneling over arbitrary IP hops doesn't guarantee in-order
delivery, and it seems the data channel doesn't have mechanisms to
reorder or drop out-of-order packets.)
802.11 header has 4 different addresses, all of which can be
different. When doing split MAC with 802.3 frames, the 802.3 frame
contains only two of the addresses; the "Radio MAC Address" field in
CAPWAP header contains the third -- but what about the fourth one?
The document should have some more text about how the WTP processes
IEEE 802.11 IEs it receives from the AC. Section 6.6 talks about
copying them to Beacon/Probe Response messages, but it seems that in
some cases, the WTP also does some local processing. (I was sort of
expecting a list of all IEs, and description of expected WTP
processing (possibly none) for them.)
Section 6.15: Is this really the PTK (which also includes KCK and KEK,
which aren't needed by the WTP since the AC is handling the EAPOL-Key
messages -- so probably shouldn't be sent to PTK), or only the TK used
for encrypting traffic?
Is the binding specified here sufficient for 802.11r as well, or would
something more be needed? (I don't know the answer -- but probably the
document should tell what it is)
Section 6.14 says that packets exceeding this priority are either
dropped or "down-tagged" -- but it seems which of these is done
depends on WTP (and the AC can't even know what the WTP does).
Isn't this problematic for interoperability?
Question: Section 4 says the "Destination WLANs" field is used only
for multicast/broadcast; how is the destination WLAN determined for
unicast? (Is this by mapping destination MAC address to earlier IEEE
802.11 Station messages -- which means a single MAC address can't be
in more than one WLAN?) (Perhaps the document should have couple
of sentences about this)
Question: The WLAN ID is always shown as 8 bits, but it seems some
other parts limit the spec to 16 WLANs per WTP Radio. Could a WTP
supporting more than 16 WLANs use multiple Radio IDs, or is 16 a hard
limit? (Perhaps the document should have couple of sentences about
this -- at least saying that WLAN ID is between 0 and 15)
Minor clarifications/editorial nits:
Section 3: CAPWAP base protocol requires that all Request messages are
odd numbers, and Responses even; these aren't.
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"?
Best regards,
Pasi
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf