Hi Pasi,
Finally over your comments on the base protocol, and just getting around
to the binding spec. I will only create issues where needed, and
therefore indicated below. Otherwise I will simply address them in this
e-mail.
> 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
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
Archives: http://lists.frascone.com/pipermail/capwap
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf