|
CID
|
Page
|
Clause
|
Comment
|
Proposed Change
|
|
2008
|
1758.06
|
9.4.2.300
|
"The P2P Ranging Availability subelement is included in the IFTMR and IFTM frames for non-TB FTM session negotiation with a non-AP RSTA." - I believe the term is "non-TB ranging", also a link would be nice.
|
Replace with "The P2P Ranging Availability subelement is included in the IFTMR and IFTM frames for non-TB ranging FTM session negotiation with a non-AP RSTA, see 11.21.6.4.4.4."
|
|
2514
|
1283.39
|
9.4.2.46
|
In the description of the FTE, it says "R1KH-ID indicates the identity of the R1KH", which is not clear. Is the body of the R1KD-IH subelement just an identifier? How big is it supposed to be? Similarly it's not clear what's in the R0KH-ID
subelement
|
Other locations indicate this is actually a MAC address. This should be specified
|
|
2532
|
|
11
|
Why both 11.10.14 Multiple BSSID set and 11.1.3.8 Multiple BSSID procedure?
|
Merge into one subclause by making 11.10.14 a new last subclause of 11.1.3.8
|
|
2539
|
2413.36
|
10.23.3.5.1
|
"A TXOP obtained by receiving a QoS (+)CF-Poll" -- the TXOP is obtained by the transmitter of the CF-Poll, not by the receiver
|
Reword (not sure exactly what the sentence is trying to say)
|
|
2547
|
|
13
|
The spec is inconsistent as to which FT messages the RSNXE is included in. Table 9-87--Presence of fields and elements in Authentication frames says it can only be present in message 1. Figure 13-5--Over-the-air FT protocol in an RSN and
13.7.1 FT reassociation in an RSN say it can only be present in messages 3 and 4. Table 13-1--FT authentication elements says it can be in messages 1, 3 and 4
|
Agree which messages the RSNXE can be present in for FT, then make sure the spec consistently says so and does not mention the RSNXE in other messages
|
|
2556
|
2896.33
|
11.2.3.14
|
"The insertion of an element means that the element was not present in the previous Beacon frame, is present in the current Beacon frame, and will be carried in the next Beacon frame. " -- the receiver has no way to know for sure whether
the element will be included in the next frame (maybe CSA, but even there there could be weird corner cases where the AP immediately advertises a CSA on the new channel). Also, should there be something about the removal of an element (e.g. no more Quiet)?
|
Change to "The insertion of an element means that the element was not present in the previous Beacon frame, is present in the current Beacon frame, and (for an AP) will be carried in the next Beacon frame, or that it was present in the
previous Beacon frame and is not present in the current Beacon frame. "
|
|
2567
|
|
9
|
"element is included in" is duplication and spec rot, but the following seem to be behaviour not just format/encoding:
The EDMG Specific Parameters subelement is included in the IFTMR frame, as described in 9.6.7.32 (FTM Request frame format), and the IFTM frame, as described in 9.6.7.33 (FTM frame
format), if the Secure RTT Measurement subfield of the FTM Parameters field of these frames is equal to 1.
The EDMG Wide Bandwidth Channel Switch element is included in DMG Beacon frames, Announce frames, or Information Response frames, as defined in 11.8.8.7 (Selecting and advertising
new channels in an EDMG BSS).
If the initiator and the responder successfully negotiate an FTM session, and the negotiated ranging protocol is non-TB, then the Non-TB Specific subelement is included in both
the IFTMR frame, to describe the requested set of parameters that the initiator proposes to use, and in the IFTM frame.
If the initiator and the responder successfully negotiate an FTM session where the negotiated ranging protocol is TB, then the TB Specific subelement is included in both the IFTMR
frame, to describe the requested set of parameters that the initiator proposes to use, and in the IFTM frame.
The P2P Ranging Availability subelement is included in the IFTMR and IFTM frames for non-TB FTM session negotiation with a non-AP RSTA.
|
Delete the cited sentences and move the behaviour to Clauses 10 and later
|
|
2573
|
867.19
|
9.3.3.1
|
The allowed settings of A1 and A3 in probe requests is unclear: whether you can have A1 = unicast A3 = broadcast, or A1 = broadcast A3 = broadcast, and whether there are any additional subtleties with MBSSID (e.g. A1 and/or A3 has to be
the txBSSID or something) and/or 6G scanning
|
As a strawman: at the referenced location add "In Probe Request frames, if the Address 3 field is the wildcard BSSID, the Address 1 field shall be the broadcast address."
|
|
2575
|
4734.38
|
26.17.2.3.3
|
"-- Otherwise, if the channel is a PSC and the STA has determined the medium to be idle for a continuous period of at least dot11MinPSCProbeDelay from the start of the scan on the channel, then the STA may, subject to other rules in this
subclause, send a Probe Request frame to the broadcast address in that channel, with the SSID field set to the SSID that corresponds to an AP or with the Short SSID field of the Short SSID List element set to the short SSID that corresponds to an AP, and/or
with the Address 3 field set to the BSSID of an AP, after invoking the backoff procedure, described in 10.23.2.2 (EDCA backoff procedure), starting from step c) of 11.1.4.3.2 (Active scanning procedure for a non-DMG STA)." seems to suggest you can have Addr1
= broadcast but Addr3 = BSSID. Is this valid, and if so what is the difference with Addr1 = Addr3 = BSSID? In general terms the latter seems better since it allows early rx termination
|
Clarify
|
|
2578
|
1283.39
|
9.4.2.45
|
"R1KH-ID indicates the identity of the R1KH, which is used by the S0KH and the R0KH for deriving the PMK-R1s." is not clear as to the actual contents of subelement, and how the identity of the R1KH is actually encoded in the subement. Similarly
for R0KH-ID.
|
Change to "The Data field of the R1KH-ID subelement contains the identity of the R1KH, which ...". On page 1284 change "the R0KH-ID indicates the R0KH" to "the Data field of the R0KH-ID subelement contains the identify of the R0KH" (2x)
|
|
2579
|
3706.33
|
13.5.2
|
Shouldn't Figure 13-5--Over-the-air FT protocol in an RSN(#11be)(#199) include RSNXEs in the Auth frames, at least in some cases, per Table 9-87--Presence of fields and elements in Authentication frames? Conversely the table does not mention
RSNXEs in anything but message 1
|
As it says in the comment
|
|
2582
|
|
|
"roaming" is used about 10 times outside the context of "SP" or "consortium", but not defined
|
Define the term, or change each instance to "BSS transition"
|
|
2614
|
2325.47
|
10.6.6.5
|
There are references to "alternate rate"s but it's not clear how you can have two rates that give the same airtime, unless this is something implausible like switching between 80M 2SS and 40M 4SS or something
|
Add a NOTE to give an example of two alternate rates
|
|
2616
|
|
|
Canonicalise "2s complement signed integer" "2s complement integer" "2s complement number" "2s complement value" "2s complement format" "2s complement 8-bit number"
|
I will provide the list of changes needed
|
|
2617
|
|
|
"unsigned 2s complement" makes no sense!
|
I will provide the list of changes needed
|
|
2626
|
|
12.7
|
Stuff like "-- The Key Data descriptions specify what shall or may be included; nothing else shall be included
except that one or more vendor specific KDEs and/or Vendor Specific elements may be included." in 12.7.6.1 General also applies to the GKH (12.7.7)
|
Either duplicate the statements or have a subclause that applies to both 12.7.6 and 12.7.7
|
|
2635
|
3249.54
|
11.24.2.2
|
Things like "The QMFReconfigurationActivated subfield shall be set to 0 in the Extended Capabilities element when dot11QMFReconfigurationActivated is false." force the transmission of the octet containing the bit, even if it's the last
octet and there are no bits set in it
|
Change to "... shall not be set to 1 ..."
|
|
2651
|
|
12.7
|
12.7.4 notation is EAPOL-Key(S, M, A, I, K, Reserved, RSC, ANonce/SNonce, MIC, {Key Data})
12.7.7.1 says
G1: EAPOL-Key(1, 1, 1, 0, G, 0, RSC, 0, MIC, ...
G2: EAPOL-Key(1, 1, 0, 0, G, 0, 0, 0, MIC ...
so the Key MIC Present (second argument to EAPOL-Key()) is shown as 1, but it is 0 when an AEAD cipher is used. This is incorrect duplication of the next two subclauses. Ditto for
12.7.6.1
|
Delete lines 2 to 8 inclusive on page 3617, and from line 63.5 on page 3603 to line 14 on the next page. Note: this is a very detailed and specific statement of the changes that would satisfy the commenter
|
|
2657
|
|
3.1
|
It would be useful to have something in 3.1 to say that a wrapped key is a key (or other sensitive material) that is encrypted and authenticated using a KEK. Note cf. CID 481 rejection that this concept appears in the form "wrapped <something>K"
not "wrapped key"
|
Add a definition in 3.1:
wrapped key: A key (or other sensitive material) that is encrypted and authenticated using a key encapsulation key (KEK).
Notes from previous discussions: The Group did not like the generic definition of "wrapped key". Concern in the wrapped data expanding the use of "wrapped" and if it needed a better
definition or usage.June 23: 12.7.3 text on wrapping could be moved to a new clause in 12.7 about the Key Wrap Algorithms for use in the standard. The Title should include the word "Wrapped" maybe at 12.7.2
|
|
2755
|
273.35
|
3.2
|
"(STA_" should be "(STA)". There are other typo instances of "_" used instead of ")" in this subclause.
|
As suggested.
|