|
Adrian Stephens
|
7062
|
832.37
|
9.4.2.25.3
|
"a single AKM suite selector may be specified because IBSS STAs use the same AKM suite" - normative verb in clause 9.It is unclear as to whether this is granting permission.
|
If normative behaviour is present elsewhere, cite it here and change "may" to "can" and add reference to subclause defining the behaviour. Otherwise move this to a behavioural clause.
|
MAC
|
Frame Formats
|
|
Adrian Stephens
|
7074
|
586.05
|
9.2.4.6.2
|
" all or part of an MSDU or A-MSDU should discard the MSDU or any MSDUs containedwithin the A-MSDU in preference toMSDUs carried in MPDUs whose DEI subfield is equal to 0." - this is
clearly behaviour, and doesn't belong in Clause 9.
|
Move to Clause 10
|
MAC
|
Frame Formats
|
|
Adrian Stephens
|
7075
|
738.44
|
9.4.2.10
|
"The Requested Element IDs within a Request element transmitted in a Probe Request frame should notinclude an element ID that corresponds to an element that will be included in the Probe
Response frame" - this is behaviour, not frame format, and doesn't belong in Clause 9.
|
Move to Clause 10/11
|
MAC
|
Frame Formats
|
|
Adrian Stephens
|
7077
|
1004.45
|
9.4.2.121
|
" If there are insufficient resources, a STA should discard theMSDUs or A-MSDUs of a TS with a Drop Eligibilitysubfield equal to 1," - this is not frame format. Should not be in clause
9.
|
Move to Clause 10/11.
|
MAC
|
Frame Formats
|
|
Adrian Stephens
|
7103
|
1883.25
|
11.43
|
"B0-B1 (BW) in TVHT-SIG-A1"- the MAC has no knowledge of the contents of particular signal fields in the PHY (rightly so).
|
Reword so that this refers only to TXVECTOR/RXVECTOR parameters.
|
EDITOR
|
MAC Operation
|
|
Adrian Stephens
|
7106
|
2330.39
|
19.2.5
|
"the MAC shall set the CH_BANDWIDTH" - this is a normative requirement on the MAC buried in the guts of a PHY subclause.Ditto at 2504.27
|
Move this normative requirement to a MAC subclause.
|
GEN
|
MAC Operation
|
|
Adrian Stephens
|
7107
|
2500.31
|
21.2.4
|
This table references "BSS bandwidth" in multiple places. But the PHY knows nothing about this, as it is a purely MAC concept. The normative statement cited here is therefore impossible
to achieve in the 802.11 architecture.Ditto comment in Table 22-2.
|
Either provide add PHY SAP primitive parameters for the MAC to tell it about the BSS bandwidth, or reword the normative requirements to relate to some other parameter/MIB variable to
which it does have access.
|
GEN
|
MAC Operation
|
|
Adrian Stephens
|
7113
|
3617.4
|
R.7
|
The equations starting at the cited location do not follow IEEE-SA equation style very closely. There is inconsistency between underscore and subscripting. The showing of units in equations
is not done elsewhere in this standard.
|
Rework equations to bring closer to IEEE-SA style and to others in the Standard. Specifically: remove any units embedded in the equations, use "underscore" versus subscripts consistently,
and certainly when referring to the same variable. Use shorter variable names, and put the explanation of what they represent into the variable list.
|
GEN
|
Annex R
|
|
Adrian Stephens
|
7119
|
1071.19
|
9.4.2.172
|
Either the "N x 3" is wrong, or the field doesn't contain the structure as described.
|
Either change "N x 3" to "3", or change in the name of the field e.g. to "ESP Information List" and add a new para at line 26 "The ESP Information list contains one or more ESP Information
fields."
|
MAC
|
Frame Formats
|
|
Adrian Stephens
|
7121
|
1346.53
|
10.21.4
|
"When communicating with a STA that supports global operating classes" - this is an informal condition in a normative statement.
|
Replace informal condition with condition based on observables.
|
MAC
|
MAC Operation
|
|
Adrian Stephens
|
7151
|
14.5
|
3.1
|
"provide access to one or more distribution systems, via the wireless medium" -- the mesh gate must surely provide access to a DS locally, not via the wireless medium
|
Add that it provides access to a single DS locally.
|
GEN
|
Definitions
|
|
Adrian Stephens
|
7235
|
2311.3
|
18.3.2.2.1
|
This subclause duplicates the information in 16.2.3.5
|
Change to just refer back to 16.2.3.5
|
GEN
|
Editorials
|
|
Adrian Stephens
|
7411
|
2504.51
|
21.2.5.2
|
"PHY-TXSTART.request(TXVECTOR) primitive is issued" -- to what? There is no OFDM PHY
|
Use "as if" wording, as above
|
EDITOR
|
Editorials
|
|
Adrian Stephens
|
7447
|
19.32
|
3.1
|
"RF chain: A receive chain or a transmit chain." -- but then all the statements about numbers of RF chains will give twice the number they expect
|
Either fix the definition, or fix the wording where used (7 instances, in 10.32.4.1 and 10.33)
|
GEN
|
Definitions
|
|
Adrian Stephens
|
7481
|
1253.54
|
9.7.3
|
There is also a restriction on A-MSDUs sent in a pre-HT PPDU
|
Change the first sentence of the NOTE 3 to "If a STA supports A-MSDUs of 7935 octets (indicated by the Maximum A-MSDU Length field in the HT Capabilities element), A-MSDUs transmitted
by that STA within an A-MPDU carried in a PPDU with FORMAT HT_MF or HT_GF or within an MPDU carried in a non-HT PPDU are constrained so that the length of the QoS Data frame carrying the A-MSDU is no more than 4095 octets. "
|
MAC
|
Frame Formats
|
|
Adrian Stephens
|
7494
|
1076.07
|
9.4.4.2.2
|
The DII field can only contain one TLV ("Single value TLV comprising fields in related table in E.2"). But what if you need to pass more than one TLV (e.g. both an FCC ID and a Device
Serial Number in the USA, per Table E-8 Device Identification Information Value fields)?
|
Delete "Single value"
|
MAC
|
Frame Formats
|
|
Adrian Stephens
|
7539
|
1285.01
|
10.3.2.12.3
|
RR1 and RR3 in Table 10-4---Receiver Caches restrict the rules to non-DMG STAs, but there is otherwise no mention of this in the actual RC rows
|
Add non-DMG to the corresponding rows
|
MAC
|
MAC Operation
|
|
Adrian Stephens
|
7543
|
3615.18
|
R.5.3
|
" an AP Advertisement location capability does not return an "incapable" response if the non-AP STA requests the "remote" location." makes no sense?
|
Change to something like "an AP avertising location capability does not return an "incapable" response if the non-AP STA requests the "remote" location."
|
MAC
|
Annex R
|
|
Adrian Stephens
|
7560
|
1261.58
|
10.2.4.2
|
This NOTE should be promoted to normative, since it is not otherwise obvious that the Retry bit is not to be set. Also need to be clear it is set, though, if had been previously transmitted
(except if this was done under BA (except if in a DMG BSS))
|
As it says in the comment
|
MAC
|
MAC Operation
|
|
Adrian Stephens
|
7648
|
838.31
|
9.4.2.27
|
Re CID 6476: why is the bit set to 0 when sent in a non-AP STA's beacon, even if it it supports PSMP (and indicates so when it sends a probe response)? This seems very odd (and would
leave a device which does passive scanning with the wrong understanding)
|
Change the rightmost cell to just the last two of the current lines
|
MAC
|
Frame Formats
|
|
Adrian Stephens
|
7685
|
1055.12
|
9.4.2.159
|
It says "The maximum value of theRXVECTOR parameter MCSof a PPDU"
|
Change to "This parameter"
|
EDITOR
|
Frame Formats
|
|
Adrian Stephens
|
7691
|
1328.16
|
10.7.12.1
|
It says "except that if thevalue of dot11VHTExtendedNSSBWCapable of the second STA is false, the supported bandwidthvalues and NSS values of each tuple are updated according to Table
10-8(Interpretation of the Supported Channel Width Set and Extended NSS BW Support subfield of theVHT Capabilities Information field and the Channel Width field of the Operating Mode field at areceiving STA with a value of false for dot11VHTExtendedNSSBWCapable)
and" -- but if extended NSS capable is false, then you don't need to update anything
|
Change to "except that". Ditto next bullet
|
MAC
|
MAC Operation
|
|
Adrian Stephens
|
7694
|
1330.44
|
10.7.12.2
|
It says "except that if thevalue of dot11VHTExtendedNSSBWCapable of the second STA is false, the supported bandwidthvalues and NSS values of each tuple are updated according to Table
10-8(Interpretation of the Supported Channel Width Set and Extended NSS BW Support subfield of theVHT Capabilities Information field and the Channel Width field of the Operating Mode field at areceiving STA with a value of false for dot11VHTExtendedNSSBWCapable)
and" -- but if extended NSS capable is false, then you don't need to update anything
|
Change to "except that". Ditto next bullet
|
MAC
|
MAC Operation
|
|
Adrian Stephens
|
7722
|
19.32
|
3.1
|
"RF chain: A receive chain or a transmit chain." -- what does the "or" mean?
|
Add ", depending on the context"
|
GEN
|
Definitions
|
|
Adrian Stephens
|
7743
|
1074.27
|
9.4.3
|
"A subelement that is not defined as extensible will not be extended in future revisions or amendments of thisstandard." -- what if it's marked a Yes, could it become Subelements? Or
vice-versa?
|
Add "A subelement that is defined as extensible might become subelement-extended in future revisions or amendments of thisstandard. A subelement that is defined as subelement-extensible
will remain so in future revisions or amendments of thisstandard."
|
MAC
|
Frame Formats
|
|
Adrian Stephens
|
7750
|
880.1
|
9.4.2.45
|
There are 4 instances of "capability enabled"
|
Change at least the first 3 to "Capability Enabled". I'm not sure what " STAs that have the Beacon request capability enabled" in 11.28.1 is referring to
|
MAC
|
Editorials
|
|
Adrian Stephens
|
7755
|
1355.53
|
10.22.2.7
|
"A frame exchange may be one of the following:" -- but a frame exchange, or at least a frame exchange sequence, is more than the things indicated (see Annex G)
|
Add ", in the context of multiple frame transmission in an EDCA TXOP"
|
MAC
|
MAC Operation
|
|
Adrian Stephens
|
7770
|
615.36
|
9.3.1.20
|
It says "If the VHT NDP Announcement frame contains only one STA Info field, then the RA field is set to the address of the STA identified by the AID in the STA Info field.", but the
AID in the STA Info field cannot identify a STA, if that STA is in fact an AP or a mesh STA or an IBSS STA. Also, there's no AID in the STA Info field
|
Change to "If the VHT NDP Announcement frame contains only one STA Info field and the frame is directed to a non-AP STA in an infrastructure BSS, then the RA field is set to the address
of the STA identified by the AID12 subfield in the STA Info field."
|
MAC
|
Frame Formats
|
|
Adrian Stephens
|
7774
|
1240.19
|
9.6.21.2
|
"One or more elements are present in this frame" -- these are already covered above
|
Delete this row
|
MAC
|
Frame Formats
|
|
Adrian Stephens
|
7775
|
649.22
|
9.3.4.2
|
"One or more elements can appear in this frame" -- these are already covered above
|
Delete this row
|
MAC
|
Frame Formats
|
|
Adrian Stephens
|
7776
|
1241.24
|
9.6.21.3
|
"One or more elements can appear in this frame" -- these are already covered above
|
Delete this row
|
MAC
|
Frame Formats
|
|
Adrian Stephens
|
7777
|
1226.34
|
9.6.20.4
|
"Each provided element is an element as specified in 8.4.2 (Elements), that the transmitter of this frame is providing to the destination of the frame." is vacuous and fails to specify
their nature and order
|
Delete this para and row 6 in the table above
|
MAC
|
Frame Formats
|
|
Adrian Stephens
|
7778
|
1227.24
|
9.6.20.5
|
"The provided elements are elements, as described in 8.4.2 (Elements), that the transmitter of this frame is providing to the destination of the frame." is vacuous and fails to specify
their nature and order
|
Delete this para and row 6 in the table above
|
MAC
|
Frame Formats
|
|
Adrian Stephens
|
7783
|
1720.01
|
11.14
|
Since SA Query frames are robust, and receipt of any protected frame will do for SA Query, SA Query frames don't need a transaction identifier
|
Delete " and with a matching TransactionIdentifier" at 1625.6 and 1629.16Delete " with a TransactionIdentifier matching aTransactionIdentifier in an MLME-SA-QUERY.request issued in this
SA Query procedure" at 1625.12 and 1629.22Delete " that has a matching transaction identifier" at 1720.1
|
MAC
|
Frame Formats
|
|
Adrian Stephens
|
7811
|
11.31
|
3.1
|
Distribution service versus distribution system service?
|
Change "distribution service" to "distribution system service" at P11.31, and P99.29.
|
GEN
|
Definitions
|
|
Adrian Stephens
|
7828
|
649.22
|
9.3.4.2
|
In Table 9-41--DMG Beacon frame body, the "last - 1" entry is underspecified. What elements are allowed/supported/expected in a DMG Beacon? Anything?
|
List explicitly, or at least describe, the elements that are expected to be included at this point in the order.
|
MAC
|
Frame Formats
|
|
Assaf KASHER
|
7142
|
2643.18
|
20.6.3.1.2
|
The MCS table contains MCSs only up to 16QAM rate 3/4. Higher MCSs are missing such as 64QAM rates, 5/8, 3/4, 13/16. Also a code rate of 7/8 is mising between MCS9 (QPSK 13/16) and MCS10
(16-QAM 5/8)
|
Document with the details of changes will be provided
|
GEN
|
VHT PHY
|
|
Brian Hart
|
7444
|
3614.27
|
R.5.3
|
There are 4 instances of "RM capability" in this subannex, and one in the MIB, but what does it mean?
|
Change to a defined term, e.g. LCI/civic location measurement capability
|
MAC
|
Annex R
|
|
Brian Hart
|
7523
|
1069.28
|
9.4.2.170.1
|
"Operating Class field is 1 octet in length and indicates the band and bandwidth of the primary channel of the APs in this Neighbor AP Information field." makes no sense, since the bandwidth
of the primary channel is always 20 MHz (excluding 11a oddities)
|
Just say it defines the operating class for the BSS, or words to that effect. Also add an article, and to the start of the next para too
|
MAC
|
Frame Formats
|
|
Brian Hart
|
7563
|
3612.65
|
R.4.2.11
|
dot11APLCITable - where is this used? (Cf. dot11APCivicLocationTable, mentioned in clause 9.4.5.13 AP Civic Location ANQP-element)
|
Add something on dot11APCLITable somewhere
|
MAC
|
Annex R
|
|
Carlos Aldana
|
7099
|
1704.14
|
11.11.10.1
|
"shall not transmit a FTM Range Request" -- there is no such thing as an FTM Range Request
|
Replace with something that does exist, or delete cited sentence.
|
MAC
|
Location
|
|
Carlos Aldana
|
7172
|
2448.08
|
20.5
|
The optional DMG OFDM mode has serious design flaws and has not been productized by any of the 60 GHz silicon vendors to the best of my knowledge. Some of the flaws: (1) DMG OFDM PHY
header is transmitted in OFDM, which makes it not decodable to Single Carrier only (SC-only) DMG devices, creating serious co-existence issues. (2) DMG OFDM subcarriers are defined such that when two channels are bonded the subcarriers for the wide channel
will not fall on a uniform frequency grid for FFT. It is anticipated that the 11ay standard will define a 60 GHz OFDM mode that will include a single-channel operation, effectively replacing the 11ad OFDM.
|
Remove the DMG OFDM mode and all parameters and references to DMG OFDM mode.
|
GEN
|
DMG PHY
|
|
Carlos Aldana
|
7276
|
1772.29
|
11.24.6.4
|
An RTT is the time between a signal going out and coming back. It includes any processing time at the other side. The spec uses "RTT" to mean the total time of flight, not the RTT
|
Delete the RTT definition from 3.4 and instead add "TOF time of flight"At 83.58 change "round trip time (RTT)" to "distance"At 1771.20 change "an RTT" to "a two-way TOF"At 1772.28 change
"The round trip time (RTT)" to "The two-way TOF" and change "RTT" to "TOF" in the equationAt 3598.21 change "RTT" to "two-way TOF"
|
MAC
|
Location
|
|
Carlos Aldana
|
7277
|
1771.2
|
11.24.6.4
|
What does "or clock estimate" mean?
|
Delete NOTE 2
|
MAC
|
MAC Management
|
|
Carlos Aldana
|
7442
|
1772.18
|
11.24.6.4
|
"When the ASAP field is set to 0 by a responding STA, the Follow Up Dialog Token, TOD, TOA, TODError, and TOA Error fields in the Fine Timing Measurement frame following the initial Fine
Timing Measurement frame shall be reserved. " -- also if this frame is re-transmitted (i.e. was not acked)
|
As it says in the comment
|
MAC
|
MAC Management
|
|
Carlos Aldana
|
7504
|
1764.23
|
11.24.6
|
There should be a mechanism to allow the responding STA to ask the initiating STA to re-initiate an FTM session (because it wants to change the parameters)
|
As it says in the comment. A bit in the FTM frame could be used to signal this
|
MAC
|
MAC Management
|
|
Carlos Aldana
|
7742
|
1767.06
|
11.24.6.3
|
"The responding STA's selection of the Number of Bursts Exponent value shall be 0 when the initiating STA requests it to be 0." should be a "should". An AP is required to support non-ASAP
since a STA is not required to be ASAP-capable. ASAP=1 can be problematic for scheduling.
|
I think this came in the context of a discussion with Carlos ALDANA, so I hope he can work out what this was about!
|
MAC
|
Location
|
|
Carlos Cordeiro
|
7136
|
2448.13
|
20.5.1
|
This is a pile on to CID5857. As discussed in https://mentor.ieee.org/802.11/dcn/15/11-15-1040-01-000m-dmg-unified-header.docx, compliant DMG devices that support only Control and SC
modes ("SC-only" devices) will be unable to decode the OFDM mode and LPSC mode packet headers, and as a result unable to calculate the duration of these packets. This is an important interoperability issue.
|
Propose to insert the following in clause 20.5.1: "The use of the DMG OFDM mode is deprecated." This would send a signal for vendors not to implement this PHY, and would pave the way
for 802.11ay to then design a proper OFDM PHY that does not exhibit the interop issue that the current OFDM PHY does.
|
GEN
|
DMG PHY
|
|
Carlos Cordeiro
|
7138
|
2463.15
|
20.6.3.1.2
|
This is a pile on to CID5857 and CID5995. As discussed in https://mentor.ieee.org/802.11/dcn/15/11-15-1040-01-000m-dmg-unified-header.docx, there is an interoperability issue that has
been uncovered with DMG OFDM mode. Essentially, this will prevent vendors from supporting the OFDM PHY, given that it is not desirable to implement a PHY that does not interoperate with the DMG control mode or DMG SC mode.As a result of the above, the maximum
data rate that can be supported by DMG devices is limited to MCS12 of the SC mode, which is about 4.6 Gbps. This is much lower than what could otherwise be achieved with OFDM at 6.8 Gbps.
|
Define new MCSs to the DMG SC mode to allow higher rates. In particular, define 64 QAM based MCSs for SC.
|
GEN
|
DMG PHY
|
|
Carlos Cordeiro
|
7143
|
2448.08
|
20.5
|
The is a major interoperability issue with OFDM tarnsmissions. THe header of OFDM TX cannot be decoded by devices supporting only mandatory SC modulation. Therefore, these devices cannot
determine the duation of OFDM packets. There are no know implemenation of devices with OFDM.
|
deprecate OFDM.
|
GEN
|
DMG PHY
|
|
Carlos Cordeiro
|
7209
|
661.62
|
9.4.1.8
|
"A DMG STA sets the 8 MSBs of the AID field to 0." is not clear. Is it trying to say that the 8 MSBs are reserved?
|
If so, say so. If not, then the sentence should be deleted, as it follows naturally from putting a value of 1-254 in a 16-bit field
|
MAC
|
Frame Formats
|
|
Carlos Cordeiro
|
7211
|
2445.1
|
20.4.3.2.1
|
If b0 is used for "differential detector initialisation", whatever that is, it cannot be reserved, can it?
|
Either make the rightmost cell blank (if it's indeed just reserved", or change the leftmost cell to say "Differential detector initialisation" and make the rightmost cell blank (if it's
used for DDI, but the notion does not seem to be covered)
|
GEN
|
DMG PHY
|
|
Carlos Cordeiro
|
7626
|
1602.16
|
11.2.3.5
|
"The following rules describe operation of the ATIM frame and frame transmission to STAs in PS mode in a non-DMG IBSS and in a DMG BSS:". Either the "BSS" was intended to be "IBSS", in
which case it collapses to "in an IBSS", or this is wildly confusing as it's in a subsubsubclause and subsubclause which are about IBSSen (fear it's the latter...)
|
Assuming it's the latter, move the DMG-related behaviour to 11.2.6 or a new 11.2.7 just for DMG BSSen (since 11.2.6 is only for DMG infra BSSen)
|
MAC
|
MAC Management
|
|
Carlos Cordeiro
|
7787
|
1488.31
|
10.36
|
The material related to DMG has a lot of "TXTIME"s without an indication of the PHY parameters (especially the MCS) to be used to determine this. Without this information the "TXTIME"s
are meaningless
|
Add an indication of the PHY parameters (especially the MCS) to be assumed when TXTIME(frame) is mentioned in the context of DMG (and anything else which might suffer from the same problem)
|
MAC
|
MAC Management
|
|
Dan Harkins
|
7350
|
|
|
Misuse of "sequence number" in the context of PNs/TSCs (rather than the MPDU SN)
|
At 1002.10 and 2018.45 change "[The] Key RSCdenotes the last frame sequence number sent using the GTK" to "[The] Key RSC denotes the last TSC or PN sent using the GTK"At 2011.52 change
"Key RSC = For PTK generation, starting sequence number" to "Key RSC = For PTK generation, starting TSC or PN"At 2019.32 change "Key RSC = last transmit sequence number for the GTK" to "Key RSC = last TSC or PN for the GTK"Ar 2021.29 change " the last sequence
number used with the GTK (RSC)" to " the last TSC or PN used with the GTK (RSC)"1930.42, 1931.47 are also suspect
|
GEN
|
Security
|
|
Dan Harkins
|
7510
|
2875.55
|
C.3
|
dot11RSNAConfigNumberOfSTKSAReplayCountersImplemented is not used outside the MIB (unlike the PTKSA/GTKSA ones)
|
Mark this variable as deprecated
|
GEN
|
Security
|
|
Dorothy Stanley
|
7105
|
1972.65
|
12.6.7
|
"Because a VHT STA is also an HT STA ... elimination of TKIP ..."- this note is stunningly irrelevant because this subclause has nothing to be with TKIP.
|
Remove cited note.
|
MAC
|
MAC Operation
|
|
Dorothy Stanley
|
7249
|
2016.33
|
12.7.6.7
|
"whether to install the temporal keys, the encapsulated GTK, and if management frame protection is negotiated, the IGTK" -- the GTK and the IGTK are TKs
|
Change to "and whether to install the temportal keys"
|
GEN
|
Security
|
|
Dorothy Stanley
|
7318
|
1994.22
|
12.7.1.7.2
|
"(Length+255)/256" potentially results in a non-integer number of iterations
|
Replace with [ Length / 256 ] where the [] should be the ceil operator symbols and the Length should remain italicised
|
GEN
|
Security
|
|
Dorothy Stanley
|
7319
|
1986.47
|
12.7.1.2
|
"(Len+159)/160" potentially results in a non-integer number of iterations
|
Replace with [ Len / 160 ] where the [] should be the ceil operator symbols and the Len should remain italicised
|
GEN
|
Security
|
|
Dorothy Stanley
|
7335
|
1994.22
|
12.7.1.7.2
|
"(Length+255)/256" assumes the output size of the has is 256 bits, but that is not the case for e.g. SHA-384
|
At the end of line 13 above append "whose output length+F265 is
HashLen" and then change "(Length+255)/256" to "(Length+HashLen-1)/HashLen", with all three variables italicised
|
GEN
|
Security
|
|
Dorothy Stanley
|
7339
|
1979.44
|
12.6.18
|
"receives or invokes an MLME Disassociation or Deauthentication primitive" is too loose
|
Change to "receives an MLME-DEAUTHENTICATE.indication or MLME-DISASSOCIATE.indication primitive or issues an MLME-DEAUTHENTICATE.request or MLME-DISASSOCIATE.request primitive"
|
GEN
|
Security
|
|
Dorothy Stanley
|
7341
|
1979.55
|
12.6.18
|
"receives or invokes an MLME Disassociation or Deauthentication primitive" is too loose
|
Change to "receives an MLME-DEAUTHENTICATE.indication or MLME-DISASSOCIATE.indication primitive or issues an MLME-DEAUTHENTICATE.request or MLME-DISASSOCIATE.request primitive"
|
GEN
|
Security
|
|
Dorothy Stanley
|
7346
|
828.4
|
9.4.2.25.1
|
It says "The RSNE contains authentication and pairwise cipher suite selectors, a single group data cipher suite selector, an RSN Capabilities field, the PMK identifier (PMKID) count,
a PMKID list, and a single group management cipher suite selector." but it doesn't necessarily contain all of these, and the PMKID count is not of particular significance compared to the other counts. And "authentication" is vague
|
Change to "The RSNE potentially contains AKM and pairwise cipher suite selector lists, single group data and management cipher suite selectors, an RSN Capabilities field, and a PMKID
list." Or replace the first para with "The RSNE contains the information necessary to establisn an RSNA. The format of the RSNE is shown in Figure 9-254."
|
MAC
|
Frame Formats
|
|
Dorothy Stanley
|
7469
|
1914.61
|
12.4.4.2.2
|
The len() function is not described
|
State that it returns the length of its argument in bits
|
GEN
|
Security
|
|
Dorothy Stanley
|
7470
|
1917.31
|
12.4.4.3.2
|
The len() function is not described
|
State that it returns the length of its argument in bits
|
GEN
|
Security
|
|
Dorothy Stanley
|
7511
|
836.1
|
9.4.2.25.4
|
It says "A STA sets the GTKSA Replay Counter subfield of the RSN Capabilities field to the value contained in dot11RSNAConfigNumberOfPTKSAReplayCounters."
|
Change "PTKSA" to "GTKSA"
|
MAC
|
Security
|
|
Dorothy Stanley
|
7530
|
2130.04
|
14.5.1
|
The term "mesh PMK" is used nowhere else
|
Change to "mesh PMKSA"
|
GEN
|
Mesh
|
|
Dorothy Stanley
|
7533
|
1002.07
|
9.4.2.118
|
"the bit string of {GTK || Key RSC ||GTKExpirationTime}" -- what is the format of the GTK as an octet string?
|
Define the format (as is done for the other two)
|
MAC
|
Security
|
|
Dorothy Stanley
|
7536
|
2138.01
|
14.5.7
|
Selected AKM Suite || min(localMAC, peerMAC) || max(localMAC, peerMAC)). -- what's the format of the Selected AKM Suite as an octet string?
|
Define the format
|
GEN
|
Mesh
|
|
Dorothy Stanley
|
7537
|
2138.15
|
14.5.7
|
Selected AKM Suite || min(localMAC, peerMAC) || max(localMAC, peerMAC)). -- what's the format of the Selected AKM Suite as an octet string?
|
Define the format
|
GEN
|
Mesh
|
|
Dorothy Stanley
|
7571
|
1995.32
|
12.7.1.7.4
|
"to generate a key whose length is equal to the length of the hash algorithm's digest" breaks the usual pattern and is too indirect
|
Add a new bullet "--- Length is the hash algorithm's output length"
|
GEN
|
Security
|
|
Dorothy Stanley
|
7649
|
2925.61
|
C.3
|
The description of dot11RSNAActivated suggests it's only for APs
|
Delete "The entity advertises the RSNE in its Beacon and Probe Response frames."
|
GEN
|
MIB
|
|
Dorothy Stanley
|
7710
|
1994.07
|
12.7.1.7.2
|
"The KDF for the FT key hierarchy, and for AKMs 00-0F-AC:11 and 00-0F-AC:12, is a variant of the pseudorandom function (PRF) defined in 12.7.1.2 (PRF)" -- it's also used for things other
than FT and :11/12, no?
|
Change to "The KDF for the FT key hierarchy and for certain AKMs is a variant of the pseudorandom function (PRF) defined in 12.7.1.2 (PRF)"
|
GEN
|
Security
|
|
Dorothy Stanley
|
7727
|
41.01
|
3.2
|
The definition of an RSNA assumes a 4WH, but for FT the non-initial, a.k.a. "FT Protocol authentication" (13.5.2/3), as distinct from the initial, a.k.a. "FT association" (13.4.2) procedure
does not include a 4WH
|
Extend the definition to cover "FT Protocol authentication"
|
GEN
|
Security
|
|
Dorothy Stanley
|
7728
|
1962.43
|
12.6.1.1.6
|
It says " Because the PTKSA is tied to the PMKSA or to a PMK-R1 securityassociation, it only has the additional information from the 4-way handshake" -- forgets FT
|
Add "or FT Protocol authentication" at the end
|
GEN
|
Security
|
|
Dorothy Stanley
|
7729
|
1963.44
|
12.6.1.1.8
|
" A GTKSA is created by the Supplicant's SME when Message 3 of the 4-way handshake isreceived or when Message 1 of the group key handshake is received." -- forgets FT
|
Add "or when FT Protocol authentication is used" at the end
|
GEN
|
Security
|
|
Dorothy Stanley
|
7730
|
1964.04
|
12.6.1.1.9`
|
"a valid Message 3 of the 4-way handshake or FT 4-way handshake, the Reassociation Response message ofthe fast BSS transition protocol with a status code indicating success, a Mesh Peering
Open Message of theAuthenticated Mesh Peering Exchange (AMPE) protocol, or a valid Message 1 of the group key handshake." -- the MPOM has to indicate success too
|
Add "with a status code indicating success" after "(AMPE) protocol"
|
GEN
|
Security
|
|
Dorothy Stanley
|
7739
|
1994.34
|
12.7.1.7.3
|
Q is unnecessary and confusing (not used elsewhere)
|
Define Length rather than Q in the para below (by adding 128 to each, obviously), delete the Length definition, and use Length 128 where you currently have Q in the two equations before
the "where"
|
GEN
|
Security
|
|
Dorothy Stanley
|
7740
|
2065.5
|
12.10.2
|
" a 256-bit key" is duplication
|
Delete the cited text
|
GEN
|
Security
|
|
Edward Au
|
7134
|
2504.27
|
21.2.5.2
|
The approved comment resolution that inserted the new first para in this subclause called for it to be inserted later in the subclause.
|
Determine if the new first para needs to be moved to a better location in this subclause.
|
GEN
|
VHT PHY
|
|
Edward Au
|
7135
|
2504.31
|
21.2.5.2
|
I believe the inequality is the wrong way round.
|
change "less than" to "greater than" in the inequality on this line.Make matching change at 2506.13And change the text at 2330.43 to match.
|
GEN
|
VHT PHY
|
|
Edward Au
|
7355
|
2925.16
|
C.3
|
"When this attribute is false, the STA may accept MSDUs that have the Protected Frame subfield of the Frame Control field equal to 0." -- so it might not? What does "accept" mean here,
exactly?
|
Delete this sentence
|
GEN
|
MIB
|
|
Edward Au
|
7437
|
2875.55
|
C.3
|
There are 5 instances of "fixed-point Part". However, the whole thing is fixed-point; what is being referred to is actually the integer part
|
Change "fixed-point Part" to "integer part" in all 5 instances
|
GEN
|
MIB
|
|
Edward Au
|
7438
|
2875.55
|
C.3
|
There are 5 instances of "This field contains the fixed-point Part of Altitude." Where is the fractional part held?
|
Add 5 MIB variables to hold the corresponding fractional parts
|
GEN
|
MIB
|
|
Edward Au
|
7556
|
2681.01
|
B.4
|
CFDMG and CFDMGSTA are the same thing
|
Change all CFDMGSTAs to CFDMGs and delete the CFDMGSTA row
|
GEN
|
PICS
|
|
Edward Au
|
7633
|
|
|
There are half a dozen instances of "with a valid FCS". These should be removed, as it is implicit that if a frame has an invalid FCS you haven't received anything (otherwise you'd have
to pepper every second line of the spec with "with a valid FCS"!)
|
Delete all 5 instances of "with a valid FCS"
|
MAC
|
MAC Operation
|
|
Edward Au
|
7698
|
2919
|
C.3
|
Both dot11VHTExtendedNSSBWSignaling and dot11VHTExtendedNSSBWCapable claim to indicate "that the IEEE Std 802.11 VHT Extended NSS BW Support Signaling option is implemented"
|
Make one be "Implemented" and the other "Enabled"
|
GEN
|
MIB
|
|
Edward Au
|
7767
|
2875.55
|
C.3
|
The wording after "when object dot11PHYType" in the MIB is inconsistent.
|
Make it consistent
|
EDITOR
|
Editorials
|
|
Emily Qi
|
7101
|
1706.09
|
11.11.10.3
|
"the reporting AP has dot11LciCivicInNeighborReport and the neighbor AP has LCI MeasurementCapability (RM Enabled Capabilities element with the LCI Measurement Capability Enabled fieldset
to 1) dot11RMLCIMeasurementActivated equal to true"-- this has at least two errors "has dot11LciCivicInNeighborReport" and"Measurement Capability (...) dot11RMLCIMeasurementActivated equal to true"Note that " (RM Enabled Capabilities element with the LCI Measurement
Capability Enabled field set to 1)" is also a informal way of anonymously referencing a transmission by the AP)." this can also be improved. This informality occurs in a number of places in this subclause. The proposed changes addresses two of these.
|
Change cited text to:"the reporting AP has dot11LciCivicInNeighborReport equal to true and the neighbor AP indicates support for LCI measurement(the neighbor AP has transmitted an RM
Enabled Capabilities element with the LCI Measurement Capability Enabled field equal to true)"Make matching changes at 1706.32.
|
MAC
|
MAC Operation
|
|
Emily Qi
|
7104
|
1897.37
|
11.46
|
"the STA may assume any value for the average MSDU size" - No normative effect can be attributed to "may assume"?
|
Reword in terms of observable behaviour.
|
EDITOR
|
MAC Operation
|
|
Emily Qi
|
7267
|
1272.58
|
10.3.2.3.5
|
""A correctly received frame is one where the PHY-RXEND.indication primitive does not indicate an error and the FCS indicates the frame is error free." is the very definition of frame
reception
|
Delete the cited sentence
|
MAC
|
MAC Operation
|
|
Emily Qi
|
7310
|
1346.56
|
10.21.4
|
"When dot11OperatingClassesImplemented is true, the following statements apply:" -- the first statement is already made in the previous subclause
|
Delete the first bullet
|
MAC
|
MAC Operation
|
|
Emily Qi
|
7316
|
873.41
|
9.4.2.40
|
"When included in a Beacon, Probe Response, or Location Track Notification frame, the Antenna ID identifies the antenna(s) used to transmit the Beacon, Probe Response, or Location Track
Notification frame. When included in a measurement report, or Location Track Notification frame, the Antenna ID identifies the antenna(s) used for the reported measurement or transmission of the Location Track Notification frame. The valid range for the Antenna
ID is 1 to 254. The value 0 indicates that the antenna identifier is unknown. The value 255 indicates that this measurement was made with multiple antennas, i.e., antennas were switched during the measurement duration. In a Beacon Report or Frame Report, the
Antenna ID always identifies the antenna used to receive the reported beacon or frame." but it's not clear to me that the antenna element can be included in anything except a beacon or probe response (from grepping for "Antenna element")
|
Change to "The Antenna ID identifies the antenna(s) used to transmit the frame the Antenna element is contained in. The valid range for the Antenna ID is 1 to 254. The value 0 indicates
that the antenna identifier is unknown. The value 255 indicates that this transmission was made with multiple antennas, i.e., antennas were switched during the transmission."
|
MAC
|
Frame Formats
|
|
Emily Qi
|
7501
|
1361.04
|
10.22.2.10.1
|
"All retransmission attempts by a non-DMG STA for an MPDU that is not sent under a block ack agreement and that has failed the acknowledgment procedure one or more times shall be made
with the Retry subfield set to 1 in the Data or Management frame. " -- what is the purpose of the words from "in the" onwards? Maybe better to move the "Data or Management" to the "MPDU" and delete from "in the" onwards. Ditto next sentence. Ditto in the DCF:
"All retransmission attempts for an MPDU the Type subfield equal to Data or Management that has failed the Ack procedure one or more times shall be made with the Retry field set to 1 in the Data or Management frame." - delete from "in the onwards").
|
As it says in the comment
|
MAC
|
MAC Operation
|
|
Emily Qi
|
7590
|
1063.21
|
9.4.2.167
|
Status Indication and Value need to be specified as being reserved for the initiating STA
|
As it says in the comment
|
MAC
|
Frame Formats
|
|
Gabor Bajko
|
7147
|
806.38
|
9.4.2.22.10
|
The mBSSID feature, as currently worded can be interpreted as meaning that if a non-AP STA can support n number of BSSIDs on the same antenna connector, then the mBSSID field would indicate
all of those BSSIDs, regardless of whether they are actively beaconing or not.The current wording could also be interpreted as only the BSSIDs which are 'configured' on the STA to be indicated, which was the original intent of the feature. The suggested changes
remove the ambiguity and clarify the intent of the feature.see resolution in 11-16-0149-00-0000
|
see resolution in 11-16-0149-00-0000
|
MAC
|
Frame Formats
|
|
Ganesh Venkatesan
|
7207
|
335.01
|
6.3.57
|
The fixes made in 6.3.58 for FTM need to be made here too
|
E.g. fix the time at which the MLME-TIMINGMSMT.indication is sent, and the descriptions of where t1-t4 come from in each of the frames
|
MAC
|
MAC SAP
|
|
Ganesh Venkatesan
|
7818
|
1402.01
|
10.24.10
|
GCR must actually do Block Ack reordering, because Replay Detection will blow up otherwise. It would be good to have text that made this clear. (It might be implied because GCR is just
a special case BA, but that's a bit weak.)
|
Add text clarifying that GCR does Block Ack reordering to 10.24.10, similar to 10.24.7.
|
MAC
|
MAC Operation
|
|
Graham Smith
|
7038
|
1133.11
|
9.6.8.3
|
The structure for the Measurement Pilot frame cannot be parsed. It is not possible to distinguish between an optional subelement and an element of the same ID. For example, a vendor specific
subelement cannot be distinguished from the vendor specific element which is permitted to follow the action field.This confusion is completely unnecessary because the "subelements" can be declared as optional fields carrying the elements in the subelement
table.
|
Remove the optional sublement IDs field, and replace with optional Multiple BSSID and Wide Bandwidth Channel Switch fields.
|
MAC
|
Frame Formats
|
|
Graham Smith
|
7039
|
1140.52
|
9.6.8.11
|
"The Vendor Specific Content contains the vendor-specific fields and may include elements defined in thestandard." -- normative verb in Clause 9.But as the vendor specific content is
defined by the vendor, and might, for example, also include a compressed version of 'War and Peace' by Tolstoy, or the current price of Rubber Ducks in outer Mongolia, it is not appropriate (and certainly not necessary) for the Standard to speculate as to
its content.
|
Replace cited sentence with "The Vendor Specific Content is not defined in this Standard." or "The Vendor Specific Content is outside the scope of this Standard."
|
MAC
|
Frame Formats
|
|
Graham Smith
|
7043
|
1189.54
|
9.6.14.9
|
"The Preferred Candidate List Included bit set to 0 indicates that the receiving STA may ignore theBSS Transition Candidate List Entries field." - normative verb in Clause 9
|
Move cited text to Clause 10/11, or change to "can" here and cite subclause that defines this behavior.
|
MAC
|
Frame Formats
|
|
Graham Smith
|
7079
|
624.01
|
9.3.3.3
|
In Tables we have "Order" column, what does this mean? It implies that this is the order that the elements should be transmitted in, or is it simply the order that they were invented?
For example, having looked at beacons from several APs the elements are not transmitted in the order as per Table 9-27. I find that in the beacon, Table 9-27, 1, 2, 3, 4, 5 and 6 are in order in each I measured, but then it varies. What to do? It is clear
that "Order" has not been interpreted as the order in which they are transmitted, so what is it? We could replace "Order" with #, OR specify that the transmitted order is informative only, or fix the order of the first ones? Tables affected: 9-27 to 9-41 inclusive.
Ask for opinions first and then prepare a contribution if positive
|
Several options come to mind and would benefit from discussion however, here is one idea: Add a sentence such as "In Tables 9-27 to 9-41 the Information shall be transmitted in the order
given for Orders 1, 2, 3 and 4. The remaining Information may be transmitted in any order." (I don't like this but it should be enough to get opinions and maybe a solution).
|
MAC
|
Frame Formats
|
|
Graham Smith
|
7080
|
1410.46
|
10.26.2
|
1410.7 "The NonERP_Present bit shall be set to 1 when a NonERP STA is associated with the BSS" 1410.46 "The Use_Protection bit may be set to 1 when the NonERP_Present bit is 1." 1410.48
"If one or more NonERP STAs are associated in the BSS, the Use_Protection bit shall be set to 1 in transmitted ERP elements." This last criteria seems to be in contrast to the previous statement on line 46. If a NonERP STA is associated then then the Non_ERO
Present bit is set AND Use_Protection bit is set. Is the condition "The NonERP_Present bit may be set to 1 at any time because the AP feels like it?" Then the L46 is OK. BUT we read that there are some conditions when the NonERP_Present bit can be set, for
example, in IBSS it is optional, and if there is an overlapping NonERP STA, i.e. not associated. So, strictly speaking the sentence is correct but it is saying nothing. If nothing else make it a 'should'
|
1410.46 to read "The Use_Protection bit should be set to 1 when the NonERP_Present bit is 1."
|
MAC
|
MAC Operation
|
|
Graham Smith
|
7081
|
1271.14
|
10.3.2.3.3
|
"The SIFS shall be used prior to transmission of an (#1198)Ack frame, a CTS frame, a PPDU containing a BlockAck frame that is an immediate response to either a BlockAckReq frame or an
A-MPDU, a DMG CTS frame, a DMG DTS frame,(#5112) a Grant (#1198)Ack frame, a response frame transmitted in the ATI,(11ad)(Ed) the second or subsequent MPDU of a fragment burst, and by a STA responding to any polling by the PCF. The SIFS may also be used by
a PC for any types of frames during the CFP (see 10.4 (PCF))." No mention of SIFS between data packets in a TXOP. Needs to be added to list.
|
At 1271.12. After "The SIFS may also be used by a PC for any types of frames during the CFP (see 10.4 (PCF))" add ", or within a TXOP."
|
MAC
|
MAC Operation
|
|
Graham Smith
|
7082
|
1271.14
|
10.2.3.2.2.
|
"The SIFS timing shall be achieved when the transmission of the subsequent frame is started at the TxSIFS slot boundary as specified in 10.3.7 (DCF timing relations)." "Shall be achieved"?
I don't know what that means. Reading the rest of the para does not help either as it is concerned with the accuracy. I think it is trying to say that if teh TXSIFS slot boundary us used then this is SIFS Timing.
|
Replace cited sentence with "The SIFS timing is when the transmission of the subsequent frame is started at the TxSIFS slot boundary as specified in 10.3.7 (DCF timing relations)."
|
MAC
|
MAC Operation
|
|
Graham Smith
|
7084
|
1297.01
|
10.3.7
|
Figure 10-19 is confusing to say the least: It looks as though SIFS = (D1+M1+Rx/TX), this is not true, (D1+M1+Rx/TX) should have expired before the SIFS boundary. Similarly for PIFS and
DIFS and Slot time.
|
Redraw Fig 10-19 such that the time blocks end before the next boundaries, as it says in comment
|
MAC
|
MAC Operation
|
|
Graham Smith
|
7085
|
1297.39
|
10.3.7
|
Equation 10-2 aSIFS Time should be >=, as all the times in the equation must be completed before the boundary. Similarly Equation 10-3 aSlot Time should be >=
|
Change "=" to ">=" for equations 10-2 and 10-3.
|
MAC
|
MAC Operation
|
|
Graham Smith
|
7087
|
1350.12
|
10.22
|
EDCA should be same or very similar to DCF but with AIFS[AC] in place of DIFS. The way it is presented by using the 'EDCA Slot Boundaries' is confusing and very unclear as to what bouindary
applies at what decision point.
|
The commenter will bring a contribution to 'clean up' and clarify EDCF operation. It has too many mistakes to list here.
|
MAC
|
MAC Operation
|
|
Graham Smith
|
7088
|
1351.39
|
10.22.2.4
|
A BIG PROBLEM exists with the "aRxTxTurnaroundTime" inclusion in every slot boundary. If it is in every slot determination, then each STA may/will have a different wait time. For example
assume the STA is at a randomly selected backoff slot and counting down, then every time the medium becomes busy then it should wait AIFS but if it waits "AIFS aRxTxTurnaroundTime" then a STA with a higher aRxTxTurnaroundTime waits less. In fact no STA will
actually wait AIFS which is the real need. The aRxTxTurnaroundTime is only used at the very end when the STA can switch on its TX early. One does wonder why this obsession with this turnaround, it was not used in DCF, and there is a case as to why it is not
required here. As long as the STA has waited for the prescribed time before it actually transmits, it does not matter if it goes earlier to make up for a turnaround time. It should not need telling. By the way, I recall that a practical value for this is 1-2us
(RIFS for example). However, if considered necessary, it has to be clear that this can only be used only once in the countdown, it cannot be used every time the medium goes busy and the countdown is halted otherwise the wait time is shortened and a STA with
a larger aRxTxTurnaroundTime actually has an advantage. We need to fix this
|
The commenter will bring a contribution to explain and correct this.
|
MAC
|
MAC Operation
|
|
Graham Smith
|
7089
|
1281.41
|
10.3.2.9
|
"The recognition of a valid Ack frame sent by the recipient of the MPDU requiring acknowledgment,""...valid Ack frame sent by the recipient of the MPDU requiring acknowledgment" is wrong
as the ACK frame does not include the address of the sender hence it is only assumed that the Ack is sent by the recipient of the MPDU. This entire paragraph has problems that were the subject of 15/1274. Due to lack of time, the resolution as provided in
15/1274r0 was not fully discussed and hence was rejected. A revision 15/1274r1 was written as a result of the liited comments that were made.
|
15/1274 r1 to be revised to refer to D5 and presented.
|
MAC
|
MAC Operation
|
|
Graham Smith
|
7090
|
1374.05
|
10.23.1
|
EDCA TXOPs of a mesh STA that has dot11MCCAActivated true shall not overlap with the time periods of any of its tracked MCCAOP reservations." -- but the section on EDCA doesn't describe
how to do it.
|
This was CID 5144 on D4.0. 15/1250r3 was prepared with proposed resolution. The resolution depends upon other changes which had not been agreed upon. Hence this propasal was pu tto one
side. 15/1250 will be updated to reference D5.0 and re-presented.
|
MAC
|
MAC Operation
|
|
Graham Smith
|
7137
|
624.54
|
9.3.3.3
|
DSSS Parameter Set clearly indicates the channel number only in 2.4GHz band only, but in practice it is used to indicate 5GHz channels.
|
Remove 2.4GHz only reference where appropriate and change name. Submitter will submit proposal
|
MAC
|
Frame Formats
|
|
Graham Smith
|
7178
|
1273.58
|
10.3.2.3.7
|
"EIFS shall not be invoked if the NAV is updated by the frame that would have caused an EIFS, such as when the FCS fails and the L-SIG TXOP function employs L-SIG information to update
the NAV" -- what is the L-SIG TXOP function, and how does this update the NAV?
|
Either reword to talk of L-SIG TXOP protection, or delete
|
MAC
|
MAC Operation
|
|
Graham Smith
|
7179
|
1602.16
|
11.2.3.5
|
"The following rules describe operation of the ATIM frame and frame transmission to STAs in PS mode in a non-DMG IBSS and in a DMG BSS" -- so the rules apply to a DMG non-IBSS? This doesn't
make sense, especially since this is a subclause of "Power management in an IBSS"
|
Change "in a non-DMG IBSS and in a DMG BSS" to "in an IBSS"
|
MAC
|
MAC Management
|
|
Graham Smith
|
7212
|
1062.2
|
9.4.2.165
|
Discussions on D4.0 suggested the Quiet Channel element might be used for IBSSes, but it's not clear how this works, and also the field should then not be called "AP Quiet Mode"
|
Either add a statement to say that the Quiet Channel element can only be used in an infrastructure BSS, or delete "AP" from the name of the field
|
MAC
|
Frame Formats
|
|
Graham Smith
|
7278
|
144.01
|
6
|
In Clause 6, when an OperationalRateSet is passed down in MLME-JOIN/START.request, it can't include rates not in dot11SupportedDataRatesRxTable
|
Add this caveat to the "Valid range" cell (where it currently says 1-127). Make a similar statement about HT-MCS and VHT-MCSes
|
MAC
|
MAC SAP
|
|
Graham Smith
|
7280
|
201.52
|
6.3.11.2.2
|
The BSSBasicRateSet can't include rates not in both dot11SupportedDataRatesRxTable and dot11SupportedDataRatesTxTable
|
Add this caveat to the "Valid range" cell (where it currently says 1-127). Make a similar statement about HT-MCS and VHT-MCSes
|
MAC
|
MAC SAP
|
|
Graham Smith
|
7425
|
1772.36
|
11.24.6.4
|
"NOTE---The mechanism by which t1' and t4' are derived from the TOD and TOA fields, and the mechanism by which t2 and t3 are determined, are implementation dependent." -- also the mechanism
by which the TOD and TOA fields are determined for transmission. Also the primes around here seem to have variable italicness and indeed sex (sexless or not)
|
Change to "At the responding STA, the mechanism by which t1' and t4' are derived from the TOD and TOA fields, and the mechanism by which t2 and t3 are determined, are implementation dependent.
At the initiating STA, the mechanism by which the TOD and TOA fields are determined is implementation dependent."Make sure all the primes are the same throughout this subclause
|
MAC
|
MAC Management
|
|
Graham Smith
|
7434
|
657.22
|
9.4.1.4
|
"A STA sets the Short Slot Time subfield to 1 in transmitted Association Request, Reassociation Request, DLS Request, and DLS Response frames when dot11ShortSlotTimeOptionImplemented
and dot11ShortSlotTimeOptionActivated are true. Otherwise, the STA sets the Short Slot Time subfield to 0 in transmitted Association Request and Reassociation Request frames." -- and otherwise in DLS frames
|
Change the second sentence to "Otherwise, the STA sets the Short Slot Time subfield to 0."
|
MAC
|
Frame Formats
|
|
Graham Smith
|
7435
|
655.31
|
9.4.1.4
|
"An AP sets the ESS subfield to 1 and the IBSS subfield to 0 within transmitted Beacon or Probe Response frames. An IBSS STA sets the ESS subfield to 0 and the IBSS subfield to 1 in transmitted
Beacon or Probe Response frames. A mesh STA sets the ESS and IBSS subfields to 0 in transmitted Beacon or Probe Response frames." -- what about a non-AP STA in an infraBSS (e.g. in (re)assoc req), or (re)assoc rsp, or a PCP?
|
Change to "An AP or PCP sets the ESS subfield to 1 and the IBSS subfield to 0. An IBSS STA sets the ESS subfield to 0 and the IBSS subfield to 1. Otherwise, the ESS and IBSS subfields
are reserved."
|
MAC
|
Frame Formats
|
|
Graham Smith
|
7465
|
2231.22
|
16.1.1
|
"The basic HR/DSSS PHY" -- Is there an advanced HR/DSSS PHY? Is there a fortran HR/DSSS PHY?
|
Delete "basic", and perhaps refer to the HR/DSSS/long flavour
|
GEN
|
Terminology
|
|
Graham Smith
|
7496
|
533.59
|
6.5.4.2
|
"The Slot Time (in microseconds) that the MAC uses for defining the PIFS and DIFSs." -- it does more than those two IFSes
|
Change to "... defining the IFSs"
|
MAC
|
MAC SAP
|
|
Graham Smith
|
7541
|
1351.21
|
10.22.2.4
|
What exactly is "the backoff procedure" for EDCA? Is it the thing which starts with waiting for AIFS of idleness, or the thing which starts with throwing a random number and then waiting
for that number of slots of idleness, or what? The term is used in many places, but this is hard if it's not defined!
|
At the end of the second para of 9.22.2.4 insert "The backoff procedure starts with this step."
|
MAC
|
MAC Operation
|
|
Graham Smith
|
7550
|
1764.23
|
11.24.6
|
When may an FTM session be implicitly terminated (i.e. no FTM with DT 0)?
|
Add a statement that the responding STA may terminate an FTM session at any point (not just after the last FTM frame of the last burst instance)
|
MAC
|
MAC Management
|
|
Graham Smith
|
7580
|
872.18
|
9.4.2.39
|
This subclause is written as if there were only one EDCAF, but there are 4
|
Change "EDCAF" to "the EDCAFs considered together" or something
|
MAC
|
Frame Formats
|
|
Graham Smith
|
7581
|
877.15
|
9.4.2.44
|
It says " EDCA services" -- what's that?
|
Change to " EDCAF"
|
MAC
|
Frame Formats
|
|
Graham Smith
|
7586
|
|
|
What exactly does "mandatory" mean in the context of rates(/MCSs/preambles/etc.) in PHYs? If a rate is "mandatory", does that mean it has to be included in the operational and/or basic
rate set? Can a device refuse to associate with another device that does not include all mandatory rates, or conversely can a device assume that other devices will include all mandatory rates? The direction the D4.0 BRC was going in when it ran out of time
was that no, it need not be in either set (see 15/1207)
|
Add a "NOTE---A STA is not required to include all mandatory rates in its operational rate set, and a STA starting a BSS is not required to include all mandatory rates in the basic rate
set."
|
MAC
|
MAC Operation
|
|
Graham Smith
|
7640
|
1567.15
|
11.1.4.3.4
|
Re CID 5208: The assertion "multi-band capable non-AP STAs can respond to Probe Requests" needs some backing evidence (i.e. a specificspec location where this is required/allowed, other
than the location which was the subject of that comment)
|
Delete this criterion
|
MAC
|
MAC Management
|
|
Graham Smith
|
7654
|
1574.61
|
11.2.2.2
|
"To change power management modes a STA shall inform the AP by completing a successful frameexchange (as described in Annex G) that is initiated by the STA and that includes a Management
frame,Extension frame or Data frame, and also an Ack or a BlockAck frame from the AP." does not make it clear that the frame exchange is required to include an Ack/BA (the NOTE 1 below does make this clear, but it's not normative)
|
Change to "To change power management modes a STA shall inform the AP by completing a successful frameexchange (as described in Annex G) that is initiated by the STA and that is required
to include a Management frame,Extension frame or Data frame, and also an Ack or a BlockAck frame from the AP."
|
MAC
|
MAC Management
|
|
Graham Smith
|
7700
|
555.12
|
8.3.5.10.4
|
"The effect of receipt of this primitive by the PHY entity is to reset the PHY CS/CCA timers to the stateappropriate for the end of a received frame and to initiate a new CCA evaluation
cycle." -- what PHY CS/CCA timers?
|
Change to "The effect of receipt of this primitive by the PHY entity is to reset the PHY to the stateappropriate for the end of a received frame and to initiate a new CCA evaluation cycle."
|
MAC
|
PHY SAP
|
|
Graham Smith
|
7769
|
1744.52
|
11.23.6
|
"any" v. "all" in"Switching to a 40 MHz off-channel direct link is achieved by including the following information in the TDLS Channel Switch Request frame:--- Operating Class field indicating
40 MHz Channel Spacing--- Secondary Channel Offset field indicating SCA or SCB" implies all need to be present"v."Switching to a wideband off-channel direct link is achieved by including any of the following information in the TDLS Channel Switch Request frame:---
An Operating Class element indicating 40 MHz Channel Spacing--- A Secondary Channel Offset element indicating SCA or SCB--- A Wide Bandwidth Channel Switch element indicating 80 MHz, 160 MHz, or 80+80 MHz channel width"
|
State that 11.23.6.3 only applies to non-VHT HT STAs and 11.23.6.5 only applies to VHT STAs
|
MAC
|
MAC Management
|
|
Graham Smith
|
7771
|
1298.26
|
10.3.7
|
Table 10-5 does not have any rows for VHT or DMG modulations. Ipso facto, dynamic EIFS cannot be used with these
|
Change 1298.13 to say "When dot11DynamicEIFSActivated is true, the PPDU that causes the EIFS does not contain a singleMPDU with a length equal to 14 or 32 octets, and this PPDU is covered
by one of the rows in Table 10-5, EIFS is determined as shown in Equation 10-7."
|
MAC
|
MAC Operation
|
|
Graham Smith
|
7772
|
1628.33
|
11.3.5.5
|
Where is the AP/PCP definition of the reassociation initiation procedures on the current AP (which might as a special case be the same as the new AP), and in particular all the stuff
which is deleted or reset (such as BA agreements)?
|
Add a:p) If the ResultCode in the MLME-REASSOCIATE.response primitive is SUCCESSand the CurrentAPAddress parameter in the MLME-REASSOCIATION.indication primitive had the new AP's MAC
address in theCurrentAPAddress parameter (reassociation to the same AP), the following states, agreements andallocations shall be deleted or reset to initial values:1) All EDCAF state2) Any block ack agreements3) Sequence number4) Packet number5) Duplicate
detection caches6) Anything queued for transmission7) Fragmentation and reassembly buffers8) Power management mode9) WNM sleep mode.The following states, agreements and allocations are not affected by the reassociation procedure:1) PSMP sessions2) Enablement/Deenablement3)
GDD enablement4) STSL, DLS and TDLS agreements5) SMKSAs, STKSAs and TPKSAs established with any peers6) MMSLs7) GCR agreements8) DMS agreements9) TFS agreements10) FMS agreements11) Triggered autonomous reporting agreements12) FTM sessions13) DMG SP and CBAP
allocations.
|
MAC
|
MAC Management
|
|
Graham Smith
|
7773
|
1730.39
|
11.16.9
|
"the STA may transmit a pending 40 MHz mask PPDU only if the secondary channel has also been idle during the times the primary channel CCA is performed (defined in 9.3.7 (DCF timing relations))
during an interval of a PIFS for the 5 GHz band and DIFS for the 2.4 GHz band immediately preceding the expiration of the backoff counter." -- why the difference?
|
Change to "the STA may transmit a pending 40 MHz mask PPDU only if the secondary channel has also been idle during the times the primary channel CCA is performed (defined in 9.3.7 (DCF
timing relations)) during an interval of a PIFS immediately preceding the expiration of the backoff counter."
|
MAC
|
MAC Management
|
|
Graham Smith
|
7786
|
1689.26
|
11.11.9.1
|
In a Beacon report, how is the bandwidth indicated? I don't think it's the Operating Class field, because an OC only gives the maximum BSS bandwidth, not necessarily the actual BSS bandwidth
(e.g. you can operate a 20 MHz bandwidth in an OC which specifies a BSS bandwidth of "up to 40 MHz")
|
Add at the end of the subclause "NOTE---An operating class indicating 40 MHz (or up to 40 MHz) is used to indicate a 40 MHz PPDU only."
|
MAC
|
MAC Management
|
|
Graham Smith
|
7788
|
1290.51
|
10.3.4.3
|
What does "CWindow" indicate in Figure 10-15, exactly? It seems to be some kind of fixed period after DIFS for any station that just transmitted a frame, but no such period exists
|
Delete "CWindow" from Figure 9-15, including the key
|
MAC
|
MAC Operation
|
|
Graham Smith
|
7789
|
1270.28
|
10.3.2.3.1
|
Figures 10-4, 10-10, 10-14 say or at least suggest there is immediate access when the medium is idle for DIFS or AIFS. This is only the case if the CW is zero. We do not want people thinking
they can just transmit after DIFS/AIFS, except in very specific circumstances
|
Add "and CW is zero" in the identified figures
|
MAC
|
MAC Operation
|
|
Graham Smith
|
7822
|
1123.6
|
9.6.5.2
|
ADDBA (9.6.5.2) points to 9.3.1.8 for the definition of the Starting Sequence Control field. But, 9.3.1.8 only makes sense in the context of a BAR, not an ADDBA.
|
Duplicate the text for Starting Sequence Control field (copy from 9.3.1.8) in 9.6.5.2.
|
MAC
|
Frame Formats
|
|
Graham Smith/Mark Rison
|
7292
|
144.01
|
6
|
There are some parameters called "SupportedRate", but this concept is not defined
|
Change to "OperationalRateSet" for MLME-(RE)ASSOCIATE.indication and MLME-DLS.*
|
MAC
|
MAC SAP
|
|
Guido Hertz
|
7160
|
1899
|
12
|
The 802.11 standard misses a method to operate an encrypted WLAN without authentication.
|
Include the changes proposed in 11-15/1184 into the standard.
|
GEN
|
Security
|
|
Guido Hertz
|
7219
|
1678.02
|
11.9.8.4.3
|
"Transitioning to a new channel does not tear down mesh peerings and, as long as themesh peers move to the new operating channel, their peerings may be maintained in the new channel."
-- they should always be maintained, at least from the side which commanded the channel switch
|
Change "may be" to "are"
|
MAC
|
MAC Management
|
|
Guido Hertz
|
7372
|
2152.14
|
14.10.8.3
|
"HWMP SNs are strictly increasing unsigned integers." contradicts "Comparing HWMP SNs is done using a circular modulo 2**32 comparison."
|
Delete lines 12 and 14 and make line 15 a plain para
|
GEN
|
Mesh
|
|
Guido Hertz
|
7611
|
2124.01
|
14.4.3
|
Cf CID 5746, not all the parameters of the actions in this subclause are described. More specifically none except the peerMAC argument is described (unlike the events above)
|
Add descriptions of the non-peerMAC parameter to the actions, based on the events (or otherwise)
|
GEN
|
Mesh
|
|
Jon Rosdahl
|
7509
|
|
|
The term "Vendor OUI or CID" is used in 3 places, but what's the precedence
|
If it's "Vendor OUI or Vendor CID" then need to define a Vendor CID? If it's "Vendor OUI, or CID" then change to that, i.e. add a comma
|
GEN
|
Terminology
|
|
Jouni M.
|
7420
|
1949.37
|
12.5.3.3.6
|
It says "A CCMP protected individually addressed robust Management frame shall be protected with the TK." -- what about other CCMP-protected frames? Note for the recipient this is clearer:
"A CCMP protected individually addressed robust Management frame shall use the same TK as a Data frame."
|
Change to "A CCMP protected frame shall be protected with the appropriate TK, where a CCMP protected individually addressed robust Management frame shall use the same TK as a Data frame."
|
GEN
|
Security
|
|
Jouni M.
|
7421
|
1949.37
|
12.5.5.3.6
|
It says "A GCMP protected individually addressed robust Management frame shall be protected with the TK." -- what about other GCMP-protected frames? Note for the recipient this is clearer:
"A GCMP protected individually addressed robust Management frame shall use the same TK as a Data frame."
|
Change to "A GCMP protected frame shall be protected with the appropriate TK, where a GCMP protected individually addressed robust Management frame shall use the same TK as a Data frame."
|
GEN
|
Security
|
|
Jouni M.
|
7462
|
1967.23
|
12.6.1.3.2
|
", or if the PMK in the cached PMKSA is no longer valid," -- how can this be determined? How is this even possible -- doesn't invalidation of a PMK also invalidate the whole PMKSA?
|
Delete the cited text. Also at 1975.45
|
GEN
|
Security
|
|
Jouni Malinen
|
7347
|
828.35
|
9.4.2.25
|
A, uh, popular implementation of the RSN protocol cannot cope with RSNE counts that are zero (it does *not* skip over them and just use the defaults)
|
In 9.4.2.25.2 after "The Pairwise Cipher Suite Count field indicates the number of pairwise cipher suite selectors that are contained in the Pairwise Cipher Suite List field." add "The
value 0 is reserved."In 9.4.2.25.3 after "The AKM Suite Count field indicates the number of AKM suite selectors that are contained in the AKM Suite List field." add "The value 0 is reserved."In 9.4.2.25.5 change " The PMKID Count specifies the number of PMKIDs
in the PMKID List field. The PMKID list contains 0 or more PMKIDs" to "The PMKID Count field specifies the number of PMKIDs in the PMKID List field. The value 0 is reserved. The PMKID List field contains PMKIDs"
|
MAC
|
Frame Formats
|
|
Mark Hamilton
|
7069
|
854.62
|
9.4.2.31
|
" An incoming MSDU that is not classified to a particular TS may be classified to another active TS based on the frame classifier for that TS." - normative verb in clause 9
|
Move normative behaviour to clause 10/11.
|
MAC
|
Frame Formats
|
|
Mark Hamilton
|
7146
|
134.1
|
5.1.5.1
|
A role-specific behaviour is not shown for a DMG relay.If security on a DMG relay is established for each leg of the relay, then the data-flow must pass through the controlled port, and
therefore be shown in the role-specific behaviour.
|
Determine whether to show a role-specific behaviour for a DMG relay, which would be similar to a mesh STA.
|
MAC
|
Architecture
|
|
Mark Hamilton
|
7150
|
3581.01
|
Annex N
|
Annex N contains terminology that is unique to itself, such as WLAN system and ACM_STA. The understanding of what a DS is has developed and change in the ARC standing committee, resulting
in changes to Clause 5. Annex N has been ignored.
|
Review Annex N and change terminology and architecture to conform to the normative portions of the draft.
|
MAC
|
Architecture
|
|
Mark Hamilton
|
7317
|
1554.34
|
11.1.2.1
|
"A STA contained in the AP or PCP shall initialize its TSF timer independently of any simultaneously started APs or PCPs" -- this cannot in general be acheved, unless the APs/PCPs are
coordinated. Needs to be restricted to managed ("enterprise/corporate") contexts, but this is arguably out of scope of the standard anyway
|
Change to "A STA contained in the AP or PCP shall initialize its TSF timer independently of any simultaneously started APs or PCPs it is aware of", or delete
|
MAC
|
MAC Management
|
|
Mark Hamilton
|
7324
|
48.3
|
9.4.2.2
|
"When the UTF-8 SSID subfield of the Extended Capabilities element is equal to 1 in the frame that includes the SSID element, the SSID is interpreted using UTF-8 encoding." -- but the
extended caps are static so it doesn't have to be in the same frame
|
Delete the sentence
|
MAC
|
Architecture
|
|
Mark Hamilton
|
7378
|
126.47
|
4.10.7
|
It says "PMK or PSK key identifier" -- what's a pairwise shared key key identifier? Also at line 49
|
Change both to "PMK identifier"
|
MAC
|
Architecture
|
|
Mark Hamilton
|
7553
|
104.5
|
4.5.4.3
|
Does "PMKSA caching" include "mesh PMKSA caching", given that a "mesh PMKSA" is not a type of "PMKSA"? Is mesh PMKSA caching even defined?
|
Delete "or mesh PMKSA" at the end of the sentence
|
MAC
|
Architecture
|
|
Mark Hamilton
|
7658
|
79.32
|
4.3.13
|
What about dot11VHTExtendedNSSBWCapable?
|
Add a line "--- "dot11TVHTExtendedNSSBWCapable" replaces "dot11VHTExtendedNSSBWCapable".
|
MAC
|
Architecture
|
|
Mark Hamilton
|
7790
|
1289.4
|
10.3.4.2
|
It says "pending MPDU". What's one of those?
|
See CID 6440 resolution
|
MAC
|
MAC Operation
|
|
Mark Hamilton
|
7792
|
1294.18
|
10.3.4.4
|
"The AP shall attempt todeliver one MSDU or MMPDU to the STA that transmitted the PS-Poll frame, using any frame exchangesequence valid for an individually addressed MSDU or MMPDU." --
can also deliver an A-MSDU
|
Add, ", A-MSDU" after each "MSDU"
|
MAC
|
MAC Operation
|
|
Mark Hamilton
|
7807
|
96.06
|
4.4.1
|
Why is the first paragraph of 4.4.1 here? It (and the first sentence of the second paragraph) should be the first paragraph of 4.4.4.
|
Move the first paragraph, and first sentence of the second paragraph, of 4.4.1 to be the start of subclause 4.4.4 instead. Replace the first sentence of the second paragraph with, "IEEE
Std 802.11 explicilty does not specify the details of implementation of the architectural components."
|
MAC
|
Architecture
|
|
Mark Hamilton
|
7808
|
96.01
|
4.4
|
Review 4.4 through 4.9. How are these descriptions different/aligned with clauses 5, 6, 7 and 8?
|
Perform technical and editorial review and remove duplication and bring like concepts together.
|
MAC
|
Architecture
|
|
Mark Hamilton
|
7814
|
1357.29
|
10.22.2.7
|
There is a problem with this NOTE, in that it describes normative exception behavior that does not seem to be clearly stated in normative text (from three and two paragraphs up, for example).
|
Change this NOTE to normative text, and mention the exclusion ("except following a PS-Poll" or something similar) in the previous paragraphs two, and three, before this one.
|
MAC
|
MAC Operation
|
|
Mark Hamilton
|
7816
|
64.19
|
4.2.5
|
4.2.5 says 802.11 has to act like a _wired_ network. No, it has to act like an 802 network (including 802.1 MAC Service requirements).
|
Delete "wired"
|
MAC
|
Architecture
|
|
Mark Hamilton
|
7817
|
133.54
|
5.1.5.1
|
In Figure 5-1, put BA sscoreboarding between Address 1 address filtering and Duplicate Detection.
|
In Figure 5-1, add a block to the Receiving flow side for "Block Ack scoreboarding", between "Address 1 address filtering" and "Duplicate Detection". Use "(null)" for the transmitting
flow side. Same thing in Figure 5-2.
|
MAC
|
Architecture
|
|
Mark Hamilton
|
7819
|
131.29
|
5.1.5.1
|
Fix 5.1.5.1 4th paragraph to be in the right order.
|
Align the order of items in the text with Figure 5-1 (running up the Receiving side of the stack).
|
MAC
|
Terminology
|
|
Mark Hamilton
|
7826
|
653.35
|
9.3.5
|
Figure 9-63 is missing some DSes
|
Insert a box labelled "DS" between the Gate and Portal, and another similar one between the Gate and AP.
|
MAC
|
Frame Formats
|
|
Mark Hamilton
|
7827
|
3505.13
|
R.3.2
|
This subclause has some significant problems with the architecture of an "AP" and its "BSS". (A single AP can't have multiple BSSIDs, for example. This is probably multiple APs and probably
also multiple ESSs, SSIDs, DSs and Portals. There could be a single physical device that includes the multiple APs, but that is a different architectural structure, and not made clear here.)
|
An Interworking expert will be needed to sort this out.
|
GEN
|
Architecture
|
|
Mark Rison
|
7061
|
831.53
|
9.4.2.25.2
|
"AnAP may specify the selector 00-0F-AC:0 (Use group cipher suite) for a pairwise cipher suite if it does notsupport any pairwise cipher suites." - normative verb in clause 9
|
Either change to "can specify" or "specifies" depending on whether this is truly optional behaviour and cite clause 10/11/12 location that defined this behaviour; or move this to clause
10/11/12.
|
GEN
|
Security
|
|
Mark Rison
|
7086
|
1289.48
|
10.3.4.2
|
"There are conditions, specified in 10.3.4.3 (Backoff procedure for DCF) and 10.3.4.5 (Control of the channel), where the random backoff procedure shall be followed even for the first
attempt to initiate a frame exchange sequence." This appears to indicate that the random back off for the first transmission is an exception rather than the rule. In fact the DCF clauses leave a lot to be desired, are difficult to follow and do not seem to
stress the basic DCF Sequence.
|
The commenter will bring a contribution to 'clean up' and clarify DCF operation.
|
MAC
|
|
|
Mark Rison
|
7133
|
2221.54
|
15.4.4.3
|
The para at this line was introduced in response to an approved comment resolution thus: " Incorporate the changes in 11-15/762r15 for CID 6676/6677 which clarifies the issue."However,
the resolution should have called out R16, which was discussed, and which does not contain the editing instruction "", which was the cause of the insertion.
|
Delete cited paragraph.Likewise delete the paragraph at 2249.50
|
GEN
|
Other PHY
|
|
Mark Rison
|
7177
|
1342.21
|
10.16
|
In order to reduce power consumption, there should be a dynamic mechanism to request to a peer that it not transmit to the requesting device using LDPC
|
Add a mechanism, based on extending Operating Mode Notification or otherwise
|
MAC
|
|
|
Mark Rison
|
7208
|
339.01
|
6.3.58
|
For MLME-FINETIMINGMSMT.request, "Set to the value of t1 (see Figure 6-17)" is misleading because it is not set to the t1 in the figure but to the time for the previous request. Ditto
t4. And for the .indication it's the time in the FTM frame, which is again not the t1 and t4 in the figure
|
Change the text as indicated in the comment
|
MAC
|
MAC SAP
|
|
Mark Rison
|
7210
|
661.41
|
9.4.1.8
|
In 9.4.1.8 AID field the MSBs are no longer required to be set. Might some existing implementations have set them, and if so might some existing implementations get confused if they are
not set? Note this is about the AID field in MMPDUs, not the ID field in PS Polls
|
Say the two MSBs are reserved, to try to make everyone (equally un)happy
|
MAC
|
Frame Formats
|
|
Mark Rison
|
7213
|
2574.45
|
12.3.11.3
|
The term "MU-capable STA" is not defined. It should be defined as an AP that supports MU-MIMO tx or a non-AP STA that is MU beamformee capable. Alternatively, since the term is hardly
used (3 instances, pp. 78, 1058, 2574), and where it is used it is only used for non-AP STAs, replace it with "MU beamformee capable"
|
As it says in the comment
|
GEN
|
Terminology
|
|
Mark Rison
|
7218
|
2946.39
|
C.3
|
dot11BeaconRssiTable makes no sense. It seems to suggest there could be 2**32 entries, each with a MAC address and an RSSI
|
Add a mechanism which allows the size of the table to be limited, e.g. the SME requests specific BSSIDs, or the device advertises some kind of limit
|
GEN
|
MIB
|
|
Mark Rison
|
7221
|
2531.35
|
19.3.21
|
The term "PHY header" (with case variation) is used but not defined in Clause 19 (and arguably subsequent PHY clauses) and in the MAC
|
Add text to Clause 19 that defines what is meant by "PHY header" and also fix the case to "PHY header" throughout
|
GEN
|
VHT PHY
|
|
Mark Rison
|
7225
|
|
|
The description of the PHYCONFIG_VECTOR is missing for DSSS, HR/DSSS, ERP, DMG and TVHT
|
Add such a description
|
GEN
|
Other PHY
|
|
Mark Rison
|
7226
|
549.01
|
8.3.4.4
|
The description of the vectors in Clause 8 makes no sense. The various PHYs have very different vectors, so trying to have a generic description just doesn't work ("The name of the field
used to specify the Tx data rate and report the Rx data rate may vary for different PHYs").FWIW, my notes on D4.0 say that the parameters were disposed of as follows:active_rxchain_set: 10.2.5operating_channel: 22.2.4.2, 22.2.4.3channel_offset 22.2.4.2, 22.2.4.3ant-config:
T21.1 onlygroup_id_management: 10.41, 22.3.11.4, 22.3.20partial_aid_list_gid00: 9.20, 22.3.20partial_aid_list_gid63: 9.20, 22.3.20listen_to_gid00: 10.41, 22.3.20listen_to_gid63: 10.41, 22.3.20
|
Delete this subclause (or make it just say that each PHY defines its vectors), and move all the information to the PHY clauses. The PHYCONFIG_VECTORs should be described in tabular form,
as the TX/RXVECTORs are
|
GEN
|
PHY SAP
|
|
Mark Rison
|
7237
|
2236.3
|
16.2.3.6
|
The Example of LENGTH calculations for CCK should show the boundary case, i.e. the case where LENGTH-LENGTH' is exactly 8/11
|
Add such a row
|
GEN
|
Other PHY
|
|
Mark Rison
|
7240
|
1017.26
|
9.4.2.129
|
"A non-PCP and non-AP STA that receives a DMG Operation element can use the value of this field to configure the AssociateFailureTimeout parameter in the MLME-ASSOCIATE.request primitive
and theReassociateFailureTimeout parameter in the MLME-REASSOCIATE.request primitive." -- there are no such parameters anymore (we deleted them in favour of dot11(Re)AssociationResponseTimeOut)
|
Given that there are various other FailureTimeoutParameters, perhaps we should reverse our prior change and deprecate the MIB variable instead
|
MAC
|
Frame Formats
|
|
Mark Rison
|
7244
|
162.13
|
6.3.5.3.1
|
What happens if the AuthenticateFailureTimeout in the MLME-AUTHENTICATE.request (which gives the overall timeout) is more than the dot11AuthenticationResponseTimeOut (which is for consecutive
frames in an auth sequence)?
|
Add words to say that the former shall be no more than the latter times the number of message pairs in the sequence
|
MAC
|
MAC SAP
|
|
Mark RISON
|
7255
|
946.18
|
9.4.2.72
|
It says " the Capability information field of the BSS" -- what's that?
|
Change to "the contents of the Capability Information field in beacons for the BSS"
|
MAC
|
Frame Formats
|
|
Mark Rison
|
7273
|
|
|
There seem to be at least three flavours of awake window: mesh, TDLS and DMG. The first seems to be so denoted, but the others not
|
Add "TDLS" or "DMG" before "awake window" where "mesh" is not present there
|
GEN
|
Terminology
|
|
Mark Rison
|
7281
|
150.51
|
6.3.3.3.2
|
126 and 127 are not valid "rate"s (they're BSS membership selectors)
|
Change "1-127" to "1-125" here and at the top of the next page
|
EDITOR
|
MAC SAP
|
|
Mark Rison
|
7282
|
159.3
|
6.3.4.2.2
|
126 and 127 are not valid "rate"s (they're BSS membership selectors)
|
Change "1-127" to "1-125"
|
EDITOR
|
MAC SAP
|
|
Mark Rison
|
7283
|
173.47
|
6.3.7.3.2
|
126 and 127 are not valid "rate"s (they're BSS membership selectors)
|
Change "1-127" to "1-125" and add a row for BSSMembershipSelectorSet
|
EDITOR
|
MAC SAP
|
|
Mark Rison
|
7284
|
177.36
|
6.3.7.4.2
|
126 and 127 are not valid "rate"s (they're BSS membership selectors)
|
Change "1-127" to "1-125"
|
EDITOR
|
MAC SAP
|
|
Mark Rison
|
7285
|
187.29
|
6.3.8.3.2
|
126 and 127 are not valid "rate"s (they're BSS membership selectors)
|
Change "1-127" to "1-125" and add a row for BSSMembershipSelectorSet
|
EDITOR
|
MAC SAP
|
|
Mark Rison
|
7286
|
190.5
|
6.3.8.4.2
|
126 and 127 are not valid "rate"s (they're BSS membership selectors)
|
Change "1-127" to "1-125"
|
EDITOR
|
MAC SAP
|
|
Mark Rison
|
7287
|
201.52
|
6.3.11.2.2
|
126 and 127 are not valid "rate"s (they're BSS membership selectors)
|
Change "1-127" to "1-125"
|
EDITOR
|
MAC SAP
|
|
Mark Rison
|
7288
|
246.6
|
6.3.27.3.2
|
126 and 127 are not valid "rate"s (they're BSS membership selectors)
|
Change "1-127" to "1-125"
|
EDITOR
|
MAC SAP
|
|
Mark Rison
|
7289
|
247.58
|
6.3.27.4.2
|
126 and 127 are not valid "rate"s (they're BSS membership selectors)
|
Change "1-127" to "1-125"
|
EDITOR
|
MAC SAP
|
|
Mark Rison
|
7290
|
249.03
|
6.3.27.5.2
|
126 and 127 are not valid "rate"s (they're BSS membership selectors)
|
Change "1-127" to "1-125"
|
EDITOR
|
MAC SAP
|
|
Mark Rison
|
7311
|
2330.39
|
19.2.5
|
"the MAC shall" in a PHY clause
|
Move to a MAC clause
|
GEN
|
MAC Operation
|
|
Mark Rison
|
7312
|
2504.27
|
21.2.5.2
|
"the MAC shall" in a PHY clause
|
Move to a MAC clause
|
GEN
|
MAC Operation
|
|
Mark Rison
|
7313
|
2506.09
|
21.2.5.3
|
"the MAC shall" in a PHY clause
|
Move to a MAC clause
|
GEN
|
MAC Operation
|
|
Mark Rison
|
7320
|
564.01
|
9.2.2
|
Like ASCII strings, UTF-8 strings should not be terminated
|
Add "or UTF-8" after "ASCII"
|
MAC
|
Frame Formats
|
|
Mark Rison
|
7349
|
1258.01
|
10
|
It was stated during D4.0 comment resolution (*cough*Adrian*cough*) that "transmission of the Beacon at TBTT is a famously individual and unnamed channel access function"
|
Add a subclause on this CAF
|
MAC
|
MAC Management
|
|
Mark Rison
|
7368
|
549.06
|
8.3.4.4
|
"Parameters in the vectors that are management rather than MAC may be specific to the PHY" -- what on Earth does that mean?
|
Delete the whole sentence
|
GEN
|
PHY SAP
|
|
Mark Rison
|
7376
|
1949.26
|
12.5.3.3.6
|
"A transmitter shall not use IEEE Std 802.11 MSDU or A-MSDU priorities without ensuring that the receiver supports the required number of replay counters." is not clear. It mixes indices
(priorities) with a count (#rc)
|
Reword as something like "A transmitter shall not use an IEEE Std 802.11 MSDU or A-MSDU priority if this would cause the total number of priorities used during the lifetime of the SA
to exceed the number of replay counters supported by the receiver for that SA."
|
GEN
|
Security
|
|
Mark Rison
|
7377
|
1966.22
|
12.6.1.3.2
|
"A STA performing secure password-based, or PSK, authentication uses" -- what is "secure PSK"? Is there an insecure PSK? If so, insecure PSK should be defined and obsoleted. If not, "secure"
should be deleted
|
Change to "A STA performing password-based authentication can use"
|
GEN
|
Security
|
|
Mark Rison
|
7384
|
1719.55
|
11.14
|
This last para belongs to the subclauses in subclause 11.3 on receipt of Deauthentication/Disassociation frames
|
Move the material to subclause 11.3
|
EDITOR
|
Editorials
|
|
Mark Rison
|
7393
|
1616.06
|
11.3.1
|
"The state variable is kept within the MLME (i.e., is written and read by the MLME). The SME may also read this variable." -- err, how?
|
Add a SAP primitive allowing the SME to find out about changes to the state variable for a given peer
|
MAC
|
MAC Management
|
|
Mark Rison
|
7396
|
1281.32
|
10.3.2.9
|
"After transmitting an MPDU that requires an Ack frame as a response (see Annex G), the STA shall wait for an AckTimeout interval" -- isn't a BA analogue of this needed?
|
Extend this para to cover the case where a BA is required
|
MAC
|
MAC Operation
|
|
Mark Rison
|
7398
|
1335.31
|
10.11
|
"A STA that participates in a successful ADDTS exchange that included a U-PID element with the No-LLC field equal to 1 shall strip the LLC header from an MSDU corresponding to the TID
indicated in the ADDTS exchange before transmission of the MSDU" -- how, exactly? Specifically, does the STA check that the expected LLC header is present, or blindly strip the first n octets from the MSDU?
|
Add a statement that the STA just strips the first n octets from the MSDU without any checking
|
MAC
|
MAC Operation
|
|
Mark Rison
|
7399
|
1045.09
|
9.4.2.154
|
Why is a No-LLC field needed? Doesn't a zero-length LLC Header Copy field already indicate this?
|
Delete the No-LLC header field
|
MAC
|
Frame Formats
|
|
Mark Rison
|
7400
|
1045.22
|
9.4.2.154
|
Is Table 9-244 normative, i.e. are no other LLC Header Copy field sizes allowed, and are no other LLC header types allowed?
|
Make the table informative
|
MAC
|
Frame Formats
|
|
Mark Rison
|
7417
|
2321.59
|
19.2.1
|
In clauses 19, 20, 21 the wording is different in the PHY service interface intro:19) The PHY interfaces to the MAC through the TXVECTOR, TXSTATUS, RXVECTOR, and PHYCONFIG_VECTOR.20)
The PHY provides an interface to the MAC through an extension of the generic PHY service interface defined in 8.3.4 (Basic service and options). The interface includes TXVECTOR, RXVECTOR, andPHYCONFIG_VECTOR.21) The PHY provides an interface to the MAC through
an extension of the generic PHY service interface defined in 8.3.4 (Basic service and options). The interface includes TXVECTOR, RXVECTOR, andPHYCONFIG_VECTOR.
|
Make these consistent: include TXSTATUS for 20 and 21, don't claim it's an extension (since the vectors are all under 8.3.4) and generally align the wording
|
GEN
|
PHY SAP
|
|
Mark Rison
|
7419
|
128.53
|
5.1.1.4
|
10.8 says "For MSDUs or A-MSDUs belonging to the service class of QoSAck when the receiver is a QoS STA, the QoS Data frames that are used to send these MSDUs or A-MSDUs shall have the
Ack Policy subfield in the QoS Control field set to Normal Ack, Block Ack, Implicit Block Ack Request, or PSMP Ack." But 5.1.1.4 says "When an MSDU is received from the MAC SAP with [QoSAck] and the recipient STA is a QoS STA [...] the MSDU is transmitted
using a QoS Data frame with the Ack Policy subfield in the QoS Control field set to either Normal Ack (normal acknowledgment) or Block Ack."
|
Work out which is right and make the other one say the same. Even better, avoid the duplication
|
MAC
|
MAC Operation
|
|
Mark Rison
|
7427
|
1740.44
|
11.23.1
|
"A DMG STA shall not use the TDLS protocol." -- may it use DLS?
|
Change to "A DMG STA shall not use the DLS or TDLS protocols."
|
MAC
|
MAC Management
|
|
Mark Rison
|
7428
|
36.47
|
3.2
|
The definition of "non-HT PPDU" excludes PPDUs sent by 11abg PHYs - this does not sound right (e.g. wording like "is carried in a non-HT PPDU" would then break)
|
Either change the definition to include PPDUs sent by 11abg PHYs, or examine the 71 or so instances and decide which should become "DSSS, HR/DSSS, ERP or OFDM PPDU"
|
GEN
|
Definitions
|
|
Mark Rison
|
7429
|
1579.25
|
11.2.2.5.2
|
"The non-AP STA may transmit multiple ADDTS Request frames to the AP where the last received ADDTS Request frame will override any previously received ADDTS Request frame." -- this seems
too general: it only applies if the TID/direction are the same. Any anyway, what is this doing in 11.2.2.5.2 U-APSD coexistence
|
Confirm the specific rules for one ADDTS Req overriding an earlier one are covered elsewhere, then delete this sentence
|
MAC
|
MAC Management
|
|
Mark Rison
|
7431
|
1622.07
|
11.3.5
|
There are 6 instances of "set to State 4(,) or State 3 if RSNA establishment is required" -- -- how does the MLME know? Using the presence of the RSNE in the MLME-ASSOC.resp? No, it's
not defined there. Using the MIB variable? It's not clear an RSNA is required if dot11RSNAActivated is set to true ("When this object is true, this indicates that RSNA is enabled on this entity.")
|
Change "if RSNA establishment is required" to "if dot11RSNAActivated is true" in each case, after verifying whether this is indeed necessary and sufficient
|
MAC
|
|
|
Mark Rison
|
7446
|
|
|
We should not be using "packet" except in specific cases like "Packet Number" and "Null Data Packet" (see also CID 5362)
|
Scrub them from 19.3.18.5, 20.3.6.4, I.1.8, T19-9, T19-10, 20.10.2.2.4, TK-2, F19-21, F20-2, F20-6, F20-7, F20-23, 6.5.9, 6.5.10, T8-4, T9-51, T9-161, T9-165, 9.4.2.130, 9.4.2.136, 9.4.2.142.1,
9-245, 9.4.2.158.2, 9.4.2.167, 9.5.3, 9.5.4, 10.3.2.3.3, 10.7.7.1, 10.7.7.5, 10.26.5.1, 10.30, 10.32.2.4.3, 10.32.3, 10.34.1, 10.36.6.2, 10.38.3.1, 10.38.3.2, 10.38.6, 10.38.7, 10.41.3.2.3, 11.6, 12.5.4.4, 12.6.21, 13.6.3, 14.12.2, endemically in the PHYs
(and hence the PICS), C.3, G.4, I.5, I.6, I.7, I.8, K.4, P.2, T.2.4, T.2.7changing to MPDU/PPDU/frame as appropriate (it might help to define "sounding packet" so this term can continue to be used)
|
GEN
|
Terminology
|
|
Mark Rison
|
7448
|
532.01
|
6.5
|
The PHY test modes are not used anywhere, and are not defined for PHYs other than DSSS and DMG
|
Delete subclauses 6.5.5/6/9.10. Alternatively, add test modes for the other PHYs and also add text in the PHY clauses to indicate how the test modes are to be used (e.g. state in 16.4.5.10
Transmit modulation accuracy), RX is a bit more ambiguous (see 16.4.6.2 Receiver minimum input level sensitivity and 17.3.7.9 Transmit modulation accuracy) which arguments are needed in the primitives to effect the requisite testing; if kept then old stuff
like 33 Mb/s also needs to be deleted
|
MAC
|
MAC SAP
|
|
Mark Rison
|
7455
|
2229.35
|
15.4.6.5
|
"within 5 us of the start of a MAC slot boundary"-- how does the PHY know where the MAC slot boundaries are?
|
If the answer is PHY-CCARESET.request, say so, and make sure the MAC is required to send this at every slot boundary
|
GEN
|
Other PHY
|
|
Mark Rison
|
7456
|
2259.33
|
16.3.8.5
|
"within 5 us of the start of a MAC slot boundary"-- how does the PHY know where the MAC slot boundaries are?
|
If the answer is PHY-CCARESET.request, say so, and make sure the MAC is required to send this at every slot boundary
|
GEN
|
Other PHY
|
|
Mark Rison
|
7468
|
1066.3
|
9.4.2.167
|
"The FTM Format And Bandwidth field indicates the requested or allocated packet format and bandwidth used by all Fine Timing Measurement frames in an FTM session" -- this is not true,
since FTM frames can use a simpler or narrower format than indicated.
|
Change to "The FTM Format And Bandwidth field indicates the requested or allocated PPDU format and bandwidth that can be used by Fine Timing Measurement frames in an FTM session"
|
MAC
|
Frame Formats
|
|
Mark Rison
|
7471
|
2404.55
|
19.3.20
|
In the PHYs, there are statements that "PHY-TXSTART shall be disabled. What does this mean? How can the name of a (class of) primitive be disabled?
|
Change to say that the PPDU transmission initiated by a PHY-TXSTART shall be terminated
|
GEN
|
Other PHY
|
|
Mark Rison
|
7474
|
562.08
|
8.3.5.17.2
|
When is PHY-TXBUSY.indication(IDLE) issued? The spec only discusses PHY-TXBUSY.indication(BUSY)
|
Add a statement that it is issued when the conditions for the BUSY are no longer met
|
GEN
|
PHY SAP
|
|
Mark Rison
|
7478
|
1574.36
|
11.2.2.1
|
"When a STA enters normal (non-APSD) PS mode, any downlink block ack agreement without an associated schedule is suspended for the duration of this PS mode." -- what does "suspended"
mean? For example, does this mean fragmentation is allowed?
|
Change to say that A-MPDUs shall not be used for that BA agreement
|
MAC
|
MAC Management
|
|
Mark Rison
|
7480
|
3393.57
|
E.2.5
|
"Be aware that most protocols above the MAC operate in the opposite endianness" should be a NOTE (cf.1075.1)
|
As it says in the comment
|
GEN
|
MAC Operation
|
|
Mark RISON
|
7484
|
1348.59
|
10.22.2.2
|
The rules for "successful transmission and transmission failure" for the purposes of EDCA backoff are made harder to follow because terms are not used consistently:: "If $blah, the STA
concludes that the transmission of the MPDU has failed." and then "$foo shall be interpreted as failure of the MPDU transmission." and then "$bar is defined to be a failure." They should all be of the same form (e.g. "shall be considered transmission failure")
|
In this subclause, always use "MPDU", not "frame", and express the rules in the same way (so e.g. not "the STA concludes that the transmission of the MPDU has failed" and then "The recognition
of a valid response frame [...] shall be interpreted as a successful response.")
|
MAC
|
MAC Operation
|
|
Mark Rison
|
7486
|
1589.51
|
11.2.2.15.1
|
There are 12 statements of the form "STA shall set dot11FooActivated to true/false". But dot11FooActivated is set by the SME, not the STA. Also, If dot11FooActivated is supposed to be
set internally, then dot11OCBActivated is wrong
|
Delete all these statements
|
GEN
|
MIB
|
|
Mark Rison
|
7499
|
549.25
|
8.3.4.4
|
"At most 4 bits out of 8 may be set to 1." for ACTIVE_RXCHAIN_SET - does this mean that a VHT STA with > 4 receive chains can't use SMPS (because a STA with SMPS is required to enable
all rx chains when not in SMPS mode)?
|
Delete this restriction
|
MAC
|
PHY SAP
|
|
Mark Rison
|
7500
|
738.13
|
9.4.2.9
|
Coverage class can only be specified in units of about 900 m. This is not useful for medium-size BSSes (of the order of 100 m, say). Brian HART adds "And it doesn't deal with OBSS, where
slotted Aloha becomes heterogeneously slotted Aloha (aka unslotted Aloha)."
|
Add coverage class values providing finer control
|
MAC
|
Frame Formats
|
|
Mark Rison
|
7503
|
1413.26
|
10.26.3.1
|
In Table 9-12, what is the difference between "Transmit an initial frame within a non-HT PPDU that requires a response frame. The remaining TXOP following the first PPDU exchange may
contain PPDUs using HT-greenfield format and/or separated by RIFS." and "Using a PPDU with the TXVECTOR FORMAT parameter set to HT_MF, transmit first a PPDU that requires a response that is sent using a non-HT PPDU. The remaining TXOP following the first PPDU
exchange may contain HT-greenfield format and/or RIFS sequences."? The second seems to be a subset of the first.
|
Replace the two rows with one saying "Transmit first a PPDU that requires a response that is sent using a non-HT PPDU. The remaining TXOP following the first PPDU exchange may contain
PPDUs using HT-greenfield format and/or separated by RIFS."
|
MAC
|
MAC Operation
|
|
Mark Rison
|
7521
|
1720.1
|
11.14
|
More generally, what is the range of all the "random number"s in the spec and the things that are chosen "randomly"?
|
Specify the range and distribution in each case
|
GEN
|
Math
|
|
Mark Rison
|
7527
|
|
|
"GTK key", "PSK key identifier", "IGTK key", "TPK key", "PTK Key Holder", "PTK key", "PMK key", "SMK key", "SKCK key", "STK Key" all suffer from RAS syndrome.
|
Delete "key" (case-insensitively) in all such instances
|
GEN
|
Security
|
|
Mark Rison
|
7528
|
2875.55
|
C.3
|
There are millions of MIB variables/tables to do with LCIs and civic locations, and it is not clear which are used in which contexts (TVWS, DSE, FTM, neighbour report, etc.)
|
Add some words to the parent MIB node to disambiguate them all (including the way in which/why an index is used, where an index is used)
|
GEN
|
MIB
|
|
Mark Rison
|
7529
|
647.08
|
9.3.3.15
|
There is no reason Action No Acks can't have MICEs. While at the moment it may be the case that such frames carry "information [...] that is of time critical but transient value" (resolution
of CID 6343), this is not a property of Action No Acks per se
|
Add MICEs to Table 9-39 as in Table 9-38
|
MAC
|
Frame Formats
|
|
Mark Rison
|
7532
|
1880.47
|
11.42
|
"A STA that is not a VHT STA shall setdot11OperatingModeNotificationImplemented to false." -- there is no justification for this. Why can't an HT non-VHT STA do OMN?
|
Delete this sentence
|
MAC
|
MAC Management
|
|
Mark Rison
|
7540
|
1283.09
|
10.3.2.12
|
In 10.3.2.12 Duplicate detection and recovery, what is meant by "QoS Data"? In "a TID subfield in the QoS Control field within QoS Data frames" it appears to refer to any Data frame with
b7 set, but it's not clear in "A STA operating as a QoS STA transmitting a QoS Data frame", "A STA receiving frames that are not QoS Data", "A QoS STA receiving an individually addressed QoS Data frame"
|
Use either "with Subtype field equal to QoS Data" or "QoS (+Data)" (or whatever it is) phraseology, depending on what is intended
|
MAC
|
MAC Operation
|
|
Mark Rison
|
7542
|
1622.07
|
11.3.5
|
The changes made for CID 6375 need to be makde for reassociation too
|
As it says in the comment
|
MAC
|
MAC Management
|
|
Mark Rison
|
7544
|
222.31
|
6.3.19.1
|
The Direction parameter of MLME-SETKEYS.request is never used in the spec. As far as I can determine, the actual behaviour assumed by the spec is that SETKEYS enables the key for both
directions, and MLME-SETPROTECTION.request allows finer control. Also, what's a "Direction element"?
|
Delete the Direction row at 223.25. Change from 223.41 to: "Receipt of this primitive causes the MAC to apply the keys as follows, subject to the MLME-SETPROTECTION.request primitive:---
The MAC uses thekey information for the transmission of all subsequent frames to which the key applies.--- The MAC installsthe key with the associated Key ID such that received frames of the appropriate type and containingthe matching Key ID are processed
using that key and its associated state information."
|
MAC
|
MAC SAP
|
|
Mark Rison
|
7549
|
1146.29
|
9.6.8.16
|
The TDLS Discovery Response frame format (which is the only TDLS frame which is not tunnelled in a Data frame) does not have space for VSIEs. Note this is not the usual thing where you
have an Action field being described, where the Action frame containing the Action field can have some VSIEs after it
|
Allow for VSIEs at the end of the frame
|
MAC
|
Frame Formats
|
|
Mark Rison
|
7555
|
228.3
|
6.3.24.1.4
|
What about the other direction?
|
Change the two bullets to "--- Rx: Specifies that Data frames from the MAC address are protected (i.e., any Data frames without protection received from the MAC address are discarded)
but data frames to the MAC address are not protected.--- Tx: Specifies that Data frames to the MAC address are protected but data frames from the MAC address are not protected."
|
MAC
|
MAC SAP
|
|
Mark Rison
|
7561
|
3179.35
|
C.3
|
dot11STALCITable OBJECT-TYPE"This table represents the geolocation of the STA as specified in 11.44.1 (General)."is too vague. The way it represents it (AIUI from the TGmc teleconf on
2015-06-05) is as a bounding polygon containing the STA
|
Describe this bounding polygon thing here or in 11.44.1
|
GEN
|
MIB
|
|
Mark Rison
|
7562
|
3179.44
|
C.3
|
dot11STALCIEntry OBJECT-TYPE"STA's location information in geospatial coordinates" is not true, AIUI from the TGmc teleconf on 2015-06-05. Each entry is a point on a bounding polygon
containing the STA
|
Describe this bounding polygon thing here or in 11.44.1
|
GEN
|
MIB
|
|
Mark Rison
|
7572
|
222.31
|
6.3.19.1
|
"If the Direction element of the SetKeyDescriptor indicates Transmit or Both then the MAC uses the key information for the transmission of all subsequent frames to which the key applies."
-- it should be clearer this applies to the Key ID also, i.e. all subsequent frames transmitted for that type and peer specify the Key ID given
|
As it says in the comment
|
MAC
|
MAC SAP
|
|
Mark Rison
|
7573
|
|
|
3.4 claims that GCMP is "Galois/Counter Mode with GMAC Protocol", where GMAC is "Galois Message Authentication Code", but 38.57, 39.13, 43.13, 68.11 think it's "Galois Counter Mode protocol"
and 12.5.5 thinks it's "GCM with Galois Message Authentication Code (GMAC) protocol"
|
Work out what GCMP really stands for, and make sure it's expanded thusly everywhere
|
GEN
|
Security
|
|
Mark Rison
|
7589
|
1719.55
|
11.14
|
"If a non-AP STA that has an SA with its AP for an association that negotiated management frame protection receives an unprotected Deauthentication or Disassociation frame with reason
code INVALID_CLASS2_FRAME or INVALID_CLASS3_FRAME from the AP" -- this should be in the clauses dealing with receipt of deauth/disassoc
|
Move the behavioural description to subclauses 11.3.4.5 and 11.3.5.9, splitting it into the form "if get this frame then invoke SA as defined in x.x"
|
MAC
|
MAC Management
|
|
Mark Rison
|
7592
|
1581.34
|
11.2.2.6
|
If in a U-APSD SP an AP ends the SP part-way through a fragmented MSDU/MMPDU, what happens at the next SP? Does the AP start from the beginning?
|
Add "If the BU is fragmented but not all fragments are transmitted within the current service period, it shall start the next service period with the first unacknowledged frame."
|
MAC
|
|
|
Mark Rison
|
7593
|
1576.53
|
11.2.2.5.1
|
Does the part-BU of the previous SP count as one or zero (if the Max SP Length was not indeterminate)?
|
After "An unscheduled SPends after the AP has attempted to transmit at least one BU using a delivery-enabled AC and destined for theSTA, but no more than the number indicated in the Max
SP Length field of the QoS Capability element ofthe STA's (Re)Association Request frame if the field has a nonzero value" add ", including any BU that was already partially transmitted in a previous unscheduled SP"
|
MAC
|
|
|
Mark Rison
|
7602
|
3237.62
|
C.3
|
Either get rid of dot11EDThreshold, or extend its use to all the PHYs (i.e. not just DSSS and HR/DSSS)
|
As it says in the comment
|
GEN
|
MIB
|
|
Mark Rison
|
7603
|
1766.49
|
11.24.6.3
|
A STA should be required to specify a FTM Format and Bandwidth that it (and the BSS, if associated) support
|
As it says in the comment
|
MAC
|
MAC Management
|
|
Mark Rison
|
7604
|
224.15
|
6.3.20.1.2
|
Why is "Valid range" N/A for the Key ID in MLME-DELETEKEYS.request?
|
Copy the corresponding cell in MLME-SETKEYS.request
|
GEN
|
Security
|
|
Mark Rison
|
7607
|
7.3
|
3
|
The TK/MK stuff is incomplete/inconsistent:3.1 has GMK, GTK, IGTK. Why are these not in 3.2?3.2 has 4WH, 4WSTKH, FT4WH, GKH, GTKSA, PMK, PMKSA, PTK, PTKSA, PKH, SMK, SMKH, SMKSA, STK,
STKSA.3.4 has GMK, GTK, GTKSA, IGTK, IGTKSA, MGTK, [no MGTKSA], MTK, PMK, PMKID, PMKSA, PTK, PTKSA, SMK, [no SMKID], SMKSA, STK, STKSA.Missing TPKSA, mesh PMKSA, mesh TKSA, mesh GTKSA.
|
Move the identified definitions from 3.1 to 3.2Add the identified missing expansions in 3.4Add missing definitions in 3.2
|
GEN
|
Security
|
|
Mark Rison
|
7608
|
534.55
|
6.5.4.2
|
"The relationship between aMACProcessingTime and the IFS and slot timing is described in 9.3.7 (DCF timing relations) and illustrated in Figure 9-19 (DCF timing relationships)." -- needs
to be extended to EDCA
|
Add references to the EDCAF timing relations subclause and figure
|
MAC
|
MAC SAP
|
|
Mark Rison
|
7612
|
22.01
|
3.2
|
Cf CID 5746, we have "mesh profile" in Clause 3, but not "mesh configuration"
|
Add a definition of "mesh configuration"
|
GEN
|
Definitions
|
|
Mark Rison
|
7615
|
26.08
|
3.2
|
The definition of "base channel" is not clear. For example, in an 80 MHz BSS, with a STA that only supports 40 MHz but has sent an Notify Channel Width or Operating Mode Notification
specifying 20 MHz, is the "base channel" from that STA's perspective a 20, 40 or 80 MHz channel?
|
Make it clear whether the "base channel" is the BSS bandwidth, the maximum bandwidth supported by the STA, or the operating bandwidth
|
GEN
|
Definitions
|
|
Mark Rison
|
7616
|
26.08
|
3.2
|
The definition of "base channel" is not clear. If the "base channel" varies when the STA's operating bandwidth changes (through Notify Channel Width or Operating Mode Notification) then
what does that do to any existing TDLS link where one or the other device does not support "TDLS Wider Bandwidth"?
|
Make it clear whether the "base channel" is the BSS bandwidth, the maximum bandwidth supported by the STA, or the operating bandwidth, and make sure this is compatible with devices that
do not support TDLS Wider Bandwidth
|
GEN
|
Definitions
|
|
Mark Rison
|
7617
|
22.01
|
3.2
|
The definitions of GMK, GTK, IGTK, PMK, PTK, SMK, STK (maybe also AEK and MTK) need to be aligned
|
As it says in the comment
|
GEN
|
Security
|
|
Mark Rison
|
7618
|
22.01
|
3.2
|
The definition of "temporal encryption key" needs to cover TKs other than group and pairwise ones
|
As it says in the comment
|
GEN
|
Definitions
|
|
Mark Rison
|
7619
|
22.01
|
3.2
|
The definition of "temporal key"/"TK" should be generic (i.e. include GTK and IGTK and STK and MTK) but sometimes refers only to the TK (temporal key) in a PTK (transient key)
|
Problem is that PTK already has a different meaning... Find a way to distinguish temporalKs and transientKs
|
GEN
|
Definitions
|
|
Mark Rison
|
7621
|
2223.22
|
15.4.4.7
|
What does "The TX-to-RX turnaround time shall be measured at the air interface from the trailing edge of the last transmitted symbol to valid CCA detection of the incoming signal. The
CCA should occur within 25 us (10 us for turnaround time plus 15 us for energy detect) or by the next slot boundary occurring after 25 us has elapsed (refer to 15.4.6.5 (CCA)). A receiver input signal 3 dB above the ED threshold described in15.4.6.5 (CCA)
shall be present at the receiver." mean? Does it mean that an 11-original device can be "deaf" to CCA for 25 us after it has transmitted?
|
Reword to be clear that no, a device can't just skip CCA for 25 us
|
GEN
|
Other PHY
|
|
Mark Rison
|
7622
|
2252.62
|
16.3.6.8
|
What does "The TX-to-RX turnaround time shall be measured at the air interface from the trailing edge of the last transmitted symbol to valid CCA detection of the incoming signal. The
CCA should occur within 25 us (10 us for turnaround time plus 15 us for energy detect) or by the next slot boundary occurring after 25 us has elapsed (refer to 16.3.8.5 (CCA)). A receiver input signal 3 dB above the ED threshold described in16.3.8.5 (CCA)
shall be present at the receiver." mean? Does it mean that an 11b device can be "deaf" to CCA for 25 us after it has transmitted?
|
Reword to be clear that no, a device can't just skip CCA for 25 us
|
GEN
|
Other PHY
|
|
Mark Rison
|
7623
|
2229.01
|
15.4.6.5
|
If aCCAtime needs to fit in slot time, does this mean it's necessary to detect a DSSS preamble within a slot time? This only allows about 8 bits of preamble, which seems insufficient.
Even worse is "With a valid signal (according to the CCA mode of operation) present at the receiver antenna within 5 us of the start of a MAC slot boundary, the PHY-CCA.indication(BUSY) primitive shall be generated before the end of the slot time.", which
seems to require ability to detect a DSSS preamble within 4 us (9 us slots minus 5 us before the valid signal turns up after the start of the slot) for CCA modes 2 or 3, even if the rx-tx turnaround time is 0!
|
Clarify how aCCAtime works for DSSS
|
GEN
|
Other PHY
|
|
Mark Rison
|
7624
|
2258.61
|
16.3.8.5
|
If aCCAtime needs to fit in slot time, does this mean it's necessary to detect a DSSS preamble within a slot time? This only allows about 8 bits of preamble, which seems insufficient.
Even worse is "With a valid signal (according to the CCA mode of operation) present at the receiver antenna within 5 us of the start of a MAC slot boundary, the PHY-CCA.indication(BUSY) primitive shall be generated before the end of the slot time.", which
seems to require ability to detect a DSSS preamble within 4 us (9 us slots minus 5 us before the valid signal turns up after the start of the slot) for CCA modes 4 or 5, even if the rx-tx turnaround time is 0!
|
Clarify how aCCAtime works for HR/DSSS
|
GEN
|
Other PHY
|
|
Mark Rison
|
7625
|
|
|
See other comments on aCCAtime, and then consider: more generally, which ED and PD requirements are required within aCCAtime, and which not?
|
Clarify
|
GEN
|
Carrier Sense
|
|
Mark Rison
|
7635
|
1564.44
|
11.1.4.3
|
What does "process all received probe responses" (2 instances) mean, exactly?
|
Change each to "process all received probe responses to construct BSSDescriptions corresponding to each"
|
MAC
|
|
|
Mark Rison
|
7650
|
2925.61
|
C.3
|
What happens if dot11RSNAActivated is true but the Assoc Req/Rsp doesn't contain an RSNE? Or vice-versa?
|
Mandate that an RSNE be passed over each SAP primitive if dot11RSNAActivated is true and that primitive carries a SAP; mandate that an RSNE not be passed if dot11RSNAActivated is false
|
GEN
|
MIB
|
|
Mark Rison
|
7655
|
1574.62
|
11.2.2.2
|
"initiated by the STA" -- so this means that the PM mode cannot be changed during RD. However, only timing distinguishes the last frame of a RD exchange from the first frame of a non-RD
exchange, which is awkward to validate
|
Allow the PM mode to be changed in RD
|
MAC
|
MAC Management
|
|
Mark Rison
|
7656
|
569.44
|
9.2.4.1.7
|
There is wide variation in the setting of the PM bit in Control frames
|
Say that the PM bit is ignored (not reserved, because some implementations do set it to 1) in Control frames
|
MAC
|
Frame Formats
|
|
Mark Rison
|
7657
|
569.44
|
9.2.4.1.7
|
Many implementations fail to distinguish between probe reqs to an associated AP and other probe requests (especially since in 802.11-2007 probe reqs did not carry a valid PM bit)
|
Say that the PM bit is ignored (not reserved, because some implementations do set it to 1) in probe reqs
|
MAC
|
Frame Formats
|
|
Mark Rison
|
7674
|
715.29
|
9.4.1.53
|
It says "The use of these fields is described in 10.7.12.1 (Rx Supported VHT-MCS andNSS Set), 10.7.12.2 (Tx Supported VHT-MCS and NSS Set), and 10.40.8(Extended NSS BW Support Signaling).
For a VHT STA, see Table 9-74(Setting of the Channel Width subfield and Dynamic Extended NSS BWsubfield at a VHT STA transmitting the Operating Mode field). " but the new Rx NSS text has no references to Clauses 9 or 10, but does have a reference to elsewhere
in Clause 8. This seems inconsistent
|
Either refer to Clauses 8 and 9/10 everywhere or nowhere
|
MAC
|
Frame Formats
|
|
Mark RISON
|
7675
|
715.31
|
9.4.1.53
|
"For a VHT STA, see Table 9-74(Setting of the Channel Width subfield and Dynamic Extended NSS BWsubfield at a VHT STA transmitting the Operating Mode field). " -- but this dynamic NSS
stuff is only supported by VHT STAs anyway. And this sentence is too far from the start of the cell
|
Just add T9-74 to the list of things in the previous sentence
|
MAC
|
Frame Formats
|
|
Mark Rison
|
7695
|
1461.44
|
10.34.5.2
|
It says "The maximum number of supported spatial streams for receive operation according to thecombination of the corresponding VHT beamformee's Rx VHT-MCS Map subfield in theSupported
VHT-MCS and NSS Set field and VHT Capabilities Information field The maximum number of supported spatial streams according to the Rx NSS subfield value and,when the value of VHT Extended NSS BW Capable subfield received from the VHT Beamformee is1, the Dynamic
Extended NSS BW Support value in the Operating Mode field of the most recentlyreceived Operating Mode Notification frame or Operating Mode Notification element with the RxNSS Type subfield equal to 0 from the corresponding VHT beamformee, as computed according
to10.7.12.1 (Rx Supported VHT-MCS and NSS Set)" -- whose receive operation this is (BFer or BFee?) and whose Rx VHT-MCS, VHT Cap Info and OM this is (BFer or BFee?)
|
Add "beamformee" or "beamformer" everywhere to dispel ambiguity
|
MAC
|
MAC Operation
|
|
Mark Rison
|
7699
|
393.25
|
6.3.72
|
6.3.72 WNM-Notification response (and maybe others) is missing a "General" or "Introduction" subclause at the start
|
Add such a subclause wherever missing
|
GEN
|
MAC SAP
|
|
Mark Rison
|
7703
|
|
|
CIDs 6214, 6215, 6216, 6305, 6306 had a broadly agreed direction (see discussion in 15/1155), but were not successfully resolved in the D4.0 BRC
|
Address the issues in the direction suggested in 15/1155
|
GEN
|
Carrier Sense
|
|
Mark Rison
|
7704
|
|
|
The attempts to resolve CIDs 6214, 6215, 6216, 6305, 6306 in the D4.0 BRC brought to light a number of technical issues
|
Address the issues in the direction suggested in 15/1155
|
GEN
|
Carrier Sense
|
|
Mark Rison
|
7732
|
1904.6
|
12.3.1
|
Explicitly mark WEP and TKIP as obsolete and might be removed (not just "deprecated")
|
As it says in the comment
|
GEN
|
Security
|
|
Mark Rison
|
7735
|
|
|
The stuff on the maximum transmit power is spread around all the place, and it's not immediately clear whether it's duplicated or overlapping or inconsistent.
|
Put it all in one places
|
MAC
|
MAC Management
|
|
Mark Rison
|
7745
|
3294.13
|
C.3
|
How does dot11APLCITable's index work? How can you have more than one LCI for an AP? Ditto dot11APCivicLocation
|
De-indexify these tables, i.e. make them just a SEQUENCE
|
GEN
|
MIB
|
|
Mark Rison
|
7746
|
1297.34
|
10.3.7
|
" provided that the CCAsensitivity specification for the attached PHY is met (see 15.4.6.5 (CCA), 16.3.8.5 (CCA), 17.3.10.6 (CCArequirements), 18.4.6 (CCA performance) and 19.3.19.5 (CCA
sensitivity))." -- what about Clauses 20 and 21 and 22?
|
Add references to the CCA bit of these. Or just delete the parenthesis
|
MAC
|
MAC Operation
|
|
Mark Rison
|
7747
|
1399.5
|
10.24.7.7
|
"An Originator that is a DMG STA shall construct A-MPDUs that contain MPDUs in increasing order of SN.When responding to a BlockAck frame, the Originator shall first retransmit unacknowledged
MPDUs inincreasing order of SN." -- what about wrap-around?
|
Add some words about "modulo 4096"
|
MAC
|
MAC Operation
|
|
Mark RISON
|
7748
|
1399.5
|
10.24.7.7
|
"An Originator that is a DMG STA shall construct A-MPDUs that contain MPDUs in increasing order of SN.When responding to a BlockAck frame, the Originator shall first retransmit unacknowledged
MPDUs inincreasing order of SN." So a DMG originator could:- first transmit an A-MPDU containing MPDUs with SNs 1, 3, 7 only, in that order- then receive a BA saying 1 and 7 were received- then transmit an A-MPDU containing MPDUs with SNs 3, 2, 4, 5, 6, 8
only, in that order;the first one (only) has the Retry bit setRight? How does the Retry bit help in this case?
|
Change the first sentence to "An Originator that is a DMG STA shall construct A-MPDUs that, apart from retransmissions of unacknowledged MPDUs, contain MPDUs in sequential SN order, starting
from the first MPDU that has never been transmitted."Note that this probably does not allow:first an A-MPDU with Ack Policy "Block Ack" (11)then SIFSthen an A-MPDU with Ack Policy "Implicit Block Ack Request" (00)Is such a sequence allowed in DMG? If so, the
wording will probably have to be more complicated.And if DMG allows partial-state scoreboard operation, the wording will be even trickier, because then you can't even say something like "which was not marked in the most recent Block Ack frame as having been
received" to clarify what is meant by "unacknowledged".Basically what we need to express in standardese is:- If you know you need to retx, you put all the retxes first, in SN order- You put all the non-retxes in consecutive SN order, starting from the first
SN that has not been txed- You are allowed to break things into multiple A-MPDUs, as long as the rules above are honoured, and all A-MPDUs but the last have "Block Ack" ack policyMaybe:An Originator that is a DMG STA shall transmit MPDUs sent under a BA agreement
such that:* MPDUs that need to be retransmitted are sent first, in SN order* MPDUs that are being transmitted for the first time are then sent, in consecutive SN order starting from the MPDU with the first SN that has not been transmitted* MPDUs may be transmitted
in more than one A-MPDU only if all but the last A-MPDU contains MPDUs with ack policy "Block Ack"where SNs are ordered based on modulo-4096 comparisons.
|
MAC
|
MAC Operation
|
|
Mark Rison
|
7764
|
280.53
|
6.3.38
|
Some MLME primitives (e.g. MLME-DSETPC) have no actual behavioural requirements associated with them (in Clause 11)
|
Ensure that all MLME primitives are referred to somewhere other than just Clause 6
|
GEN
|
MAC SAP
|
|
Mark Rison
|
7791
|
1309.05
|
10.7
|
The multirate rules are an impenetrable mess. It's impossible to determine whether they are complete, let alone whether they are correct
|
Rewrite as a flowchart or table, so that it can be seen that the rules are complete and correct
|
MAC
|
|
|
Mark Rison
|
7793
|
1313.28
|
10.7.6.1
|
10.7.6.1: "Control frames carried in an A-MPDU that does not contain a VHT single MPDU shall be sent at a rate selected from the rules defined in 10.7.5.7"10.7.5.7: is basically about
Data and Management frames, though "The rules in this subclause also apply to A-MPDUs that aggregate MPDUs of type Data or Management with any other types of MPDU."However Table 9-413---A-MPDU contents MPDUs in the control response context shows that you can
have an (non-VHT single MPDU) A-MPDU without a Data or Management frame. In that situation what rate is used?
|
Clarify
|
MAC
|
MAC Operation
|
|
Mark Rison
|
7794
|
|
|
The HT rules for CCA as they pertain to non-HT transmissions are not clear. The issue is that if you don't know you're dealing with a non-HT transmission (which you don't know unless
you successfully pick up the preamble) you don't know you have to apply the rules ("CCA sensitivity requirements for non-HT PPDUs")
|
Make it clear that the energy detect rules (not the CCA-ED rules, which are something different) from 18 and 19 apply even if you can't work out what type of PPDU/energy you're dealing
with (these are "detect a medium busy condition within 4 us of any signal with areceived energy that is 20 dB above the minimum modulation and coding rate sensitivity" for 2.4 GHz and -- hm, 19.4.6 has no energy detect requirement, that's in 19.3.4 ... but
there's no just energy detect requirement there too. Does this mean HT has no just energy detect requirements (again, not talking of CCA-ED here) in the 5 GHz band?
|
GEN
|
Carrier Sense
|
|
Mark Rison
|
7795
|
1308.44
|
10.6
|
"A STA shall support the concurrent reception of fragments of at least three MSDUs or MMPDUs." -- frankly, this is not good enough nowadays, even for non-AP STAs (consider QoS, for example)
|
Add "A STA should support the concurrent reception of fragments of at least one MSDU per access category. An AP should support the concurrent reception of at least on MSDU per access
category per associated STA."
|
MAC
|
MAC Operation
|
|
Mark Rison
|
7796
|
|
|
The distinctions made in the specification w.r.t. TS/TC/TSID/TID are incomprehensible
|
Make the definitions comprehensible. E.g. what does "UP for either TC or TS" mean?
|
MAC
|
Terminology
|
|
Mark Rison
|
7798
|
|
|
The material for VHT bandwidth operation etc. needs to be merged in with that for other PHYs
|
As it says in the comment (see also yellow stuff in 14/1104 for CID 3479)
|
GEN
|
Other PHY
|
|
Mark Rison
|
7804
|
|
|
"FST" is an action (fast session transfer), so what's an "FST session"?
|
Change all instances of "FST session" to "FST-capable association"
|
EDITOR
|
Terminology
|
|
Mark Rison
|
7812
|
730.62
|
9.4.2.3
|
Why is a Basic Rate anything (rounded), but a non-Basic Rate has to be from the selection list (table 6.5.52)? (9.4.2.3 Supported Rates and BSS Membership Selectors element, third paragraph)
|
Change "Rates not contained in the BSSBasicRateSet parameter are" to "Each Supported Rate in the OperationalRateSet parameter is". Replace the text referencing in table in 6.5.5.2 with
text similar to that above for the BSSBasicRateSet parameter values ("set to the data rate, if necessary rounded..."). Make matching changes in 9.4.2.13.
|
MAC
|
Frame Formats
|
|
Mark Rison
|
7815
|
3293.42
|
C.3
|
Why would APCivicLocationTable (and LCI version) be a table of locations (each of which is a sequence of information)?
|
Change the APCivicLocationTable (and LCI version), to be a single sequence (not a table of sequences).
|
GEN
|
MIB
|
|
Mathew Fischer
|
7193
|
3618.2
|
R.7
|
"MPDU_pPPDU" is not defined
|
Change to "MPDU_pA_MPDU"?
|
GEN
|
Annex R
|
|
Mathew Fischer
|
7197
|
3617.4
|
R.7
|
"AMSDUB" is not defined
|
Change to "A_MSDU_B"
|
GEN
|
Annex R
|
|
Mathew Fischer
|
7198
|
3617.6
|
R.7
|
What do the vertical bars indicate? Absolute value? None of the quantities can be negative
|
Delete the vertical bars
|
GEN
|
Annex R
|
|
Matthew Fischer
|
7093
|
1053.52
|
9.4.2.158.2
|
The insertion here makes a special case out of the Extended NSS BW Support field and Supported Channel Width Set fields. All the other fields are fully defined the table 9-245.
|
Move this text into Table 9-245 against definition of one or more of these fields.
|
MAC
|
Frame Formats
|
|
Matthew Fischer
|
7114
|
3618.45
|
R.7
|
The units of RSSI and P_adjust are not specified.Note, a separate comment has been submitted on the editorial style of these equations.
|
Specify them.
|
MAC
|
MAC Operation
|
|
Matthew Fischer
|
7187
|
716.05
|
9.4.1.53
|
Does the Extended NSS BW Support stuff apply to HT PPDUs too?
|
Add a table NOTE to say it only applies to VHT PPDUs
|
MAC
|
Frame Formats
|
|
Matthew Fischer
|
7190
|
3617.47
|
R.7
|
It says "is in units of s/s"
|
Change to "is unitless"
|
MAC
|
Annex R
|
|
Matthew Fischer
|
7192
|
3617.6
|
R.7
|
"MPDU_pA_MPDU" is clearly nothing to do with the number of MPDUs per A-MPDU (look at the units!), though it's not clear what it is
|
Change to "mysterious_quantity" (3 instances, all on this page)
|
MAC
|
Annex R
|
|
Matthew Fischer
|
7195
|
3617.51
|
R.7
|
"min(BA_WIN_Size, max(1,MPDU_pA_MPDU))" is unitally inconsistent (dimensionless, dimensionless, "s/b")
|
I really have no idea what's going on here
|
MAC
|
Annex R
|
|
Matthew Fischer
|
7199
|
3618.1
|
R.7
|
I have no idea what this example means. The size of the MAC header is variable
|
Delete ", e.g. 50"
|
MAC
|
Annex R
|
|
Matthew Fischer
|
7222
|
1453.04
|
10.32.3
|
What does "An HT beamformer may use the following worst-case parameters to estimate the duration of the expected frame that contains the feedback response: Basic HT-MCS, HT-Mixed Format,
Supported Grouping." mean? Also the cases are wrong
|
Change to "An HT beamformer may use the following worst-case parameters to estimate the duration of the expected frame that contains the feedback response: lowest rate in basic HT-MCS
set, HT-mixed format, no grouping."
|
MAC
|
MAC Operation
|
|
Matthew Fischer
|
7223
|
1453.04
|
10.32.3
|
"An HT beamformer may use the following worst-case parameters to estimate the duration of the expected frame that contains the feedback response: Basic HT-MCS, HT-Mixed Format, Supported
Grouping." -- what about a VHT beamformer
|
Add an equivalent statement to the VHT BF subclause (10.34.5)
|
MAC
|
MAC Operation
|
|
Matthew Fischer
|
7665
|
1056.37
|
9.4.2.158.3
|
"the Extended NSS BW Support bits" -- what bits? Of what?
|
Change to "the Extended NSS BW Supportsubfield in the ". Also change "bits" to "subfield" at 1053.42, 717.23 and 1056.39, and for the last two also add the missing "Support" before that
|
MAC
|
Frame Formats
|
|
Matthew Fischer
|
7671
|
1050.29
|
9.4.2.158
|
How does the new extended NSS BW support stuff interact with STBC? ? E.g. what happens if Max VHT NSS for some MCSes ends up being less than implied by Rx STBC?
|
Add "subject to any extended NSS BW support constraint" to the rightmost cell
|
MAC
|
Frame Formats
|
|
Matthew Fischer
|
7679
|
1049.47
|
9.4.2.158.2
|
"Together with the ExtendedNSS BW Support subfield andSupported VHT-MCS and NSSSet field," -- not if it's a TVHT STA
|
Add "(for non-TVHT STAs)"
|
MAC
|
Frame Formats
|
|
Matthew Fischer
|
7680
|
1049.5
|
9.4.2.158.2
|
It says " indicates the channelwidths"
|
Change to " indicates the channelwidths and maximum NSSvalues per width"
|
MAC
|
Frame Formats
|
|
Matthew Fischer
|
7682
|
716.37
|
9.4.1.53
|
If Max VHT NSS is 5, is this combination allowed? If so, does it mean 8?
|
Add a "NOTE 5---Twice Max NSS is equal to equal to double Max VHT NSS, limited to 8." at the end of the table
|
MAC
|
Frame Formats
|
|
Matthew Fischer
|
7683
|
1053.24
|
9.4.2.158.2
|
If Max VHT NSS is 5, is this combination allowed? If so, does it mean 8?
|
Add a "NOTE 5---Twice Max NSS is equal to equal to double Max VHT NSS, limited to 8." at the end of the table
|
MAC
|
Frame Formats
|
|
Matthew Fischer
|
7684
|
1332.17
|
10.7.12.2
|
If Max VHT NSS is 5, is this combination allowed? If so, does it mean 8?
|
Add a "NOTE 5---Twice Max NSS is equal to equal to double Max VHT NSS, limited to 8." at the end of the table
|
MAC
|
MAC Operation
|
|
Matthew Fischer
|
7762
|
1449.3
|
10.32.3
|
"The procedures in this subclause apply only to HT and non-HT PPDUs for which the HT Control field, ifpresent, is the HT variant HT Control field." -- is this sufficiently clear that
the subclause is only for non-VHT STAs? VHT STAs can sent HT variant HTCs, after all
|
As it says in the comment
|
MAC
|
MAC Operation
|
|
Matthew Fischer
|
7763
|
1453.44
|
10.33.1
|
"The procedures in this subclause apply only to HT and non-HT PPDUs for which the HT Control field, ifpresent, is the HT variant HT Control field." -- is this sufficiently clear that
the subclause is only for non-VHT STAs? VHT STAs can sent HT variant HTCs, after all
|
As it says in the comment
|
MAC
|
MAC Operation
|
|
Michael Fischer
|
7157
|
3585.27
|
N.3
|
The list of primary functions of an ACM_STA is incomplete. This entity also performs power save buffering, traffic indication, and delivery. Indeed, the principal difference between a
STA and an ACM_STA appears to be the existence of this power save functionality.
|
Add an item "c" to the list of primary functions which states something to the effect "Perform power save buffering, traffic indication, and delivery for mobile units." Figure N-6 should
probably be updated to show the power save support.
|
MAC
|
Architecture
|
|
Michael Fischer
|
7158
|
543.07
|
7.1
|
The DS concept in 802.11 actually provides two, rather distinct, services. One service moves data among the various BSSes of an ESS as well as mesh gates and a portal. The other service
is for management of station mobility within the ESS. The DS SAP defined in this clause is a mixture of these two, with the DS-UNITDATA primitives constituting the DS data service and the DS-STA-NOTIFY primitive constituting (part of?) the mobility service.
The mixing of these two concepts makes it unnecessarily difficult to develop a coherent model of how 802.11 functions as a MAC/PHY within and 802.1 bridged LAN.
|
Add a statement that the DS includes both a data service (illustrated in figure 7-1) and a mobility service, and clarify that DS-UNITDATA is the interface to the data service whereas
DS-STA-NOTIFY is (at least part of) the interface to the mobility service. Describing the mobility service appears to be beyond the scope of a maintenance activity, but explicitly identifying the existence of something that has actually been present throughout
the history of 802.11, and providing a way to refer to this service will remove substantial obstacles to future activities in this area.
|
MAC
|
Architecture
|
|
Payam Torab Jahroni
|
7171
|
649.18
|
9.3.4.2
|
DMG Wakeup Schedule element (Order number 16) needs a brief introduction note.
|
Add the following note for the element: "The DMG Wakeup Schedule element is optionally present. If present, the element carries the wakeup schedule of a DMG STA. See 11.2.6 (Power management
in a PBSS and DMG infrastructure BSS)."
|
MAC
|
Frame Formats
|
|
Payam Torab Jahroni
|
7173
|
2471.01
|
20.7.2.2
|
DMG LPSC mode PHY header is transmitted using Reed-Solomon coding, which makes it not decodable to Single Carrier only (SC-only) DMG devices, creating serious coexistence issues. DMG
LPSC mode has not been productized to the best of my knowledge and a it is defined to day will interfere with SC-only devices that will ship in very large quantities.
|
Transmit the LPSC PHY header using SC modulation and coding; text will be provided.
|
GEN
|
DMG PHY
|
|
Payam Torab Jahroni
|
7174
|
2474.45
|
20.7.2.3.5
|
A-PPDU aggrergation is not defined for DMG low-power SC mode (how adjacent PPDUs are transmitted is undefined)
|
Text will be provided to define A-PPDU aggregation for low-power SC mode.
|
GEN
|
DMG PHY
|
|
Payam Torab Jahroni
|
7175
|
2471.01
|
20.7.2.2
|
DMG LPSC mode PHY header is transmitted using Reed-Solomon coding, which makes it not decodable to Single Carrier only (SC-only) DMG devices, creating serious coexistence issues. DMG
LPSC mode has not been productized to the best of my knowledge and a it is defined to day will interfere with SC-only devices that will ship in very large quantities.
|
Transmit the LPSC PHY header using SC modulation and coding; text will be provided.
|
GEN
|
DMG PHY
|
|
Payam Torab Jahroni
|
7176
|
1105.24
|
9.5.4
|
Definition of the Chan-FBCK-CAP subfield can suggest that returning channel measurement information (including but not limited to SNR list) -in general- is an option or capability. Since
this is not the case (for example, during a BRP following a TXSS, the responding STA can be asked to return an SNR list for all received sectors from the preceding TXSS, and the responding STA is required to respond with the information in this case), I propose
to add a NOTE to clarify that the Chan-FBCK-CAP capability applies to returning channel measurement during beam refinemnet only.
|
Add the following NOTE after the Chan-FBCK-CAP subfield definition in line 24,NOTE--Regardless of the value of the Chan-FBCK-CAP subfield, a DMG STA is required to return the SNR values
from the last TXSS if it receives a BRP frame with the TXSS-FBCK-REQ field and the SNR Requested subfield within the FBCK-REQ field set to 1 (see 10.38.6.4 (BRP phase execution)).
|
MAC
|
Frame Formats
|
|
Peter Ecclesine
|
7102
|
1876.39
|
11.40.4
|
"NOTE 1--Other means to switch the BSS bandwidth are described in 11.42 (Notification of operating mode changes)." -- this note is incorrect. Operating mode changes are not the same as
BSS bandwidth changes.
|
Delete cited note.
|
MAC
|
MAC Operation
|
|
Peter Ecclesine
|
7123
|
1675.12
|
11.9.8.3
|
"each STA in an IBSS is required to detect radar" - it needs to be clear that 802.11 does not create these requirements
|
Change "is required" to "is required by regulation"
|
MAC
|
MAC Operation
|
|
Peter Ecclesine
|
7170
|
743.47
|
9.4.2.19
|
In some DFS bands it is important to close the channel as quickly as possible, and one means is to indicate well ahead of time the future preferred channel, so STAs know which channel
the Master intends to migrate the BSS. The Channel Switch Mode field should also have a value to indicate a future preferred channel switch target channel so if the AP or DFS owner ceases transmission on this channel, the other STAs know where to scan next
for the beaconing STA.
|
See 802.11-15/828r8 proposed resolutions of SB0 CIDs 5969, 5970 and 5972 for the proposed text changes.
|
MAC
|
Frame Formats
|
|
Peter Ecclesine
|
7676
|
716.05
|
9.4.1.53
|
Because of 4.3.13, this table applies to TVHT STAs too unless stated otherwise
|
Add "non-TVHT" after "VHT"
|
MAC
|
Frame Formats
|
|
Sean Coffey
|
7139
|
1340.25
|
10.13.6
|
This NOTE in clause 10.13.6 cites a restriction based on rules in 10.13.1 regarding prohibition of inclusion of MPDUs of more than one TID. However, it does not appear that 10.13.1 (and,
in particular, the sub-tables of table 9-420) impose this stated restriction. The actual scope of what TIDs can be included in an A-MPDU does have implications that can affect MAC implementations.
|
Harmonize the statements in 10.13.6, 10.13.1, and the tables 9-420 through 9-425 regarding the permissible contents of an A-MPDU. If the NOTE is correct, clarification is probably needed
in 10.13.1 and/or the tables. If the NOTE is incorrect, it should be removed.
|
MAC
|
MAC Operation
|
|
Sigurd Schelstraete
|
7166
|
1050.49
|
9.4.2.158.2
|
The meaning of the "Beamformee STS Capability" field was changed during the comment resolution of 11mc/D4.0 sponsor ballot based on comment CID 5879, regarding decoupling MU Beamformee
Sounding capability from MU PPDU reception capability. During the discussions in the 11mc group, concerns have bee raised about the AP side processing issue for the beamforming matrix for the data with more streams (say 8 streams) than the training streams
done with the STA (say 4 streams), when using NDP frame with less number streams than MU PPDU.In addition, the original description is technically correct, nothing needs to be fixed. That is, the changes proposed by CID 5879 resolution do not belong to technical
corrections, as for 11mc project.
|
Change the definition box for " "Beamformee STS Capability" field back to 11mc/D4.0, i.e., to the following:The maximum number of space-time streams that the STA can receive in a VHT
NDP, themaximum value for NSTS,total that can be sent to the STA in a VHT MU PPDU if the STA isMU beamformee capable, and the maximum value of Nr that the STA transmits in a VHTCompressed Beamforming frame.
|
MAC
|
CID 5879
|
|
Sigurd Schelstraete
|
7167
|
1054.01
|
9.4.2.158.3
|
The 3-bit field (Bit 29 to Bit 31) was changed from Reserved to "Maximum NSTS,total" during the comment resolution of 11mc/D4.0 sponsor ballot based on comment CID 5879, regarding decoupling
MU Beamformee Sounding capability from MU PPDU reception capability. During the discussions in the 11mc group, concerns have bee raised about the AP side processing issue for the beamforming matrix for the data with more streams (say 8 streams) than the training
streams done with the STA (say 4 streams), when using NDP frame with less number streams than MU PPDU.In addition, the original description is technically correct, nothing needs to be fixed. That is, the changes proposed by CID 5879 resolution do not belong
to technical corrections, as for 11mc project.
|
Make the following chnages:1. line 1 on page 1054, Change Bit 29 to Bit 31 back to Reserved in Figure 9-559--Supported VHT-MCS and NSS Set field2. line 33 on page 1055, delete the row
"Maximum NSTS,total" in Table 9-247--Supported VHT-MCS and NSS Set subfields
|
MAC
|
CID 5879
|
|
Sigurd Schelstraete
|
7168
|
1462.09
|
10.34.5.2
|
The paragraph in line 9 to 13 on page 1462 was changed during the comment resolution of 11mc/D4.0 sponsor ballot based on comment CID 5879, regarding decoupling MU Beamformee Sounding
capability from MU PPDU reception capability. During the discussions in the 11mc group, concerns have bee raised about the AP side processing issue for the beamforming matrix for the data with more streams (say 8 streams) than the training streams done with
the STA (say 4 streams), when using NDP frame with less number streams than MU PPDU.In addition, the original description is technically correct, nothing needs to be fixed. That is, the changes proposed by CID 5879 resolution do not belong to technical corrections,
as for 11mc project.
|
Change the parapgraph in line 9 to 13 on page 1462 back to 11mc/D4.0 version, i.e., to the following:A VHT beamformee shall indicate the maximum number of space-time streams it can receive
in a VHT NDP in the Beamformee STS Capability field. If the beamformee is a non-AP STA, this shall also be the maximum total number of space-time streams that the STA can receive in a VHT MU PPDU.
|
MAC
|
CID 5879
|
|
Sigurd Schelstraete
|
7169
|
2574.47
|
21.3.11.3
|
The paragraph in line 47 to 50 on page 2574 was changed during the comment resolution of 11mc/D4.0 sponsor ballot based on comment CID 5879, regarding decoupling MU Beamformee Sounding
capability from MU PPDU reception capability. During the discussions in the 11mc group, concerns have bee raised about the AP side processing issue for the beamforming matrix for the data with more streams (say 8 streams) than the training streams done with
the STA (say 4 streams), when using NDP frame with less number streams than MU PPDU.In addition, the original description is technically correct, nothing needs to be fixed. That is, the changes proposed by CID 5879 resolution do not belong to technical corrections,
as for 11mc project.
|
Change the parapgraph in line 47 to 50 on page 2574 back to 11mc/D4.0 version, i.e., to the following:An MU-capable STA shall support reception of VHT MU PPDUs with the total number of
space-time streams across the N_user users being less than or equal to its Beamformee STS Capability in the VHT Capabilities Info field.
|
MAC
|
CID 5879
|
|
Sigurd Schelstraete
|
7405
|
2506.13
|
21.2.5.3
|
You need to use 20U if the prim is above the sec
|
Change < to >
|
GEN
|
VHT PHY
|
|
Sigurd Schelstraete
|
7577
|
1051.08
|
9.4.2.158.2
|
It says "Set to 1 if supported and SU BeamformeeCapable is set to 1."
|
Change to "Set to 1 if supported, SU BeamformeeCapable is set to 1 and not sent by an AP."
|
MAC
|
Frame Formats
|
|
Sigurd Schelstraete
|
7584
|
2588.45
|
21.3.18.5.1
|
"The thresholds in this subclause are compared with the signal level at each receiving antenna." -- why is this not stated for the HT PHY
|
Add a similar statement to the HT PHY
|
GEN
|
VHT PHY
|
|
Sigurd Schelstraete
|
7672
|
715.42
|
9.4.1.53
|
"If the Rx NSS Type subfield is 1, the value of this field, combined with other information described in 9.4.2.158.3 (Supported VHT-MCS and NSS Set field), indicates the maximum number
of spatial streams that the STA can receive as a beamformee in an SU PPDU" -- I see nothing in there that deals with BF
|
Delete ", combined with other information described in 9.4.2.158.3 (Supported VHT-MCS and NSS Set field), "
|
MAC
|
Frame Formats
|
|
Sigurd Schelstraete
|
7687
|
1053.3
|
9.4.2.158
|
"The value of Max VHT NSS is equal to the smaller of:" -- but this value is MCS-dependent
|
Change to "The value of Max VHT NSS for a given MCS is equal to the smaller of:"
|
MAC
|
Frame Formats
|
|
Sigurd Schelstraete
|
7805
|
1168.61
|
9.6.12.1
|
The CSI, Noncompressed Beamforming, Compressed Beamforming and ASEL Indices Feedback frames are an Action or an Action No Ack frame of category HT.And, the Time Priorities of those frames
(Table 9-328) are Yes.Since TGah received a comment asking a clarification of a time priority field of some TGah action frame, TG discussed it.And TG concluded that only Action No Ack frame is eligible for the Time Priority frame.So, TGah has agreed to add
the following condition."Time Priority""Yes when transmitted as an Action no Ack frame"But, if this resolution is correct, the same modification is needed for Table 9-328.
|
In Table 9-328,Add the following condition for the CSI, Noncompressed Beamforming, Compressed Beamforming and ASEL Indices Feedback frames- Yes when transmitted as an Action no Ack frame
|
MAC
|
Frame Formats
|
|
Solomon Trainin
|
7148
|
1608.31
|
11.2.6.2.1
|
Figure 11-9--State transition diagram of non-AP and non-PCP STA in active and PS modes is not compliant with definition provided in sub-clauses 11.2.6.2.2 Non-AP and non-PCP STA operation
without a wakeup schedule and 11.2.6.2.3 Non-AP and non-PCP STA operation with a wakeup schedule
|
Replace the figure with drawing provided in 11-16-0158-00-000m-Power-Management-State-Transition-Diagram
|
MAC
|
MAC Management
|
|
Solomon Trainin
|
7149
|
1612.3
|
11.2.6.3.3
|
Figure 11-10--State transition diagram of PCP power management mode does not fit to definitions provided in 11.2.6.3.3 PCP operation with a wakeup schedule and does not reflect definition
in 11.2.6.3.2 PCP operation without a wakeup schedule
|
Replace the figure with figure provided in 11-16-0158-00-000m-Power-Management-State-Transition-Diagram
|
MAC
|
MAC Management
|
|
Solomon Trainin
|
7152
|
2075.11
|
13.5.2
|
Authentication frame is not supported in DMG. This frame is broadly used in FT protocol and FT resource request protocol. As result current version of FT is not applicable for DMG. Additional
relevant places are. in 13.5.4 Over-the-air FT protocol authentication in a non-RSN P2078 L58, 13.6.2 Over-the-air fast BSS transition with resource request P2080 L36, P2082L34
|
Use another frame - FT Request frame that is applicable for DMG to deliver FT information in the over-the-air FT protocol and in the Over-the-air FT resource request protocol
|
GEN
|
Security
|
|
Solomon Trainin
|
7153
|
1010.44
|
9.4.2.128.1
|
Negotiation of Max Number Of MSDUs In AMSDU as part of STA capabilities makes a lot of sense to DMG STA. In the current definition the Max Number Of MSDUs In AMSDU capability is not applicable
for DMG STA's
|
Extend DMG Capabilities element to convey DMG Max Number Of MSDUs In AMSDU capability subfield with four values encoded 32, 16, 8, and 4
|
MAC
|
Frame Formats
|
|
Solomon Trainin
|
7165
|
1576.33
|
11.2.2.5.1
|
U-APSD mechanism provides fine granularity of power management for non-AP STA that is not provided by any power management mechanism in DMG network.
|
Provide changes to the U-APSD definitions that makes it applicable for DMG networks
|
MAC
|
MAC Management
|
|
Solomon Trainin
|
7749
|
|
|
According to Solomon TRAININ, "no-ack frames cannot be sent under BA agreement". Presumably this is a DMG restriction as it is not a general restriction. Where is this in the spec, though?
|
Add a statement to that effect (not clear whether this means Action No Ack frames or ack policy No Ack (or Block Ack?))
|
MAC
|
MAC Operation
|