|
Assigned
|
B
|
Bugfix
|
Adrian Stephens
|
6258
|
It says "compliant with the OFDM PHY"
|
Change to "compliant with the ERP"
|
GEN
|
PHY
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Adrian Stephens
|
6259
|
It says "For an OFDM PHY"
|
Change to "For an ERP"
|
GEN
|
PHY
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Adrian Stephens
|
6260
|
It says "compliant with the OFDM PHY"
|
Change to "compliant with the HT PHY"
|
GEN
|
PHY
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Adrian Stephens
|
6261
|
It says "For a conforming OFDM PHY"
|
Change to "For an HT PHY"
|
GEN
|
PHY
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Adrian Stephens
|
6262
|
It says "compliant with the OFDM PHY"
|
Change to "compliant with the HT PHY"
|
GEN
|
PHY
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Adrian Stephens
|
6263
|
It says "For a conforming OFDM PHY"
|
Change to "For an HT PHY"
|
GEN
|
PHY
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Adrian Stephens
|
6264
|
It says "compliant with the OFDM PHY"
|
Change to "compliant with the VHT PHY"
|
GEN
|
VHT PHY
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Adrian Stephens
|
6266
|
It says "compliant with the OFDM PHY"
|
Change to "compliant with the VHT PHY"
|
GEN
|
VHT PHY
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Adrian Stephens
|
6451
|
The Duration/ID rules for TXOPs apply to all STAs, not just HT STAs
|
Delete "and TXOP" in HTM8 and create a "Duration/ID rules for TXOP" in the QoS section which is CF:M
|
GEN
|
PICS
|
|
|
Assigned
|
B
|
Bugfix
|
Adrian Stephens
|
6710
|
"In an A-MSDU, the Mesh Control field is located in the A-MSDU Subframe Header (see Figure 8-55 (A-MSDU subframe structure for Mesh Data)). In an MMPDU, the Mesh Control field is located
within the MMPDU (see 8.6.18 (Multihop Action frame details)). Such Mesh Control fields need to be taken into account if a maximum A-MSDU or MMPDU size constraint applies" -- why does the MCf needs to be taken into account if a maximum A-MSDU size constraint
applies, since it's not within the A-MSDU?
|
Delete "A-MSDU or" in the cited text
|
MAC
|
Motion MAC-BA Pulled
|
Discuss
|
|
Assigned
|
B
|
Bugfix
|
Adrian Stephens
|
6813
|
Should not use "Data" after "Null"/"QoS Null".
|
As it says in the comment
|
MAC
|
Editorials
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Adrian Stephens
|
6826
|
"The Request element field is described in 8.4.2.10 (Request element)." in 8.6.20.5 Information Response frame format does not seem correct. Was some description of the Request information
information (sic) intended?
|
As it says in the comment
|
MAC
|
Motion MAC-BA Pulled
|
Discuss
|
|
Assigned
|
B
|
Bugfix
|
Carlos Cordeiro
|
6430
|
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
|
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
|
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Donald Eastlake III
|
6076
|
With the introduction of EPD support (in some situations), 802.11 now can support a variety of LLC sublayer protocols/entities, not just LLC. Saying that the 802.11 MAC's purpose is to
deliver MSDUs between two LLC entities is too limiting. The term "LLC sublayer entities" is more generic (and aligns with 802-2014).
|
Change "LLC entities" to "LLC sublayer entities", "LLC entity" to "LLC sublayer entity" and "LLC PDUs" to "LLC sublayer PDUs" and "LLC" (as a noun) with "LLC sublayer", throughout 5.1
(6 occurances in total). NOTE: Figures 5-1 and 5-2 should have a similar change, and are covered by another comment.
|
MAC
|
MAC Service
|
|
|
Assigned
|
B
|
Bugfix
|
Donald Eastlake III
|
6078
|
This subclause is not really unique to APs. The same rules apply to non-AP STAs (and non-infrastructure scenarios), too, per the last paragraph of 5.1.1.4.
|
Replace the last paragraph of 5.1.1.4 with the text contents of 5.1.1.3 (deleting the 5.1.1.3 header), and changing "at the AP" to "at a STA", and "the AP" with "the STA". NOTE: the last
paragraph/sentence of 5.1.1.3 should be moved also, to stay with the rest of the moved text.
|
MAC
|
MAC Service
|
|
|
Assigned
|
B
|
Bugfix
|
Donald Eastlake III
|
6080
|
How can an MSDU
|
|
MAC
|
MAC Service
|
|
|
Assigned
|
B
|
Bugfix
|
Donald Eastlake III
|
6083
|
"The integer values of the priority parameter (i.e., TID) are supported only at QoS STAs that are either associated in an infrastructure QoS BSS or members of a QoS IBSS." So, these can't
be used in MBSS or PBSS?
|
Change "associated in an infrastructure QoS BSS" to "associated in a QoS BSS"
|
MAC
|
MAC Service
|
|
|
Assigned
|
B
|
Bugfix
|
Donald Eastlake III
|
6085
|
I'm not sure the information CCMP, GCMP and BIP need is from "nonlayer-2 management or system entities". It definitely from non-MAC sublayer entities, but remember the SME and 802.1X
are both still layer-2, for example.
|
Change "nonlayer-2" to "non MAC sublayer"
|
MAC
|
MAC Service
|
|
|
Assigned
|
B
|
Bugfix
|
Donald Eastlake III
|
6086
|
The first sentence of this paragraph is true, but irrelevant here and already stated in 5.1.1.5. The purpose of the sentence seems to be to introduce the service class concept, to cover
bullet (c) below. But, bullet (c) is just incorrect, because all group addressed frames are delivered NoAck regardless of the service class specified (as described in 5.1.1.5).
|
Delete the first sentence of the paragraph ("In QoA STAs operating in a BSS, there are two service classes, ..."). Delete bullet (c) in the list at the end of this paragraph.
|
MAC
|
MAC Service
|
|
|
Assigned
|
B
|
Bugfix
|
Donald Eastlake III
|
6087
|
What does this sentence mean (in this context), "In order for the MAC to operate properly, the DS needs to meet the requirements of ISO/IEC 15802-1:1995."? Presumably, this is a reference
to MSDU reordering rules in 15802-1, since the sentence is in this subclause. Note that 15802-1 has weak restrictions on reordering of MSDUs, saying "In general, the MAC Service provider may perform any or all of the following actions: ... change the order
of the [MSDUs]." but also saying a MAC Service provider exhibits "a negligible rate of ... reordering of [MSDUs] for a given priority".
So, first, 15802-1:1995 is an odd, and old reference. How about referencing 802.1AC-2012 instead (which has identical language to that quoted above, by the way)?
Secondly, this sentence needs to be clarified that this reordering "requirement" (weak as it is) is what is being refernced here. Surely, the DS does NOT (and cannot) meet all the requirements of 15802-1 (or 802.1AC), since it isn't a MAC Service.
|
Replace this sentene with, "In order for the MAC to operate properly, the DS needs to meet the MSDU ("object") reordering requirements of IEEE Std 802.1AC-2012."
|
MAC
|
MAC Service
|
|
|
Assigned
|
B
|
Bugfix
|
Dorothy Stanley
|
6069
|
With respect to dot11EDCATableTXOPLimit, it doesn't make sense to have a MIB attribute that is a "control variable" but written by the MAC.
|
If it is at all useful to expose this value externally, make it a status variable. Otherwise, consider removing the MIB attribute completely, as it is only used for the MAC to indicate
the value to itself - and that is just a local variable, and not in the MIB.
|
GEN
|
MIB
|
|
|
Assigned
|
B
|
Bugfix
|
Dorothy Stanley
|
6205
|
dot11PNWarningThreshold and dot11PNExhaustionThreshold (p. 3185) are 32-bit but the PN is 48-bit and there is no reason to stop using a PTKSA after 32 bits have been used up.
|
Change their SYNTAX to "Integer64 (1..281474976710655)"
|
GEN
|
MIB
|
|
|
Assigned
|
B
|
Bugfix
|
Dorothy Stanley
|
6752
|
Why are there two "dot11CurrentChannelWidth"s et al.?
|
Delete one of them
|
GEN
|
MIB
|
|
|
Assigned
|
B
|
Bugfix
|
Emily Qi
|
6203
|
It says "To terminate the use of FMS for an FMS Stream identified by FMSID, the non-AP STA shall transmit an FMS Request frame with an FMS Request element and FMS subelement with the
FMSID matching the FMS stream and the delivery interval set to 0.", but there is no FMSID in an FMS Request element, nor an FMS subelement. An FMS Request element contains an FMS Token for a stream set, but not the FMSID allocated by the AP to a stream
|
Resolution: add an FSMID to the FMS subelement in Figure 8-407---FMS subelement format
|
MAC
|
Power Saving
|
|
|
Assigned
|
B
|
Bugfix
|
Graham Smith
|
5011
|
As it stands an 11b device using only CS-CCA is not compliant with EN 300 328 V1.8.1 which specifies ED-CCA at -58dBm minimum. Clause 19 and 20 devices must use both CS-CCA and ED-CCA.
It is proposed that all devices at 2.4GHz be made similar with respect to CCA and hence also cause 11b devices to be compliant with EN 300 328. This proposal would not affect present 11b devices but would affect new 11b implementations.
|
Submission will be made with proposed text
|
GEN
|
Gen Assigned Graham Smith
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Graham Smith
|
5012
|
As it stands an 11b device using only CS-CCA is not compliant with EN 300 328 V1.8.1 which specifies ED-CCA at -58dBm minimum. Clause 19 and 20 devices must use both CS-CCA and ED-CCA.
It is proposed that all devices at 2.4GHz be made similar with respect to CCA and hence also cause 11b devices to be compliant with EN 300 328. This proposal would not affect present 11b devices but would affect new 11b implementations.
|
Submission will be made with proposed text
|
GEN
|
Gen Assigned Graham Smith
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Graham Smith
|
5078
|
"BRP packets transmitted during beam refinement should use MCS 1 and shall not use any MCS greater than
MCS 12. BRP packets transmitted during beam refinement should use MCS 0 if the BRP packet is sent at
start of an SP as defined in 9.36.6.2 (Service period (SP) allocation)." -- this creates conflicting recommendations
|
Reword thus: "A BRP packet transmitted during beam refinement at the start of a SP (as defined in 9.36.6.2 (Service period (SP) allocation)) should use MCS 0 , otherwise a BRP packet
transmitted during beam refinement should use MCS 1. A BRP packet transmitted during beam refinement shall not use any MCS greater than MCS 12. "
|
MAC
|
MAC operation
|
|
|
Assigned
|
B
|
Bugfix
|
Graham Smith
|
5124
|
"For MSDUs or A-MSDUs belonging to the service class of QoSNoAck when the receiver is a QoS STA"
Either there is a third condition to follow this one "service class of QoSNoAck and the receiver is not a QoS STA" or the
constraint "when the receiver is a QoS STA" is unnecessary.
|
Either remove "when the receiver is a QoS STA", or add the missing third condition stated in the comment.
|
MAC
|
MAC operation
|
|
|
Assigned
|
B
|
Bugfix
|
Graham Smith
|
5144
|
"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, and contains lots of "may transmit" statements.
|
In 9.22.2 add constraints that a TXOP cannot be gained under EDCA during one of these tracked time conditions, and the TXOP duration is limited so the TXOP does not extend into any such
period.
|
MAC
|
MAC operation
|
|
|
Assigned
|
B
|
Bugfix
|
Graham Smith
|
5147
|
"Separate the Block and Basic BlockAckReq frames" - there is no such thing as a "Block" or "Block frame"
Likewise at 1361.59.
|
Possibly: replace "Block" by "Data". Likewise at 1361.59, replace "Block frame" with "series of Data frames related to a single block ack agreement"
But the third list item appears to duplicate the new 2nd one, so I don't know if I'm missing something.
|
MAC
|
MAC operation
|
|
|
Assigned
|
B
|
Bugfix
|
Graham Smith
|
5163
|
"is not able to forward the frame" -- forwarding is at the level of MSDU or MMPDU, not frame.
|
change "frame" to "MSDU".
Make the same change at 1448.14
|
MAC
|
Motion MAC-BA Pulled
|
Discuss
|
|
Assigned
|
B
|
Bugfix
|
Graham Smith
|
5226
|
Isn't dot11RSNABIPMICErrors the same with dot11RSNAStatsCMACICVErrors? The reason of thinking like that is because, in 11.4.4.6 BIP reception d), it is said that "... If the result does
not match the received MIC
value, then the receiver shall discard the frame and increment the *dot11RSNAStatsCMACICVErrors*
counter by 1, and terminate BIP processing for this reception." and BIP uses CMAC integrity check. The parameter, dot11RSNAStatsCMACICVErrors, is the counter that is used when there is an error in BIP CMAC integrity check and dot11RSNABIPMICErrors seems to
be unnecessary.
|
Delete dot11RSNABIPMICErrors.
|
GEN
|
Gen Assigned Graham Smith
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Mark Hamilton
|
5035
|
"The Destination REDS AID field is set to the AID of the target destination REDS" -- no size is given for this field.
|
Define the structure & size of this field.
|
MAC
|
Action Frames
|
Discuss
|
|
Assigned
|
B
|
Bugfix
|
Mark Hamilton
|
5039
|
"The Sampling Frequency Offset field is reserved when set to 0" -- is internally self-contradictory, i.e. you need to test its value to determine whether its value should have been ignored.
|
Replace it with something meaningful, or delete the sentence.
|
MAC
|
Action Frames
|
Discuss
|
|
Assigned
|
B
|
Bugfix
|
Mark Hamilton
|
5100
|
Wrong logic in "If all ... were not received", because even if one fregement is lost, the transmission of query response fails. The correct _expression_ is "If not all ... were received"
or "If at least one ... were not received". Either way is fine.
|
Change "If all ... were not received" to "If not all ... were received".
|
MAC
|
Interworking
|
Review
|
|
Assigned
|
B
|
Bugfix
|
Mark Hamilton
|
5421
|
"the STA shall wait for an AckTimeout interval, with a value of aSIFSTime + aSlotTime + aRXPHYStartDelay, starting at": exactly what (field, parameter?) has this value? Is this the length
of time in the AckTimeout interval? If so, that needs to be stated clearly. In addition, what is starting at the primitve? Actually, nothing starts at a primitive, since a primitive is just an internal function that can be invoked.
|
Replace "AckTimeout interval, with a value of aSIFSTime + aSlotTime + aRXPHYStartDelay, starting at the PHY-TXEND.confirm primitive." with "AckTimeout interval (whose value is aSIFSTime
+ aSlotTime + aRXPHYStartDelay). This interval begins when the STA's MAC receives a TXEND.confirm primitive from its PHY."
|
MAC
|
DCF & HCF
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Mark Hamilton
|
5571
|
"All measurement requests and reports are enabled by default.": this statement is inside a normative paragraph. Shouldn't this statement also be normative?
|
Replace "are enabled" with "shall be enabled".
|
MAC
|
DFS
|
Review
|
|
Assigned
|
B
|
Bugfix
|
Mark Hamilton
|
5957
|
There is no item "e)"
|
Change "reason c), d) or e)" to "reason c) or d)"
|
MAC
|
HCF
|
Review
|
|
Assigned
|
B
|
Bugfix
|
Mark Hamilton
|
6273
|
"Deauthentication notification sets the STA's state to State 1.", "If STA A in an infrastructure BSS receives a Class 2 or Class 3 frame from STA B that is not authenticated with STA
A (i.e., the state for STA B is State 1), STA A shall discard the frame. If the frame has an individual address in the Address 1 field, the MLME of STA A shall send a Deauthentication frame to STA B.", "The state for the indicated STA shall be set to State
1.", "If no valid SA Query response is received, the non-AP STA may delete the SA and move into State 1 with the AP.", "If the target AP is distinct from the previous AP, the FTO shall enter State 1 with respect to the previous AP.", "If the target AP is distinct
from the previous AP, then the FTO shall enter State 1 with respect to the previous AP." -- these statements do not apply to DMG STAs which do not perform 802.11 authentication
|
Update the statements to take account of DMG STAs which do not use State 1
|
MAC
|
MAC state machine
|
|
|
Assigned
|
B
|
Bugfix
|
Mark Hamilton
|
6342
|
The $Foo frame Action field does not include VSIEs, MICEs or AMPEEs (per 8.3.3.13)
|
Remove those fields at 1188.43, 1190.8, 1191.7
|
MAC
|
Action Frames
|
Discuss
|
|
Assigned
|
B
|
Bugfix
|
Mark Hamilton
|
6499
|
It says "An exception is that recognition of a valid Data frame sent by the recipient of a PS-Poll frame shall also be accepted as successful acknowledgment of the PS-Poll frame." but
so should a valid Management frame; similar issues at 1272.4, 1330.33, 1383.7
|
Add "or Management" after "Data" in the cited text; similarly extend the text at 1272.4, 1330.33, 1383.7
|
MAC
|
DCF & HCF
|
Review
|
|
Assigned
|
B
|
Bugfix
|
Mark Rison
|
6233
|
Table 9-5 needs to be extended for PHYs after 11n
|
Add info on VHT (and DMG?) PPDUs
|
MAC
|
MAC operation
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Mark Rison
|
6295
|
The things which are cached are the SAs, not just the Ks
|
Change "PMK cached" to "PMKSA cached" at 1926.5, "SMK cache" to "SMKSA cache" at 2903.32, "SMK caching" to "SMKSA caching" at 3287.31
|
MAC
|
Security
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Mark Rison
|
6302
|
"is being received at the antenna" -- PPDUs can't be received anywhere else
|
Delete "at the antenna" in both instances of the cited text
|
GEN
|
GEN CCA
|
Discuss
|
|
Assigned
|
B
|
Bugfix
|
Mark Rison
|
6303
|
It says "the timer of CCA Mode 2 shall be overridden by this requirement." but there is no timer in CCA Mode 2 (in fact, there is no CCA Mode 2 in HR/DSSS)
|
Change "2" to "4" in the cited text
|
GEN
|
GEN CCA
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Mark Rison
|
6656
|
Various technical issues were raised in yellow stuff in 14/1104
|
Address these technical issues
|
GEN
|
GEN Assigned to Mark RISON
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Mark Rison
|
6657
|
Various editorial issues were raised in yellow stuff in 14/1104
|
Address these editorial issues
|
GEN
|
GEN Assigned to Mark RISON
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Mark Rison
|
6684
|
Suspect uses of "will not", e.g. "The value of Nr within an explicit Beamforming feedback frame transmitted by a VHT beamformee will not exceed the value indicated in the Beamformee STS
Capability subfield of the VHT Capabilities element." and "The AP will not deliver the requested streams at the delivery interval as specified by the non-AP STA in the FMS Request element." Either make into a NOTE or reformulate with "shall" or otherwise (e.g.
latter is "does not" nearby).
|
As it says in the comment
|
EDITOR
|
Editorials - assigned
|
|
|
Assigned
|
B
|
Bugfix
|
Mark Rison
|
6733
|
Ref. to "8.4.2.21.10" in new BSSID stuff -- caption does not say "LCI report" nor "Location configuration information" nor "field" etc.
|
I will propose text once I've worked out what I was going on about
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Mark Rison/Mark Hamilton
|
6562
|
The exception for the PM bit in Probe Responses sent in response to unicast Probe Requests in an IBSS makes no sense
|
Get rid of this special case (in 3.2, 8.2.4.1.7 and 10.2.2.4)
|
MAC
|
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Matthew Fischer
|
5892
|
A statement similar to the first paragraph should be included for VHT transmisisons.
|
Add LDPC requirement for VHT.
|
MAC
|
VHT MAC
|
|
|
Assigned
|
B
|
Bugfix
|
Matthew Fischer
|
6221
|
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
|
Make the AID12 subfield reserved in that case (also, there is no AID in the STA Info field, to be pedantic)
|
MAC
|
VHT MAC
|
|
|
Assigned
|
B
|
Bugfix
|
Matthew Fischer
|
6242
|
Nothing seems to stop a VHT STA sending a VHT PPDU using LDPC to a STA which doesn't support this
|
Add a para "A VHT STA shall not transmit a frame with the TXVECTOR parameter FORMAT set to FTM and the TXVECTOR parameter FEC_CODING set to LDPC_CODING unless the RA of the frame corresponds
to a VHT STA for which the Rx LDPC subfield of the VHT Capabilities element received from that STA contained a value of 1 and dot11VHTLDPCCodingOptionActivated is true.". Change "a STA" to "an HT STA" at 1316.6
|
MAC
|
VHT MAC
|
|
|
Assigned
|
B
|
Bugfix
|
Menzo Wentink
|
5143
|
"that belongs to a TC that requires acknowledgment." -- this is misleading and highlights an underspecification.
|
Delete "that belongs to a TC".
Somewhere in this subclause add a para that indicates how it is determined that an MSDU requires acknowlegement, being a combination of any TS set up and the Service Class in the UNITDATA.request. Particularly addess the question of what to do when these conflict.
|
MAC
|
HCF
|
|
|
Assigned
|
B
|
Bugfix
|
Menzo Wentink/Jouni Malinen
|
6230
|
It says "It should not overlap with the secondary 40 MHz channel of any existing BSSs with a 160 MHz or 80+80 MHz operating channel width." Shouldn't overlap with the secondary 40 MHz
channel of an 80 MHz BSS be avoided too?
|
Add "80 MHz," before "160 MHz" in the cited sentence
|
MAC
|
MAC management
|
|
|
Assigned
|
B
|
Bugfix
|
Menzo Wentink/Jouni Malinen
|
6777
|
Status Indication and Value need to be reserved for the initiating STA
|
As it says in the comment
|
MAC
|
MAC management
|
|
|
Assigned
|
B
|
Bugfix
|
Payam Torab Jahroni
|
5990
|
There are no channel access rules defined for the variable-duration period between BRP request and response frames. With the duration longer than SIFS, it is important to keep the medium
busy while a response frame is being prepared. However, there are currently no rules to establish how the BRP initiator or the responder can keep the medium busy, resulting in collisions and interoperability problems.
|
Text will be provided.
|
MAC
|
DMG operation
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Sigurd Schelstraete
|
5940
|
The NOTE in Table 22-29 for aPSDUMaxLength is not correct. For an SU PPDU, the max APEP_LENGTH is 1 048 575, according to Table 22-1. This could never result in a PSDU_LENGTH of 4 692
480. (see (22-112) and (22-113)). For SU, the difference between APEP_LENGTH and PSDU_LENGTH is at most N_DBPS/8). For MU transmissions, PSDU_LENGTH could be longer, but it would not be possible to use 8 streams to a single user.
|
I believe the maximum PSDU_LENGTH would be 1506*12480/8 = 2 349 360, corresponding to 4 streams MCS9 in an MU PPDU with N_STS,total=5 that is 1506 symbols long.
|
GEN
|
VHT PHY
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Stephen McCann
|
6200
|
There don't seem to be any normative behavioural requirements for the Protected Frame bit for Data/Management frames
|
Add something e.g. in Clause 11 to require all Data frames sent while in an RSNA and in auth/assoc State 4, and all unicast robust Management frames, to have the bit set to 1
|
MAC
|
Frame Control field
|
|
|
Assigned
|
B
|
Bugfix
|
Stephen McCann
|
6201
|
There don't seem to be any normative behavioural requirements for the Protected Frame bit for Authentication frames
|
Add something e.g. in Clause 11 to clarify which Authentication frames have the bit equal to 1 (only frames 3 and 4 of Shared Key auth?)
|
MAC
|
Frame Control field
|
|
|
Assigned
|
B
|
Bugfix
|
Stephen McCann/Mark Hamilton
|
6331
|
"Twenty-one Exception fields are provided to give more flexibility in defining the QoS Map and it is currently the number of Fibs defined by the IETF." -- what's a Fib, if it's not a
Small Lie?
|
Define the term "Fib"
|
MAC
|
Interworking
|
Discuss
|
|
Assigned
|
B
|
Bugfix
|
Youhan Kim
|
5018
|
In Equation 22-72, there is a minor error on the range of K.
k = 0, 1, ..., N_Block*N_ES*s - 1
k = N_Block*N_ES*s, ..., N_CBPSS - 1
's' should be 'S' (capital S).
|
Replace "N_Block*N_ES*s" with "N_Block*N_ES*S" in Equation 22-72.
|
GEN
|
VHT PHY
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Youhan Kim
|
5019
|
In Equation 22-73, there is a minor error on the range of K.
k = 0, 1, ..., N_Block*N_ES*s - 1
k = N_Block*N_ES*s, ..., N_CBPSS - 1
's' should be 'S' (capital S).
|
Replace "N_Block*N_ES*s" with "N_Block*N_ES*S" in Equation 22-73.
|
GEN
|
VHT PHY
|
Submission Required
|
|
Assigned
|
B
|
Bugfix
|
Youhan Kim
|
6431
|
Why does the DSSS PHY have such a big max MPDU length? All other PHYs (including HR/DSSS) have a maximum of 4095, and furthermore it's not clear what this means in terms of the max A-MSDU
size which can be transported in a DSSS-format PPDU sent between HT STAs
|
Change 2^13 to 2^12 at 2175.14, 2176.24, 2188.19
|
GEN
|
PHY
|
|
|
Assigned
|
B
|
Bugfix
|
Youhan Kim
|
6640
|
PHY-TXBUSY is missing from Table 7-2 at 544.8 and its parameters from Table 7-3 at 544.34
|
Add the missing information
|
GEN
|
PHY
|
|
|
Assigned
|
B
|
Bugfix
|
Youhan Kim
|
6821
|
In Clause 22 have "Set to 1 if a beamforming steering matrix is applied to the waveform in an SU transmission as described in 20.3.11.11.2 (Spatial mapping)." and "Set to 1 if a Beamforming
steering matrix is applied to the waveform in an SU transmission as described in 20.3.11.11.2 (Spatial mapping)" i.e. ref to Clause 20, not Clause 22 spatial mapping. Ditto Clause 23. Also why uppercase "Beamforming"?
|
Refer to the correct subclause in 22 (and 23); fix the case of "beamforming"
|
GEN
|
PHY
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Adrian Stephens
|
6460
|
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 rate set?
|
Add a "NOTE---A STA is not required to include mandatory rates in its operational rate set."
|
MAC
|
|
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Adrian Stephens
|
6483
|
The term "supported rate set" is undefined
|
Change throughout to "operational rate set", except at 1277.47, 1383.45, 1384.1 (change to "basic rate set") and maybe 892.52, 1383.50, 1384.5 (not sure what is intended there)
|
MAC
|
|
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Dorothy Stanley
|
5055
|
The large numbers of warnings in the MIB makes it difficult for amendments to determine if they are causing any additional warnings. Such additional warnings are not allowed by the 802.11
MDR process.
|
Compile the MIB. Remove all "not in a group" and "not in a compliance statement" by adding a "bucket" group with optional support from the 802.11 compliance statement.
|
GEN
|
MIB
|
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Dorothy Stanley
|
6474
|
Slurp out all words starting with "dot11" in 802.11-2011 in all Clauses/Annexes other than Annex C. Slurp out all words following "SYNTAX" in Annex C. Compare
|
If anything is in one list but not the other, address the discrepancy (in some cases there may be good reasons for the discrepancy, and the simple recipe given in the comment will certainly
produce false alerts)
|
GEN
|
MIB
|
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Dorothy Stanley
|
6538
|
C.2 says "When an object is deprecated, add a line to the Description indicating why (IETF convention)." -- there is not always such a line
|
Add missing justifications
|
GEN
|
MIB
|
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Dorothy Stanley
|
6689
|
Cross-references in the MIB are not good because (a) they do not immediately indicate the spec revision and (b) they are not easily accessible (getIEEE might be discontinued).
|
Give the information directly, not by cross-reference
|
GEN
|
MIB
|
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Dorothy Stanley
|
6690
|
The format of the REFERENCES in the MIB is not consistent (and some are doubtless missing).
|
Make those which are there consistent, and add those which are missing
|
GEN
|
MIB
|
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Edward Au
|
5249
|
WNM-Notification is a capability, not a frame, field, element, etc., so its name does not require initial caps. In addition, similarly to "U-APSD coexistence", this name does not need
a hyphen.
|
When "WNM-Notification" is part of the name of a frame, field, element, etc. replace it with "WNM Notification" throughout the draft. Otherwise (such as line 37), replace it with "WNM
notification" throughout the draft.
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Graham Smith
|
5013
|
Clause 19 does not specify any CCA energy detect level. In addition it specifies a level of -76dBm whereas one might expect a value of -82dBm so as to be consistent with 11a, 11n, and
11ac. It is proposed to bring this clause into line with the others
|
Submission will be made with proposed text
|
GEN
|
Gen Assigned Graham Smith
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Hamilton
|
6279
|
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 parallel subclause for APs/PCPs
|
MAC
|
MAC state machine
|
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Hamilton
|
6341
|
"Vendor Specific" subelements are not needed in $Foo frame Action field formats, since the VSIEs can all be put at the end of the Action frame (per 8.3.3.13/14)
|
Remove vendor-specific subelements in subclause 8.6 (e.g. p 1114, 1127, 1183, 1184)
|
MAC
|
Action Frames
|
Discuss
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
5024
|
The standard is inconsistent about whether the Duration field is that or the "Duration/ID field". There are 166 instances of "Duration field" and 120 of "Duration/ID field".
|
Change all references to "Duration field" to "Duration/ID field" and change all "Duration" fields shown in frame format figures to be "Duration/ID".
|
MAC
|
Terminology
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6198
|
It is not always stated explicitly in various locations that conditional things are not present if the condition is not met, i.e. some "and is not present otherwise" is missing
|
Add the cited text where missing
|
EDITOR
|
General
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6214
|
There are references to "physical carrier sense", "virtual carrier sense" and "physical CS" and "virtual CS" but the terms are never defined
|
Define the terms. Arguably, virtual CS is defined at 1247.61 (though why it is "referred to as the NAV" is unclear -- or maybe virtual CS also includes considering the medium busy for
the duration indicated in a received PPDU header?), but physical CS is not well-defined. 1247.57 says each PHY provides the details, but the term is only used at 2280.45 and merely reflects back to the PHY. Something needs to tie "physical CS" with the zoo
of CS/CCA/energy detect/ED/blahblahblahPHYwibblings terminology used in each PHY
|
GEN
|
GEN CCA
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6215
|
Use "CS" rather than "carrier sense" except when defined etc.
|
Use "CS" rather than "carrier sense" at 74.14, 833.8, 1239.15, 1664.39, 1664.40, 3187.59 (2x), 860.43, 864.52, 1378.5, 1679.57, 2184.52, 2437.59
|
GEN
|
GEN CCA
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6216
|
The terms PHYCS and PHYED are defined but barely used
|
Delete them from subclause 3.4 and replace them in the other locations with their full-fat equivalents, i.e. physical CS and physical ED (4 instances each)
|
GEN
|
GEN CCA
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6237
|
The SAP primitive parameter names are inconsistent as to whether they have spaces or not
|
Be consistent (I suggest not having spaces, for contrast with frame contents)
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6305
|
There is a zoo of inconsistent terminology for "carrier sense", whch makes it hard to understand exactly what is meant where and how the various PHYs compare: CS, CCA, CS/CCA, energy
detect, ED, PHYED, CCA-ED, CCA Mode 1-5
|
First rename CCA-ED to PHYRED (regulatory ED). Then call the ED which everybody uses PHYED, and the preamble detect PHYPD. Call the combination of things which yield the PHY part of "carrier
sense" PHYCS. Kill the terms CS, CCA, CS/CCA, CCA Mode, ED. Make it clear how "I'm currently transmitting" fits into "carrier sense", and whether "I've received the PPDU header so I know how long to consider the medium busy even though the energy has gone
away" is considered part of PHYCS or part of MACCS/virtual CS
|
GEN
|
GEN CCA
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6306
|
"CCA-ED" just confuses everyone, because everyone thinks it means CCA using ED, when in fact it means some wacko mode of operation in wacky regulatory domains/bands
|
Rename CCA-ED to something more obscure, so that people can use this term for the CCA-ED which is actually used in practice
|
GEN
|
GEN CCA
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6422
|
Get rid of the BSS basic VHT set stuff in the same way the BSS basic HT set stuff was gotten rid of in CID 2010
|
As it says in the comment
|
MAC
|
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6428
|
The parameters called "BSSBasicRateSet" or "OperationalRateSet" or "SupportedRates" in the MLME SAP are not always rates, they can sometimes be BSS selectors
|
Rename the parameter to allow for this, and if there are any cases where a BSS selector is not allowed, reduce the range (from 1-127)
|
MAC
|
Layer management
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6447
|
What is a "QoS Data frame" or "QoS Data MPDU"? Does this refer to all frames of Type Data and Subtype 1000-1111, or all frames of Type Data and Subtype 1000-1011 (i.e. not QoS Null or
immediate relatives), or all frames of Type Data and Subtype 1000 (i.e. not QoS Data + CF-anything)? 568.44 is an example of the first of these, 572.33 seems to be an example of the last of these and 574.52 seems to be an example of the middle of these
|
Use "QoS data subtype" for the first, "QoS (+)Data frame" for the second and "QoS Data frame" for the last, throughout
|
MAC
|
Terminology
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6467
|
The word "frame" is used too loosely. Sometimes it refers to a MSDU or MMPDU, rather than an MPDU (which might form just part of a fragmented MSDU or MMPDU). This affects, for example,
whether the PM mode can change during a fragmented MSDU or MMPDU.
|
Make sure that "frame" is never used to refer to an MSDU or MMPDU.
|
GEN
|
GEN Assigned to Mark RISON
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6493
|
The notes for b2, Extended Channel Switching, do not have any linkage with dot11ExtendedChannelSwitchActivated. More generally, many of the bits in the Extended Capabilities are associated
with a MIB variable, but this linkage is not specified
|
Link b2 and any other bits which are linked to a MIB variable explicitly to that variable
|
MAC
|
Frame formats 8.4
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6508
|
The operating channel width is defined as the channel width in which the STA is currently able to receive. However, in some cases the term is used to refer to the maximum channel width
which may be used in the BSS
|
Make the changes indicated in 14/1104 under CID 3386, as they pertain to the term "operating channel width"
|
MAC
|
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6528
|
What is the difference between a "network" and a "BSS"?
|
Be consistent. Pick one and stick to it
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6541
|
"LCI Report", "LCI report", "Location Report", "Location Configuration Information Report", "Location Configuration report"
|
Pick one and change the others to that
|
EDITOR
|
Editorials - assigned
|
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6542
|
There is a zoo of terminology: "operating [band]width", "channel [band]width", "operating channel width", "BSS operating width" (and probably other more esoteric forms)
|
Pick one term and humanely kill all the others
|
GEN
|
GEN Assigned to Mark RISON
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6543
|
References to "Clause frames" (n = 16, 17, etc.) make no sense as frames are a MAC concept. "rates" is suspect too because a given rate may be used by more than one PHY (e.g. 11g and
11a, and probably some variants of 11a and 11n). Other forms like "Clause waveforms" or "PPDUs" or "formats" make sense but should be consistent
|
Pick one valid term and use it consistently
|
MAC
|
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6546
|
"the value $n", where "$n" is a number, can be compressed
|
Change all instances to "$n"
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6553
|
Sexless double quotes
|
Make all sexless double quotes sexy, except those in code and in the MIB
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6567
|
Should the word "format" appear in IE figure captions? E.g. "Figure 8-85--DSSS Parameter Set element format" v. "Figure 8-94--ERP element"
|
Be consistent. Look at the list of figures and fix other inconsistencies (e.g. "fixed": "Timestamp field" v. "Dialog Token fixed field"). See ad-hoc notes for CID 135 for examples
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6572
|
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
|
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6574
|
We cleaned up the PICS (especially the CF section) in the early phases of TGmc, and then amendments came in and made it all messy and inconsistent again
|
Fix all the damage done by the later amendments
|
GEN
|
GEN Assigned to Mark RISON
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6578
|
There are abbreviations for all the less common types of BSS (IBSS, MBSS, PBSS, etc.) but there is no abbreviation for the most common type of BSS, namely the one with an AP and a bunch
of non-AP STAs!
|
Introduce a new term for this. Perhaps APBSS (Access Point BSS) or ABSS (AP BSS or Asymmetric BSS)? Find where in the spec BSS has been (mis)used to mean just infrastructure BSS and change
those to the new term
|
EDITOR
|
Editorials - assigned
|
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6579
|
"frame body" or "Frame Body" or "payload" or what?
|
Be consistent
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6580
|
The "ack policy" case is all over the place (ack/ACK/Ack all used, as are policy and Policy)
|
Be consistent
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6597
|
Should a one-bit field be a Foo bit or a Foo (sub)*field?
|
Be consistent
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6601
|
Sexless single quotes
|
Make all sexless double quotes sexy, except those in code and in the MIB and those introducing a non-decimal number
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6605
|
The space between a number and its unit should be a non-breakable one
|
Make them all NBSPs
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6621
|
Sometimes element/frame figures have "(optional)", sometimes not
|
Be consistent -- either always (when the field in question is indeed optional) or never
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6624
|
When do we say "Address 1/2" and when do we say "TA/RA" (see e.g. 9.19.2.2)? There doesn't appear to be any rhyme or reason to the choice
|
Be consistent
|
MAC
|
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6655
|
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)
|
MAC
|
VHT MAC
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6659
|
Change "local policy" to "implementation-defined". Change "implementation-defined" to "outside the scope of this standard too"? Canonicalise "out of scope"/"out of the scope"/"beyond
the scope"/"outside the scope" and "scope for"/"of" etc.
|
As it says in the comment
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6693
|
"The X element/subelement/field/subfield is present in the Y frame/element/subelement/field/subfield" should be deleted. If it is not duplicated in the description of Y, then it should
be added to Y.
|
As it says in the comment
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6694
|
Be consistent on whether to say "element" for rows in tables showing Action field formats
|
As it says in the comment
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6742
|
Behavioural stuff should not be in clause 8, it should be in a later clause.
|
As it says in the comment
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6814
|
Where is the stuff which explains how stuff is taken off queues? Is it just that each queue is a pseudo-STA fed MSDUs one at a time? That would still require a statement that a new MSDU
is not fetched if a previous one is outstanding
|
Add something about how/when items are taken off queues
|
MAC
|
HCF
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Mark Rison
|
6832
|
Type is sometimes "MAC Address" and sometimes "MAC address".
|
Be consistent
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Matthew Fischer
|
5901
|
It would make sense to have a section on explicit feedback beamforming for VHT after clause 9.32.3
|
Add section "Explicit feedback beamforming for VHT" to clarify that Explicit feedback beamforming with immediate feedback is the only allowed format for VHT.
|
MAC
|
VHT MAC
|
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Menzo Wentink/Jouni Malinen
|
5111
|
Inconsistence in definition of TS use that may be seeing as limitation to use the same TS in CBAP allocations delivered by ESE and CBAP allocation delivered by beacon with CBAP only set
to 1. For example few BA agreements with specific UP's/TSID's are established and the CBAP allocation is changed from Source AID=broadcast AID to BI with CBAP only set to 1. The BA agreement shouldn't be chaged in this case, but it is not allowed in the existent
definition.
|
Each TS is carried in one allocation, except when
-- The TS has an access policy of EDCA, where it can use all CBAP allocations with Source AID equal to the broadcast AID, all CBAP allocations with Source AID matching the source STA of the TS, and all CBAP allocations with Destination AID matching the destination
STA of the TS, and in a beacon interval for which the received DMG Beacon has the CBAP Only subfield within the DMG Parameters field set to 1; or
-- The TS has an access policy of SEMM, where it can use exactly one SP allocation as well as all CBAP allocations with Source AID equal to the broadcast AID, all CBAP allocations with Source AID matching the source STA of the TS, and all CBAP allocations with
Destination AID matching the destination STA of the TS, and in a beacon interval for which the received DMG Beacon has the CBAP Only subfield within the DMG Parameters field set to 1.
|
MAC
|
MAC management
|
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Menzo Wentink/Jouni Malinen
|
6599
|
OBSS scan all messed up: ref to 10.16.5, not clear whether applies to 2G4 STAs, not clear if the dot11...Factor is a factor or a number of scans or what, ActivityFraction is zero in initial
scan before BSS is started, etc.
|
Fix
|
MAC
|
MAC management
|
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Stephen McCann/Mark Hamilton
|
6094
|
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.
|
MAC
|
Interworking
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Stephens, Adrian
|
5038
|
The "Action field format" tables are inconsistent in their interpretation as to the meaning of the "Information" field. Either it names "a field" which might contain a field, an element,
or multiple of them. (e.g. the "Relay Status Code" field contains a Status Code); or the name of the field is absent, and it identifies the information that goes into it (e.g. "one or more elements").
|
Recommend that this be discussed and see if a simple fix to create a single interpretation is possible.
For example, to make the Information hold "[Name: ][field|element]".
This would entail adding missing when the information holds the definition of a new name, and adding field or element to every entry that does not have it.
Furthermore, many of these tables are followed by a list of "the xyz field is defined in ".
These could be combined into the table by moving the xref into the information column, e.g. in parens after field or element. So "Category" becomes "Category (8.4.1.11)". Or we could add a new column for that purpose. So, in 8.6.20.15, "Destination Status Code"
would become "Destination Status Code: Status Code field (optional)"
|
EDITOR
|
General
|
Submission Required
|
|
Assigned
|
CL
|
Clarity/consistency (Large scope)
|
Youhan Kim
|
6495
|
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 a
received 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
|
PHY
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Adrian Stephens
|
5141
|
"All other channel access functions at the STA shall treat the medium as busy"
"treat the medium as busy" is underspecified. Better to include this in the definition of virtual carrier sense.
|
Add to 9.3.2.1 a statement that the virtual carrier sense indicates medium busy during the TXNAV duration and reference 9.22.2.7 for its definition.
|
MAC
|
HCF
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Carlos Cordeiro
|
6057
|
In Table 8-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
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Carlos Cordeiro
|
6335
|
"One or more elements are present in this frame" -- need to explicitly list which those are, and their order
|
As it says in the comment (see also CID 3499)
|
MAC
|
Action Frames
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Carlos Cordeiro
|
6336
|
"One or more elements can appear in this frame." -- need to explicitly list which those are, and their order
|
As it says in the comment (see also CID 3499)
|
MAC
|
Frame formats
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Carlos Cordeiro
|
6337
|
"One or more elements can appear in this frame." -- need to explicitly list which those are, and their order
|
As it says in the comment (see also CID 3499)
|
MAC
|
Action Frames
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Carlos Cordeiro
|
6338
|
"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." -- need to explicitly list which
those are, and their order
|
As it says in the comment (see also CID 3499)
|
MAC
|
Action Frames
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Carlos Cordeiro
|
6339
|
"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." -- need to explicitly list which
those are, and their order
|
As it says in the comment (see also CID 3499)
|
MAC
|
Action Frames
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Carlos Cordeiro
|
6548
|
Why are there duplicate PICS entries for 11ad, e.g. QoS Frame Format
|
Merge them (being careful with the references, which seem to be different)
|
GEN
|
PICS
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Dorothy Stanley
|
5021
|
In dot11SMTbase13, please includes the followings.
dot11DMGOptionImplemented
dot11VHTOptionImplemented
dot11TVHTOptionImpelemented
Also, check other missing features.
|
Check whether dot11SMTbase13 has missing other features.
At least, please include the followings.
dot11DMGOptionImplemented
dot11VHTOptionImplemented
dot11TVHTOptionImpelemented
|
GEN
|
MIB
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Dorothy Stanley
|
6249
|
What does "DEFVAL { short }" mean in for dot11MaxMPDULength? More generally, there shouldn't be defaults for things which are entirely implementation-dependent
|
Remove the DEFVAL for dot11MaxAMSDULength, dot11MaxMPDULength, dot11TVHTMaxMPDULength and any other implementation-dependent capabilities
|
GEN
|
MIB
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Dorothy Stanley
|
6705
|
Why is dot11TVHTMaxMPDULength needed? Why is dot11MaxMPDULength not good enough? Ditto maybe other TVHT MIB variables.
|
Remove the spurious MIB variables
|
GEN
|
MIB
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Edward Au
|
5773
|
"PHY_CCA", "PHY_RXEND", "PHY_DATA" and "PHY_RXSTART": there are no such primitives.
|
Throughout the draft, including all of the related figures, replace "PHY_CCA" with "PHY-CCA", replace "PHY_RXEND" with "PHY-RXEND", replace "PHY_DATA" with "PHY-DATA", and replace "PHY_RXSTART"
with "PHY-RXSTART". It might be possible to search and replace "PHY_" with "PHY-" univarsally (but that still requires manual labor with the figures).
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Edward Au
|
6728
|
"the Sleep Mode element" needs "WNM-" added (and s lowercased). Sometimes "elements", which is suspect. Also follow-ons, e.g. references to "Sleep Mode Request" frames.
|
As it says in the comment
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
FMS (not Qi)
|
6687
|
Isn't "If the AP selects an alternate delivery interval or alternate maximum delivery interval from the value specified in the FMS Request, the FMS Status subelement shall be set to Alternate
Preferred, and the FMS subelement shall indicate the AP selected value(s)." in 10.2.2.16.3 FMS Request procedures duplication of stuff in ....16.4?
|
Remove the duplication
|
MAC
|
Editorials
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Graham Smith
|
5127
|
"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."
The MSDU is an opaque data type to the MAC. This is a statement for the operation of the MAC that implies the MAC knows how to strip an LLC header.
This breaks layering and assumptions made in the system architecture about the MAC.
|
Identify the architectural entity responsible for this behaviour. If this entity is within the scope of the 802.11 STA architecture, move this normative statement to the behavioural description
of that entity.
If the entity is not within scope of the 802.11 architecture, ensure that the interface from the STA (UNITDATA) can indicate the No-LLC field so that higher layers can perform this function.
Likewise adjust the next sentence so that operations on MSDUs are not performed within the MAC.
|
MAC
|
MAC operation
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Graham Smith
|
5129
|
The use of "per" is often ambiguous. It can mean "through", or it can mean "for each".
In the case of: " agreement is determined per block ack agreement.", it could mean that agreement is determined for each block ack agreement, or through the process of block ack agreement.
The ambiguity exists when the thing following "per" can be viewed as a noun describing an object, or a noun describing a process.
|
Review all uses of "per" and replace ambiguous uses by "for each" or "through the process of" (or some less wordy unambiguous alternative).
|
MAC
|
MAC operation
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Graham Smith
|
5531
|
"where the interpretation of the Maximum Transmit Power Level field ... is the same as the Local Maximum Transmit Power Unit Interpretation subfield": presuming that "same as the" applies
to the value in the Transmit Powe Unit Interpretation subfield (and not some evaluation of the subfield itself), then what does "interpretation" mean when it is applied to the Maximum Transmit Power Level field? Does it just mean the value that is that field
in a special case? If that is the case, then why not use "value" instead of the unspecified term "interpretation"? The explanatory note below doesn't help, if only because it refers to both "interpretations" as beiing EIRP. Does this mean that both have the
same value and that value is an ID for EIRP?
|
Replace "where" (on line 51) with "and" (so the reader doesn't worry about which of the three elements above is being referenced).
Replace "the interpretation of the" with "the value of the". Also replace "same as the Local" with "same as the value of the Local". On line 59 replace "interpretation" with "value".
|
MAC
|
TPC
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Jon Rosdahl
|
6416
|
The definition of RSNA key management seems incomplete. 4WH, GTK, PeerKey, FT4WH and FT auth are included, but what about IGTK, SAE, etc.?
|
Add everything, or make the definition more generic
|
GEN
|
GEN Review/discuss
|
Review
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Mark Hamilton
|
6340
|
"Vendor Specific" should not appear in $Foo frame Action field formats, since the VSIEs are in the Action frame not the Action field (per 8.3.3.13/14)
|
Remove vendor-specific elements at 1111.46, 1166.17, 1167.31, 1188.43, 1190.8, 1205.38, 1205.61, 1206.28, 1206.52,
|
MAC
|
Action Frames
|
Discuss
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Mark Hamilton
|
6378
|
The description of auth/assoc handling has statements like "If an Association Response frame is received with a status code of SUCCESS, the state for the AP or
PCP shall be set to [...]". How does the SME know this?
|
Tie this to receiving a .indication (SUCCESS)?
|
MAC
|
MAC state machine
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Mark Hamilton
|
6379
|
The description of auth/assoc handling has statements like "the state variable for the STA shall be set to State 4, or to State 3 if RSNA establishment is required". How does the SME
know whether RSNA establishment is required
|
Tie this to the presence of an RSNE in the (Re)Association Request?
|
MAC
|
MAC state machine
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Mark Hamilton
|
6380
|
"An AP may provide neighbor report information to a STA that requests authentication or association by responding with an Authentication or (Re)Association Response frame that includes
the Reason Code field set to REJECTED_WITH_SUGGESTED_BSS_TRANSITION and that includes one or more Neighbor Report elements." What is this doing here? Why is this not in the auth or reassoc subclauses?
|
Either move the statement to a common subclause, or make it in each subclause and make it specific to that subclause
|
MAC
|
MAC state machine
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Mark RISON
|
5761
|
"PHY shall indicate a busy medium for the intended duration of the transmitted frame as indicated by the LENGTH field.": this doesn't say how this indication is to be made, and fields
don't indicate things (though their values do).
|
Replace "shall indicate a busy medium" with "shall issue a PHY-RXEND indication to notify the MAC of a busy medium". Also, on the next line replace "for intended duration of the transmitted
frame as indicated by the LENGTH field. The intended duration is indicated by the LENGTH field (length x 1 us)." with "for the intended frame transmission duration, as indicated by the value of the LENGTH field (length x 1 us)."
|
GEN
|
GEN Assigned to Mark RISON
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Mark Rison
|
6220
|
The uses of t1-t4 are not clearly explained for the MLME-FINETIMINGMSMT primitives. In the .request, t1 and t4 are the values from the relevant previous .confirm. In the .confirm they
are the values measured for the frame which has just gone out, and the Ack which came back (but there needs to be a way to signal "no Ack"). In the .indication t1 and t4 are from the frame but t2 and t3 are measured
|
Update the descriptions in the tables as it says in the comment
|
MAC
|
Layer management
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Mark Rison
|
6289
|
There is vast scope for confusion regarding "Duration/ID" and "AID" fields (the former is in MAC headers, the latter is in (Re)Assoc Rsp bodies)
|
At 654.63 delete "and places it in the 14 LSBs of the AID field, with the two MSBs of the AID field set to 1 (see 8.2.4.2 (Duration/ID field))". In Figure 8-22 change "AID" to "ID". At
597.42 change "The AID is the value assigned to the STA transmitting the frame by the AP in the Association Response frame that established that STA's current association.
The AID value always has its two MSBs set to 1." to "The ID field contains the AID value assigned to the STA transmitting the frame by the AP in the (Re)Association Response frame that established that STA's current association, with the two MSBs set to 1."
Change "Duration/ID" to "Duration" in Figures 8-25, 8-31, 8-52 and at 613.40, 616.12, 616.13, 616.16, 616.31,
|
MAC
|
Frame formats
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Mark Rison
|
6442
|
The spec says things like "immediate response" and "immediately following" and "immediately after" but does not state what this means. In general, it seems to mean "after SIFS", but in
some contexts this is not the case (e.g. 1409.49)
|
Delete the first para of 8.3.1.1 "In the following descriptions, "immediately previous" frame means a frame whose reception concluded
within the SIFS preceding the start of the current frame." and instead add something somewhere generic (maybe 9.3.2.3.1) the following: "In this standard, unless indicated otherwise, an "immediate response" (or similar constructs with "immediately") is one
which occurs SIFS after the frame causing the response, and an "immediately previous frame" (or similar constructs) is one whose reception concluded a SIFS before the start of the current frame."
|
MAC
|
DCF & HCF
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Mark Rison
|
6459
|
What is the difference between an STSL and a TDLS link? The must be different because there's an STKSA and also a TPKSA
|
Clarify
|
MAC
|
Security
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Mark Rison
|
6470
|
It's not clear how to indicate A-MSDU/A-MPDU aggregation in TSPECs; this can have a significant effect on the medium time required for a particular traffic stream
|
Create a new IE to signal this information (sadly, the TSPEC IE is not extensible). Consider whether A-MSDU aggregation would be better handled by redefining the Nominal MSDU Size field
to be the nominal A-MSDU size if A-MSDUs are used, and if so (a) whether giving information on A-MSDU aggregation could be useful and (b) how the Data Rates in the TSPEC should account for the A-MSDU overheads
|
MAC
|
Frame formats 8.4
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Mark Rison
|
6598
|
Why is it sometimes Capabilities (Extended Capabilities IE, RM Enabled Capabilities IE, HT Capabilities IE, Capabilities field/subfield, HT Capabilities Info field, HT Extended Capabilities
field, TxBF Capabilities field, Timing Capabilities field, RSN Capabilities field) and sometimes Capability (Capability Information FF, Power Capability IE, QoS Capability IE, Nontransmitted BSSID Capability IE, QoS Traffic Capability IE, Capability-List AE,
TDLS Capability AE, QoS Traffic Capability Update frame)?
|
Be consistent
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Mark Rison
|
6679
|
Stuff like "This format is represented at the PHY data service access point (SAP) by the TXVECTOR/RXVECTOR FORMAT parameter being equal to HT_GF." is superfluous (not done for other cases).
|
Remove superfluous verbiage
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Mark Rison
|
6698
|
Where are awake/doze state for IBSS, MBSS defined?
|
Add definitions, modelled on the infrastructure BSS ones
|
MAC
|
Power Saving
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Mark Rison
|
6699
|
Where is active/PS mode for IBSS defined?
|
Add definitions, modelled on the infrastructure BSS ones
|
MAC
|
Power Saving
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Mark Rison
|
6715
|
The capitalisation of "operating class" is haphazard
|
Make it all-lowercase, except in field names etc.
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Mark Rison
|
6718
|
Binary order in tables -- is the order clear enough? Also Tables 8-1, 8-2, 8-143, 9-17, 10-18, 16-8, 17-8, 17-9, 17-10, 17-11, 18-14, 18-15, 18-16, 23-4, 23-13 (references might be to
D3.0). Also some instances of "(binary)" but maybe not all?
|
As it says in the comment
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Mark Rison
|
6719
|
"used together with an operating class number" -- not for non-TVHT. Also say primary upper should match SCO. Also how is primary position specified for VHT? Also get rid of unused behaviours.
Also restrict the "defined by regulations" stuff explicitly to just TVHT and explain because of differening widths. Also what is 80+ for?
|
I will propose text once I've worked out what I was going on about
|
MAC
|
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Mark Rison
|
6720
|
Does "non-VHT" imply "non-TVHT"?
|
Clarify
|
GEN
|
GEN Assigned to Mark RISON
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Mark Rison
|
6723
|
Terms like "HT format PPDU" (including NON_HT, non-HT etc.) don't need the "format"
|
Delete the spurious "format"s throughout
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Mark Rison
|
6730
|
"VHT Capabilities element (optional). The VHT Capabilities element is present if the dot11VHTOptionImplemented is true" (multiple instances). Probably other spurious "Blah element (optionals)"
and also many spurious "the dot11"s (possibly acceptable for *Entry and maybe also *Table?). Also case of "the status code is SUCCESS" (should be Status Code).
|
Delete "VHT Capabilities element (optional)" in the cited text, and similarly in other places. Delete "the" before "dot11" and similarly in other places.
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Mark Rison/Mark Hamilton
|
6075
|
The details of when the PM subfield is valid are still a bit murky. (This is a follow-on comment to changes already made which improved things, but left a bit of work to do.) Also, PM
should be discussed as a field/subfield, not a "bit".
|
A submission will be made by Mark Rison/Mark Hamilton with specific proposed changes.
|
MAC
|
Frame Control field
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Matthew Fischer
|
5870
|
Is there anyting that excludes A-MSDUs from being acknowledged by the basic BlockAck variant - even if it's not the most efficient format?
|
Replace "MSDU" with "MSDU or A-MSDU" throughout the subclause.
|
MAC
|
Frame formats
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Menzo Wentink
|
5909
|
Do TVHT requirements belong in this section (rules for VHT sounding protocol sequences) or should they have a separate section?
|
Clarify
|
MAC
|
MAC operation
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Menzo Wentink
|
5911
|
Do TVHT requirements belong in this section or should they have a separate section?
|
Clarify
|
MAC
|
MAC operation
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Menzo Wentink/Jouni Malinen
|
5052
|
"the STA shall reject the Beacon request" -- it is not clear what is the normative effect of "rejecting" something.
The same issue obtains at: 1662.10, 1670.31, 1720.54 (this occurance might make a whole bunch of "shall reject" statements in 10.24 unnecessary), 1727.02, 1727.41, 1884.31, 1884.42, 1885.36, 2087.19, 2098.60, 2099.03.
|
State the normative effect of "rejecting" or reword to avoid a "shall" followed by an undefined or unobservable verb.
|
MAC
|
MAC management
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Menzo Wentink/Jouni Malinen
|
5523
|
"Every STA shall maintain an inactivity timer for every negotiated direct link": since the value of the DLS Timeout Value field might be 0, what does the inactivity timer do in that case?
|
Replace "Every STA shall" with "When the DLS timeout value given in the DLS Request frame's DLS Timeout Value field is nonzero, every STA shall". But something still needs to be added
about what happens (is there an inactivity timer or not?) when that value is zero.
|
MAC
|
MAC management
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Menzo Wentink/Jouni Malinen
|
5986
|
It would be nice to includde DMG in the names of all MAC parameters that are DMG-secific (Table 10-24 parameters).
|
Follow a preferably consistent convention such as renaming "aDtime to "aDMGDtime"
|
MAC
|
MAC management
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Menzo Wentink/Jouni Malinen
|
6065
|
"A STA that implements DMS has dot11DMSImplemented set to true." ... "A STA that has a value of true for dot11DMSActivated is defined as a STA that supports the directed multicast service."
The first sentence covers the ...Implemented attribute. The second covers the ...Activated attribute. But, the conditions for the two aren't clearly different. The second of these sentences seems to be unnecessary, and not worth trying to clarify it.
|
Delete the sentence, "A STA that has a value of true for dot11DMSActivated is defined as a STA that supports the directed multicast service." Also change "support(s) DMS" to "have/has
DMS activated", and change "supports both DMS and FMS" to "has both DMS and FMS activated", throughout this subclause.
|
MAC
|
MAC management
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Menzo Wentink/Jouni Malinen
|
6185
|
It is not clear whether the rules in 10.23.6.4 supersede, augment or are an alternative to the rules in 10.23.6.2, as regards a 40 MHz direct link
|
Clarify (e.g. does 10.23.6.2 only apply to non-VHT HT STAs and 10.23.6.4 only apply to VHT STAs?)
|
MAC
|
MAC management
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Menzo Wentink/Jouni Malinen
|
6196
|
10.23.6.2.1 says: "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"
but 10.23.6.4.1 says: "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" -- note the "any". This is inconsistent
|
Resolve the inconsistency, either by making 10.23.6.2.1 only require any of the two, or by making 10.23.6.4.1 require all of them
|
MAC
|
MAC management
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Menzo Wentink/Jouni Malinen
|
6309
|
"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?
|
Align 2.4 and 5 GHz operation, and also define the answer for other bands (e.g. TVWS)
|
MAC
|
MAC management
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Menzo Wentink/Jouni Malinen
|
6320
|
If the time to the next burst instance (whether that is the first one, i.e. the one at the Partial TSF Time, or a later one) is large, then the worst-case drift between the two STAs can
easily become comparable or larger than the burst duration. In this regime, when does the iSTA send the trigger frame? Too early, and the rSTA might not be there (and even if it is, the rSTA might ignore it or wait until the start of the burst instance from
its perspective before responding); too later and the rSTA might have given up
|
Add some rules on the minimum Burst Duration (taking into account not only the time to the first burst but also the burst interval, for multi-burst sessions)
|
MAC
|
MAC management
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Menzo Wentink/Jouni Malinen
|
6321
|
It is not clear what the rSTA is to do if the iSTA sends the trigger frame just before the end of the burst instance
|
At least add some kind of recommendation that the iSTA send the trigger frame "early enough" in the burst instance
|
MAC
|
MAC management
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Menzo Wentink/Jouni Malinen
|
6389
|
The requirement for an AP to notify (re)associating STAs that it is operating with reduced max NSS is not clearly expressed. Part of the problem is that the text talks of "changes in"
max NSS, but from the perspective of a (re)associating STA (except special case of reassociating to the same AP) this is meaningless.
[The OMN element appears in Beacons, Probe Responses, (Re)Association Requests/Responses, TDLS Setup Responses, TDLS Setup Confirms, Mesh Peering Opens, Mesh Peering Confirms, and of course OMN frames.]
|
I will propose text (not possible to give here)
|
MAC
|
MAC management
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Michael MONTEMURRO
|
5045
|
DMG use of "operationalRateSet" instead of "basic MCS Set" is awkward.
Firstly, the semantics relate to "basic" rather than "operational", secondly it relates to MCSs, not rates.
|
If this does not affect OTA signalling, and I don't think it does, change DMG throughout to use "basic MCS Set".
|
MAC
|
Layer management
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Michael MONTEMURRO
|
5267
|
About the BSSBasicRateSet parameter of the BSSDescription set parameter of the MLME-SCAN.confirm primitive: "DMG BSS: Empty". But a parameter of a primitive is something that is present
in the primitive, whether or not the invoker of the primitive has put any values in it. When a parameter (such as BSSBasicRateSet) is numerical, then some number or other will be present in the parameter. If no number is defined as meaning "Empty", then there
is no such thing as "Empty" in the BSSBasicRateSet parameter.
|
Since the valid values of BSSBasicRateSet are 1-127, it would be easy enough to define the value 0 as meaning "Empty". So insert that definition into this description. (In the normative
text below, references to BSSBasicRateSet being empty, or not, seem to be consistent with such a definition.)
|
MAC
|
Layer management
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Payam Torab Jahroni
|
5991
|
"A DMG STA that transmits a PPDU containing at least one individually addressed MPDU shall set the TXVECTOR parameter Turnaround to 1 if the STA is required to listen for an incoming
PPDU immediately following the transmission of the PPDU; otherwise, the STA shall set the TXVECTOR parameter Turnaround to 0. the STA shall set the TXVECTOR parameter Turnaround to 0 when it transmits an RTS frame." There are cases where a STA is not required
to listen, but the peer may see a transition from Rx to Tx, e.g., STA A and STA B in a Service period (A transmitting, B receiving), which is followed by another Service Period with B transmitting. Is this bit intended to be a PHY accelerator (Rx to TX predictor)
with 100% hit rate and some false negatives, or less than 100% hit rate and no false negatives? Define the correct behavior.
|
Text will be provided.
|
MAC
|
DCF & HCF
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Sigurd Schelstraete
|
5914
|
In Table 22-1, sometimes reference is made to Table 20-1 for HT-related values, while sometimes content of Table 20-1 is copied explicitly.
|
Propose to consistently refer to Table 20-1 when appropriate rather than duplicating text in both Table 22-1 and Table 20-1.
|
GEN
|
VHT PHY
|
Submission Required
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Solomon Trainin
|
5221
|
There is a layer of meaning in this state machine that is obscure.
The leftmost top bubble "expands" to the state machine below it. But the rightmost bubble expands to one of the two state machines below it with transitions that are not shown.
|
Redraw the state machine so that all states are shown and all transitions identified clearly.
Make matching changes at 1585.02.
|
MAC
|
Power Saving
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Stephen McCann
|
6500
|
StrictlyOrdered is deprecated, and +HTC is much more likely nowadays
|
Rename the Order bit to the "Order/+HTC" bit
|
MAC
|
Frame Control field
|
|
|
Assigned
|
CM
|
Clarity/consistency (Med scope)
|
Youhan Kim
|
6674
|
What does "or CH_OFFSET is not present" mean? a) This table seems to be about tx, and the xXVECTOR table says this is always present in the TXVECTOR. b) If this is supposed to be about
rx, then how does it work, since that table says this is never present in the RXVECTOR -- how does the MAC know what offset it was?
|
Clarify
|
GEN
|
PHY
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Adrian Stephens
|
5031
|
"It is set to 1 if the STA supports both Link cooperating type and Link switching type. It is set to 0 if a STA supports only
Link switching or if the Duplex subfield is set to 1."
So, what happens if the STA supports both Link cooperation, link switching and duplex?
"Link cooperating type and Link switching type" -- the capitalization of the various "Link" types doesn't follow WG style. The language it poor, in what sense is a "type" supported.
|
Reword thus: "It is set to 1 if the STA supports both link cooperation and link switching. It is set to 0 otherwise."
|
MAC
|
Frame formats 8.4
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Adrian Stephens
|
6226
|
It is not possible to request elements with an element ID extension
|
Add words to that effect
|
MAC
|
Frame formats 8.4
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Adrian Stephens
|
6415
|
"The Channel Number field indicates a current operating channel, or a center frequency index of the frequency segment (if the indicated channel comprises noncontiguous frequency segments)"
-- the parenthesis makes no sense. 1) What is its precedence w.r.t. the "or"? 2) Which frequency segment is being referred to, if there is more than one?
|
Clarify (maybe need to say "of frequency segment 0"?)
|
MAC
|
Frame formats 8.4
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Adrian Stephens
|
6536
|
There are a bunch of "*BSS network"s, which seems pleonastic (about 20 instances)
|
Delete the "network"s
|
MAC
|
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Adrian Stephens
|
6589
|
Colons in MAC addresses and suchlike imply bit-reversed notation, which is definitely Not The Done Thing anymore
|
Change the colons to hyphens, or put an explicit note that they are not meant to imply bit-reversed notation
|
MAC
|
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Adrian Stephens
|
6671
|
The last bullet point of NOTE 2 in Table 8-173--HT Operation element fields and subfields seems useless (OBSS is covered by the second bullet and associated STAs are covered by the first)
and dangerous (what, any old Management frame?!). Maybe ditto 9.26.2 "A Management frame (excluding a Probe Request) is received where...". [these may be references to D3.0]
|
As it says in the comment
|
MAC
|
Motion MAC-BA Pulled
|
Discuss
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Adrian Stephens
|
6774
|
"The SME shall generate an MLME-ASSOCIATE.response primitive addressed to the non-AP and
non-PCP STA." -- primitives are not addressed to STAs, frames are.
|
Change to refer to the field which gives the target STA
|
MAC
|
Motion MAC-BA Pulled
|
Discuss
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Adrian Stephens
|
6791
|
References to both 802.1Q-2004 and 2011 in clause 2/annex A. Classifier type 2 should probably not specify the year, therefore
|
As it says in the comment
|
MAC
|
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Donald Eastlake III
|
6077
|
Figures 5-1 through 5-6 are being further refined by the ARC SC, and should be updated to be: less confusing in the use of double-ended-arrows; easier to represent entities above 802.11
but still within the MAC sublayer (like bridges, for 11ak); and to make "LLC" more general.
|
See 801.11-13/0115r16 (or later) for the detailed proposal.
|
MAC
|
MAC Service
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Donald Eastlake III
|
6082
|
This subclause is about frames passed across the MAC SAP. An MSDU at the MAC SAP can't possibly have a DA of the GCR concealment address. Further, the handling of the "local MAC SAP"
at APs is a subtle concept, best left to 5.1.5.3 (which could be clarified/expanded - the subject of another comment), and 4.5.2.1. Don't try to cover the handling of group addressed MSDUs in the subclause that talks about the service class parameter, it's
just out of place here.
|
Delete the paragraph. Also delete the NOTE at the end of the subclause.
|
MAC
|
MAC Service
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Dorothy Stanley
|
6234
|
Basic rates/MCSes are by definition a property of the BSS, so "BSS" is superfluous
|
Delete "BSS" (and fix subsequent capitalisation, where necessary) at 1607.64, 1606.65, 1247.22, 1288.57, 1289.50, 1289.52, 1289.57, 1291.26, 1291.29, 1293.27, 1294.49, 1296.53, 1846.20,
1846.22, 1846.26, 1846.32
|
MAC
|
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Dorothy Stanley
|
6743
|
Why wasn't dot11AuthenticationAlgorithm made the same as dot11AuthenticationAlgorithmIndex? Can we make this change now?
|
As it says in the comment
|
GEN
|
MIB
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Edward Au
|
5694
|
"A STA that has a value of true for dot11WNMNotificationActivated is defined as a STA that supports WNM-Notification. A STA for which dot11WNMNotificationActivated is true shall set the
WNM-Notification Enabled field of the Extended Capabilities element to 1.": see the comments on 1536.37; the same problems dominate here (including using initial caps on the capability's name).
|
Replace:
"A STA that has a value of true for dot11WNMNotificationActivated is defined as a STA that supports WNM-Notification. A STA for which dot11WNMNotificationActivated is true shall set the WNM-Notification Enabled field of the Extended Capabilities element to
1."
With:
"A STA whose dot11WNMNotificationActivated value is true shall support WNM notification and shall set to 1 the WNM-Notification field of the Extended Capabilities elements that it transmits."
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Emily Qi
|
6427
|
Are FTM frames bufferable? This subclause suggests they are
|
Either state that a non-AP STA doing FTM needs to be in active mode during burst instances, or state that FTM frames are not bufferable
|
MAC
|
Power Saving
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
FMS (not Qi)
|
6558
|
Half the stuff in 10.2.2.16.3 seems to be about the FMS Response, not the FMS Request
|
Move the stuff to do with the FMS Response to 10.2.2.16.4
|
MAC
|
Editorials
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Ganesh Venkatesan
|
6072
|
Under GCR, an A-MPDU will contain an MPDU with group addressed RA. There are notes explaining that an HT (and VHT) AP can transmit an A-MPDU containing an MPDU with a group addressed
RA, but there is no note saying this is true for GCR APs (non-HT, included), also.
|
Add a "NOTE 3--An AP providing GCR service can transmit an A-MPDU containing MPDUs with a group addressed RA.
|
MAC
|
GCR
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Graham Smith
|
5081
|
"NOTE--An A-PPDU capable DMG STA that receives an A-PPDU responds with an acknowledgment frame, if
appropriate, only after it receives the last PPDU in the A-PPDU. " -- this should not need to be stated, because it will only receive a frame requiring an immediate response in the last A-MPDU of the A-PPDU. It is therefore hinting at how to handle non-compliant
behaviour, which is outside the scope of the standard.
|
Remove cited note.
|
MAC
|
MAC operation
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Graham Smith
|
5126
|
"NOTE--A STA supporting the HT Control field can reset the NAV set by a wrapped RTS frame following the rules
defined in 9.3.2.4 (Setting and resetting the NAV)."
Given the previous para, note is a statement of the obvious put there to "reassure" participants in the standards process as to what the previous para *really really* meant.
Such reassurance should be unnecessary if the previous para is written *really really* clearly enough.
|
Delete cited note.
|
MAC
|
MAC operation
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Graham Smith
|
5128
|
"An A-MSDU contains only MSDUs whose DA parameter values map to a single RA value (see 8.3.2.2
(Aggregate MSDU (A-MSDU) format)). An A-MSDU contains only MSDUs whose SA parameter values
map to a single TA value (see 8.3.2.2 (Aggregate MSDU (A-MSDU) format)). "
This text is "commoner" than the detail about PTP TSPECs and Short A-MSDUs that occurs before it.
|
Move cited text to the start of the subclause. Merge following sentence into previous para.
|
MAC
|
MAC operation
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Graham Smith
|
5135
|
"Further restrictions on TXVECTOR parameter values may apply due to rules found in 9.26 (Protection
mechanisms) and 9.7 (Multirate support)."
What is this telling me? Is it specific to FEC_CODING or not?
|
Either make this specific to FEC_CODING or remove it.
|
MAC
|
MAC operation
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Graham Smith
|
5145
|
"The MCCA enabled neighbor mesh STAs that could cause interference to
transmissions during these reserved time periods, or that would experience interference fromthem, shall not
transmit during these reserved time periods."
How does a neighbor mesh STA know when it might cause interference?
|
Either precisely define "could cause interference" or "would experience interference", or turn the shall into some other verb.
|
MAC
|
MAC operation
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Graham Smith
|
5146
|
"The delayed block ack mechanism is primarily intended to allow existing implementations" -- this may have been true at the time of writing the footnote in 2002, but it is surely no longer
true.
|
Remove cited footnote.
|
MAC
|
MAC operation
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Graham Smith
|
5148
|
"A DMG STA shall support the HT-immediate block ack extension." -- this statement is out of context, because 9.24.1 doesn't mention HT-immediate.
|
Either merge 9.24.7.1 into 9.24.1, or move the cited sentence into 9.24.7.1. The latter is my preference.
|
MAC
|
Motion MAC-BA Pulled
|
Discuss
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Graham Smith
|
5153
|
"A STA shall not transmit PPDUs separated by a RIFS unless the RIFS Mode field of the HT Operation element
is equal to 1." -- this has nothing to do with protection
|
Move cited sentence to 9.3.2.3.2.
Remove any references to 9.26.3.3 that do not reference RIFS protection.
|
MAC
|
Motion MAC-BA Pulled
|
Discuss
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Graham Smith
|
5156
|
"NOTE 6--After transmitting a PPDU requiring a response but not containing anRDG, the state of the RDG/More
PPDU subfield in the response does not affect the behavior ofthe RD initiator" -- this circumstances described in this note cannot occur if the peer is a compliant implementation.
We do not attempt to describe how the protocol responds to non-compliant peers.
|
Remove cited note.
|
MAC
|
Motion MAC-BA Pulled
|
Discuss
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Graham Smith
|
5422
|
"The recognition of a valid Ack frame sent by the recipient of the MPDU requiring acknowledgement, corresponding to this PHY-RXEND.indication primitive, shall be interpreted as successful
acknowledgement, permitting the frame sequence to continue, or to end without retries, as appropriate for the particular frame sequence in progress.": is this a direct quotation from Finnegan's Wake? Clever way to make a simple process look complicated.
|
Replace the drivel quoted in the comment with:
{New paragraph}"If the transmission of an MPDU requires acknowledgement, the acknowledgement comes to the MPDU's transmitter in the form of an Ack frame. When the STA that transmitted the MPDU recognizes a valid Ack frame in response to the transmission, this
recognition shall be interpreted as successful acknowledgement. Successful acknowledgement allows the STA's frame transmission sequence either to continue or to end without retries (whichever is appropriate for the particular frame sequence in progress)."
Then replace the following sentences: "
|
MAC
|
DCF & HCF
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Graham Smith
|
5423
|
"The recognition of anything else, including
any other valid frame, shall be interpreted as failure of the MPDU transmission. In this instance, the STA shall invoke its backoff procedure at the PHY-RXEND.indication primitive and may process the received frame. An exception is that recognition of a valid
Data frame sent by the recipient of a PS-Poll frame shall also be accepted as successful acknowledgment of the PS-Poll frame.": continuation of the obfuscation that worked so well in the preceding sentence. Unfortunately, clearer descriptions are even longer.
|
Replace the text quoted in the comment with:
"If the STA recognizes any other transmission, including any other valid frame, that recognition shall be interpreted as failure of its MPDU transmission. This happens when the STA's MAC receives a PHY-RXEND.indication primitive from its PHY -- notifying the
MAC that a frame has been received. When this primitive is received by the MAC, the MAC shall invoke its backoff procedure. During the backoff procedure the STA may process the received frame. {New paragraph} An exception (that is, a case in which a non-ACK
frame is received but that event should not be interpreted as a failure of the STA's MPDU transmission) occurs with the PS-Poll frame. If the STA has transmitted a PS-Poll frame, then the STA's receipt and recognition of a valid Data frame transmitted by the
recipient of the PS-Poll frame shall be accepted as successful acknowledgement of the PS-Poll frame."
|
MAC
|
DCF & HCF
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Jouni Malinen
|
6332
|
It says "default pairwise cipher suite and
default group cipher suite for Data frames in an
RSNA" but what does default mean here?
|
Is it referring to the case where the RSNE is truncated before these fields? If so, say so; if not, say what it means
|
MAC
|
Frame formats 8.4
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Jouni Malinen
|
6403
|
Do the msbs need to be irretrievably deleted at 1941.63 (EAPOL-Key MIC), 1896.4 (BIP-CMAC) and 959.5 (Emergency Alert Identifier Hash) in D3.0?
|
Add a Truncate-128() for the first one, and generalise Truncate-128() to Truncate-n(), so the latter two can use Truncate-64()
|
MAC
|
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Hamilton
|
5076
|
"However, in a controlled environment (e.g., no interference), the behavior of the scheduler can be observed and verified to be compliant to meet the service
schedule."
This causes me some issues. Firstly, "no interference" is not a condition that is ever likely to obtain. Even in a deployment in a licensed band, contention-based channel access creates collisions, and STAs below the CCA threshold create interference.
Secondly, I don't know what "verified to be compliant" means. What is this compliance to?
|
Delete the cited sentence.
|
MAC
|
HCF
|
Review
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Hamilton
|
5130
|
"MPDUs in an A-MPDU carried in an HT PPDU shall be limited to a maximum length of 4095 octets.
A STA shall not transmit an MPDU in a VHT PPDU to a STA that exceeds the maximum MPDU length
capability indicated in the VHT Capabilities element received from the recipient STA."
These statements do not relate to the transport of A-MPDUs, but he formation of A-MPDUs from MDPUs.
|
Either change the heading to capture the actual purpose of this subclause or move these statements in a new sibling subclause "constraints on MPDUs carried in an A-MPDU".
|
MAC
|
A-MPDU operation
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Hamilton
|
5137
|
NOTE 4 talks about conditions b) or c) "for a secondary AC". But part of conditions b) and c) is that they are the primary AC. This is inconsistent.
|
Remove NOTE, or reword it to avoid references to b) and c).
|
MAC
|
HCF
|
Review
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Hamilton
|
5542
|
"Any calculation ... shall cause the mitigation requirements for the channel in the current regulatory domain to be satisfied.": "shall cause" -- what kind of normative statement is that?
Technically, if those mitigation requirements just happen to be met (that is their satisfaction wasn't actually _caused_ by the calculation, then the STA fails this normative statement.
|
Replace "shall cause" with "needs to meet" and delete "to be satisfied". If those words don't sound regulatory enough, then replace "needs to meet" with "are required to meet" (and still
delete the "to be satisfied" at the end of the sentence.
|
MAC
|
Editorials
|
Review
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Hamilton
|
5590
|
"Each IBSS STA shall adopt the DFS owner and the DFS owner recovery interval": the procedure of _adopting_ a DFS owner has not been defined -- is there an agency for this sort of thing?
|
Replace '"Each IBSS STA shall adopt the DFS owner and the DFS owner recovery interval" with "Each IBSS STA shall cooperate with the DFS owner and shall use the DFS owner recovery interval
from".
|
MAC
|
DFS
|
Review
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Hamilton
|
5620
|
"and existing mesh peerings may be maintained in the new operating channel.": as long as the peers move to the new channel.
|
Replace "and existing mesh peerings may be maintained in the new operating channel." with "and, as long as the mesh peers move to the new operating channel, their peerings may be maintained
in the new channel."
|
MAC
|
DFS
|
Review
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Hamilton
|
5628
|
"to a new operating channel in a BSS shall be made": since this sublause is about DMG BSSs, should make that clear in this first sentence. Also, for clarification, "may make use of the
information in Supported Channel elements" should emphasize that the information is in received elements.
|
Replace "in a BSS" with "in a DMG BSS".
Replace "information in Supported Channel elements" with "information in received Supported Channel elements". Likewise, on line 11 replace "Announcement element in DMG Beacon frames" with "Announcement element in its transmitted DMG Beacon frames".
|
MAC
|
DFS
|
Review
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Hamilton
|
5631
|
"A Channel Switch Mode equal to 1 means that the STA in a BSS to which the frame containing the element is addressed shall transmit no further frames within the BSS until the scheduled
channel switch.": (1) this says nothing about the STA receiving this Channel Switch Mode field, but how else does the STA know?; (2) meaning is not the critical part of a requirement (the "if..then shall" is the critical part); (3) frames aren't addressed
to BSSs, but STAs in BSSs; (4) open question: this requirement only limits transmissions in a BSS - so the STA is still allowed to transmit (on the soon to be abandoned channel) Action frames to STAs outside the BSS?; (5) this requirement is mitigated by the
following that allows IBSS STAs to ignore this flag - so the "shall" is inaccurate in that case.
|
Replace:
"A Channel Switch Mode equal to 1 means that the STA in a BSS to which the frame containing the element is addressed shall transmit no further frames within the BSS until the scheduled channel switch."
with:
"If a STA in a BSS that is not an IBSS receives a Channel Switch Mode field that has the value 1, it shall not transmit any more frames to STAs in the BSS until the scheduled channel switch occurs."
|
MAC
|
DFS
|
Review
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Hamilton
|
6060
|
Since this "Status Code" is not the same as the generally well-known ones in Table 8-45, call this one something differentiated from those.
|
Change the field "Status Code" to "BTM Status Code", update the text to match, and change Table 8-341 to match.
|
MAC
|
Action Frames
|
Review
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Hamilton
|
6062
|
"timeout" should be GAS_QUERY_TIMEOUT
|
Change 'indicating "timeout"' to 'with ResultCode equal to GAS_QUERY_TIMEOUT'. At 1775.18, change 'result code set to "timeout"' to 'ResultCode equal to GAS_QUERY_TIMEOUT'. At 1775.49,
change ' "Timeout" ' to 'GAS_QUERYY_TIMEOUT'.
|
MAC
|
Interworking
|
Review
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Hamilton
|
6063
|
"transmission failure" is not a valid result code.
|
Change 'result code set to "transmission failure"' to 'ResultCode equal to GAS_QUERY_TIMEOUT'.
|
MAC
|
Interworking
|
Review
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Hamilton
|
6064
|
"unspecified failure" is not a valid ResultCode for an MLME-GAS.confirm primitive. Since NO_OUTSTANDING_GAS_REQUEST is a valid ResultCode, just use that.
|
Change ' "unspecified failure" ' to NO_OUTSTANDING_GAS_REQUEST.
|
MAC
|
Interworking
|
Review
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Hamilton
|
6090
|
Figure 4-14 is far from the "complete" 802.11 architecture.
|
Change the caption for Figure 4-14 to "Complete IEEE Std 802.11 infrastructure architecture." Change the similar phrase at 97.2 to match.
|
MAC
|
General description
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Hamilton
|
6218
|
The difference between State 3 and State 4 is not expressed clearly (though there are hints in Figure 10-12)
|
State explicitly that in State 3 the controlled port is blocked (note that State 4 is also used in a non-RSNA, so there may not be a controlled port at all)
|
MAC
|
MAC state machine
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Hamilton
|
6429
|
The Tx Supported VHT-MCS and NSS Set is not used anywhere
|
Delete the referenced subclause
|
MAC
|
MAC operation
|
Review
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Hamilton
|
6448
|
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 starting at 1323.19 but is never actually defined
|
At the end of the second para of 9.22.2.4 insert "The backoff procedure starts with this step."
|
MAC
|
HCF
|
Review
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Hamilton
|
6721
|
Does "pre-VHT" need defining?
|
Add a definition of the term
|
MAC
|
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Hamilton
|
6818
|
In 10.3.5.5 there is no mention of state deletion for an AP on receipt on reassociation. Would expect something to match the non-AP STA procedure stated in 10.3.5.4 c).
|
Add such information
|
MAC
|
MAC state machine
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Hamilton/Mark RISON
|
6374
|
"The Power Management field is valid only in frame exchanges as described in 10.2.2.2" -- do DMG STAs follow the normal rules (that would be a first...) when in an IBSS?
|
Clarify
|
MAC
|
Motion MAC-BB Pulled
|
Discuss
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Rison
|
6129
|
"Carrier sense" is not defined herein
|
Either change "carrier sense (CS)" to "clear channel assessment (CCA)" or provide a definition for "carrier sense (CS)"
|
GEN
|
GEN CCA
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Rison
|
6299
|
What is a "frame exchange" (anything with not more than one non-Control frame?)? What is a "frame exchange sequence" (anything with SIFS/RIFS separation?)?
|
Clarify (see strawmen in comment)
|
GEN
|
GEN Assigned to Mark RISON
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Rison
|
6549
|
It says "_SAP" (about 33 instances)
|
Replace the underscore with a space in all of them
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Rison
|
6551
|
The subclause headings for xXVECTOR parameters are sometimes missing the "xXVECTOR" or "field" or have a spurious "PHY", e.g. in 16.2.3.5, 18.2.2.6, 18.2.3.4, 18.2.3.5, 18.3.4.3, 16.3.3.3,
16.3.4, 17.2.3.3, 17.2.3.7, 17.2.3.14, 17.2.4 ,18.3.5.5
|
Add the missing "xXVECTOR"s and "field"s, delete the spurious "PHY"s
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Rison
|
6666
|
At 1552.1 in D3.0 add "and a maximum delivery interval" after "a delivery interval".
|
As it says in the comment
|
MAC
|
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Rison
|
6676
|
How do "CH_OFFSET_ABOVE/BELOW/NONE" relate to "CH_OFF_20/40/20L/20U"?
|
Clarify
|
GEN
|
GEN Assigned to Mark RISON
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Rison
|
6732
|
"The [HT] NDP Announcement subfield in the [HT variant] HT Control field is set to 1 to indicate NDP sounding." needs addition of the bracketed terms. Also "and the [HT] NDP Announcement
subfield equal to 0" on p1291. Also "or the [HT] NDP Announcement subfield of the [HT variant] HT Control field" on p1416 (also missing [HT variant] later in para). Page references might be to D3.0
|
As it says in the comment
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Rison
|
6747
|
Does "positive" include 0 (apparently not)?
|
Clarify (perhaps in Subclause 1.4 or 1.5?)
|
GEN
|
GEN Assigned to Mark RISON
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Rison
|
6772
|
There is confusion between "Deny" and "Denied" status/result/reason codes
|
Be consistent
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Rison
|
6775
|
"1-127" for rate sets is bogus because 127 and 126 are not rates but HT/VHT selectors
|
Either change to 1-125 or rename the parameter to refer to "rate set and BSS selector"
|
MAC
|
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Rison
|
6793
|
"FST" is an action, so what's an "FST session"?
|
Clarify
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Rison
|
6795
|
Per the rejection of CID 3372, add "network" after all instances of "BSS" which do not already have it
|
As it says in the comment
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Mark Rison
|
6807
|
"Table 8-162--RM Enabled Capabilities definition" has (a) lowercase "enabled"s in the Field name column and (b) missing articles in the Notes column and (c) inconsistency for "field"
v. "bit" v. nothing.
|
Be consistent
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Matthew Fischer
|
5133
|
"A STA shall not transmit a VHT PPDU if the PPDU duration exceeds aPPDUMaxTime defined in Table 22-29
(VHT PHY characteristics).
NOTE--This restriction limits the maximum value in the LENGTHfield in the L-SIG field of a VHT PPDU to 4095.
A STA shall not transmit a VHT PPDU in TVWS bands if the PPDU duration exceeds aPPDUMaxTime
(defined in Table 23-25 (TVHT PHY characteristics)). "
These statements would better live in 9.14.
|
Move cited text to 9.14.
|
MAC
|
VHT MAC
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Matthew Fischer
|
5868
|
"In an RTS frame transmitted by a VHT STA in a non-HT or non-HT duplicate format and where the scrambling sequence carries the TXVECTOR parameters CH_BANDWIDTH_IN_NON_HT and DYN_BANDWIDTH_IN_NON_HT
(see 9.3.2.6 (VHT RTS procedure)), the TA field is a bandwidth signaling TA."
Is there any other case where the use of bandwidth signaling TA is allowed? If not, make this explicit.
|
Suggested wording, to be added at end of paragraph: "A bandwidth signaling TA shall not be used in any other case"
|
MAC
|
VHT MAC
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Matthew Fischer
|
5874
|
"In a VHT NDP Announcement frame transmitted by a VHT STA in a non-HT or non-HT duplicate format and where the scrambling sequence carries the TXVECTOR parameter
CH_BANDWIDTH_IN_NON_HT, the TA field is set to a bandwidth signaling TA."
Is there any other case where the use of bandwidth signaling TA is allowed? If not, make this explicit.
|
Suggested wording, to be added at end of paragraph: "A bandwidth signaling TA shall not be used in any other case"
|
MAC
|
VHT MAC
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Matthew Fischer
|
6251
|
"When the frame body carries an A-MSDU, the size of the frame body field is
limited by:
[...]
If A-MPDU aggregation is used, a maximum MPDU length of 4095 octets" is not true for VHT or DMG STAs
|
Add "at at non-VHT non-DMG STA" after "used"
|
MAC
|
VHT MAC
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Matthew Fischer
|
6388
|
Is an 80+80 MHz transmission always a "non-contiguous" one? Although 22.1.1 hints that it is ("The VHT PHY provides support for 20 MHz, 40 MHz, 80 MHz, and 160 MHz contiguous channel
widths and support for 80+80 MHz noncontiguous channel width.") nothing in the spec prevents a VHT AP from setting in the VHT Operation Information field:
* Channel Width to indicate 80+80
* Channel Center Frequency Segment 0 to be a segment adjacent to Channel Center Frequency Segment 1
It doesn't help that the adjective "noncontiguous" (sic) only sometimes appears with "80+80" (and ditto with "contiguous" and "160")
|
Add a sentence (the one shown between asterisks) to the bottom right cell of Table 8-242 at 1045.23 as follows: "For an 80+80 MHz operating channel width, indicates the channel center
frequency index of the 80 MHz channel of frequency segment 1 on which the VHT BSS operates. ***The channel center frequency index of segment 1 differs by more than 16 from the channel center frequency index of segment 0 (i.e. the channel center frequencies
are more than 80 MHz apart).*** Reserved otherwise."
Change "noncontiguous 80+80" to "80+80" throughout the spec except in 22.1.1 (about 26 instances).
Change "contiguous 160" to "160" throughout the spec except in 22.1.1 (about 15 instances)
|
MAC
|
VHT MAC
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Matthew Fischer
|
6471
|
"MRQs shall not be sent to STAs that have not advertised support for link adaptation." is not very precise. The VHT formulation at 1411.57, "A STA shall not send an MRQ to STAs that have
not set VHT Link Adaptation Capable subfield to Both in the VHT Capabilities Info field of the VHT Capabilities element." is better
|
Change the referenced sentence to "A STA shall not send an MRQ to STAs that have not set the MCS Feedback subfield to Both in the HT Extended Capabilities field of the HT Capabilities
element."; also add the missing "the" after "set" in the cited VHT text
|
MAC
|
VHT MAC
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Matthew Fischer
|
6492
|
9.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 9.7.5.7"
9.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 8-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
|
VHT MAC
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Matthew Fischer
|
6704
|
"A STA shall not transmit an MPDU in a VHT PPDU to a STA that exceeds the maximum MPDU length capability indicated in the VHT Capabilities element received from the recipient STA." --
why is this in 9.13.5 Transport of A-MPDU by the PHY data service?
|
Move to a more suitable location
|
MAC
|
VHT MAC
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Menzo Wentink
|
5411
|
"A QoS STA shall update its MIB values of the EDCA parameters within an interval of time equal to one beacon interval after receiving an updated EDCA parameter set.": as written this
is a non-specific requirement, as it does not list any minimal set of EDCA parameters that shall be updated. Any STA may have many MIB attributes that in some way incorporate information from the EDCA parameters that are included in the EDCA Parameter Set
element. The only clear requirement is that the QoS STA shall update its copies of the records incorprated in the received EDCA Parameter Set element within the stated time interval.
|
Replace: "shall update its MIB values of the EDCA parameters"
with: "shall update its MIB attribute copies of the records received in a EDCA Parameter Set element".
|
MAC
|
MAC operation
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Menzo Wentink
|
5412
|
"If the EDCA Parameter Set update count value in the QoS Capability element is different from the value that has been stored, the QoS STA shall": passive antecedent to a normative requirement.
If the value is different than the value stored by whom?
|
Replace: "different from the value that has been
stored, the QoS STA shall"
with: "different from the value that the QoS STA has stored, the QoS STA shall".
|
MAC
|
MAC operation
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Menzo Wentink
|
5426
|
"When group addressed MPDUs are not delivered using GATS,": this is ambiguous -- does it mean "when GATS is used but the group addressed frames are not delivered, or does it mean "when
GATS is not used to deliver MPDUs"? I'm guessing the latter and proposing a clearer version of that.
|
Replace "When group addressed MPDUs are not delivered using GATS," with "When GATS is not used to deliver group addressed MPDUs,"
|
MAC
|
MAC operation
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Menzo Wentink
|
5431
|
"shall not transmit a frame using a value for the CH_BANDWIDTH parameter of the TXVECTOR that is not permitted for use in the BSS, as reported in the most recently received HT Operation
element with the exception transmissions on a TDLS off-channel link, which follow": this passive voice is vague both about what is doing the permitting and whether this is a specified requirement.
|
Replace:
"value for the CH_BANDWIDTH parameter of the TXVECTOR that is not permitted for use in the BSS, as reported in the most recently received HT Operation element with the exception transmissions on a TDLS off-channel link, which follow"
With: "value for the CH_BANDWIDTH parameter of the TXVECTOR that the AP does not allow in the BSS, as reported in the STA's most recently received HT Operation element. The one exception is that the STA may still use such CH_BANDWIDTH parameter values for a
TDLS off-channel link transmission, which follow".
|
MAC
|
MAC operation
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Menzo Wentink
|
5442
|
Two almost identical sentences:
"The Buffer size field in the ADDBA Request frame is advisory and may be changed by the recipient for an ADDBA set up between HT STAs."
and
"The Block Ack Timeout Value field is advisory and may be changed by the recipient for an ADDBA set up between HT STAs."
The same problem resides in both sentences: are both features (being advisory and being changeable by the recipient) present because the ADDBA is set up between HT STAs? Or is only the changeability a result of being set up between HT STAs, and the Buffer Size
fields and the Block Ack Timeout Value fields are always advisory?
And surely it is not the fields that are advisory, but their values.
|
Clarify exactly what depends on what -- preferably using direct sentences, such as:
"In the ADDBA Request frame the values of the Buffer Size field and the Block Ack Timeout Value field are advisory. When an ADDBA is set up between HT STAs, the values of both fields may be changed by the recipient."
Either use this version or supply a corrected version.
|
MAC
|
MAC operation
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Menzo Wentink
|
5956
|
There is no "Explicit Compressed Feedback Capable" field defined anywhere in clause 8.
|
Change the cited incorrect field name to "Explicit Compressed Beamforming Feedback Capable" field
|
MAC
|
MAC operation
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Menzo Wentink
|
5976
|
"An A-PPDU is a sequence of two or more PPDUs transmitted without IFS, preamble, and separation between PPDU transmissions." The word separation likely refers to PHY-specific bonding
between adjacent PPDUs and not "airtime" separation, as that has been singled out through mention of IFS. How PPDs are stitched together is PHY-depenndent and needs to be defined per PHY (e.g., for DMG SCit is defined as only one 64-symbol Guard Interval (GI)
between succcessive LDPC blocks from two adjacent PPDUs); suggest to emphasize the PHY dependency of this definnition.
|
Change to: "An A-PPDU is a sequence of two or more PPDUs transmitted without IFS, preamble, and with a PHY-dependent separation between PPDU transmissions."
|
MAC
|
MAC operation
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Menzo Wentink
|
6073
|
This sentence uses "may" when it should be "shall", and it is negative logic. Clean it up.
|
Change "may transmit no more than GCR buffer size A-MSDUs" to "shall transmit less than or equal to the GCR buffer size number of A-MSDUs"
|
MAC
|
MAC operation
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Menzo Wentink
|
6091
|
Figure 9-54 is missing some DSes
|
Insert a box labelled "DS" between the Gate and Portal, and another similar one between the Gate and AP.
|
MAC
|
MAC operation
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Menzo Wentink/Jouni Malinen
|
5051
|
"the STA shall reject the measurement request and return a Measurement Report" -- elsewhere (e.g. 1656.57) we changed this to "shall reject x by returning a ...". The point is that the
cited text describes the normative requirement to reject the request without stating what such rejection entails. The modified " ... by ... " text indicates that the returned (in this case) Measurement Report is how the normative requirement is discharged.
The same issue exists at 1661.02, 1661.30, 1662.41, 1664.23, 1664.50, 1665.57, 1666.30, 1666.52, 1668.26, 1668.44, 1669.44, 1670.08, 1671.20, 1671.40, 1671.55, 1673.21, 1673.45
|
Change to "shall reject the ... by returning a ..."
|
MAC
|
MAC management
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Menzo Wentink/Jouni Malinen
|
5524
|
"The direct link becomes inactive when no frames have been exchanged as part of the direct link for the duration of DLS timeout value, if the DLS Timeout Value field is a nonzero value
during the DLS.": a couple of confusions here: (1) the DLS timeout value is actually the value in the DLS Timeout Value field in the DLS-originating DLS Request frame -- so the quote should instead refer to the duration set according to that value, not to
the duration of the value; (2) the field being nonzero during the DLS -- since the field is transmitted only once (in the DLS Request frame) for the DLS period, it itself does not have much of a duration.
|
Replace:
"The direct link becomes inactive when no frames have been exchanged as part of the direct link for the duration of DLS timeout value, if the DLS Timeout Value field is a nonzero value during the DLS."
with:
"The DLS timeout value is set according to the value of the DLS Timeout Value field in the DLS Request frame that initiated the direct link. If, for the period of time specified by the DLS time out value, no frames are exchanged as part of the direct link,
then the direct link becomes inactive."
|
MAC
|
MAC management
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Menzo Wentink/Jouni Malinen
|
5526
|
"procedures that may satisfy needs" and "frequency bands and may be useful for other purposes": in neither case is this normative term being used for specification.
|
On line 41 replace "that may" with "designed to" and on line 42 replace "bands and may" with "bands. These procedures might".
|
MAC
|
MAC management
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Menzo Wentink/Jouni Malinen
|
5641
|
"wait for dot11RMMeasurementProbeDelay": there seems to be no specification of how the value of this attribute is set. For instance, this value appears to bear no relationship to any
of the values of the ProbeDelay parameters of the SME-invoked .request primitive calls. So does the MAC designer just dream up any arbitrary value that she or he desires?
|
Specify a way that dot11RMMeasurementProbeDelay shall be set. Otherwise delete this arbitrary attribute and any sentences about it in the standard.
|
MAC
|
MAC management
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Menzo Wentink/Jouni Malinen
|
5659
|
"equal to at least dot11TDLSProbeDelay": there seems to be no specification of how the value of this attribute is set. For instance, this value appears to bear no relationship to any
of the values of the ProbeDelay parameters of the SME-invoked .request primitive calls. So does the MAC designer just dream up any arbitrary value that she or he desires?
|
Specify a way that dot11TDLSProbeDelay shall be set. Otherwise delete this arbitrary attribute and any sentences about it in the standard.
|
MAC
|
MAC management
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Menzo Wentink/Jouni Malinen
|
5958
|
"To prevent this from happening, the STA can request a notification frame be sent when requesting the establishment of the traffic filter. If negotiated with the AP, a frame match is
indicated to the non-AP STA via a notification frame." Such a Notify frame may be delivered to the non-AP STA after the delivery of the multicast frame. When this happens, it can only inform the non-AP STA that it has missed certain type of frames, but cannot
prevent the loss of these multicast frames. This is already reflected in the note in Line 38 of page 1752. "NOTE--Due to the operation of group addressed frame delivery, a group addressed frame that matches a traffic filter might result in the STA receiving
indication of the group addressed frame either before or after the group addressed frame is transmitted by the AP, if the TFS Notify frame is queued in the STA's power save queue. This might result in the STA receiving the group addressed frame in some cases
and not receiving it in other cases."
|
Delete "To prevent this from happening, the STA can request a notification frame be sent when requesting the establishment of the traffic filter. If negotiated with the AP, a frame match
is indicated to the non-AP STA via a notification frame."
|
MAC
|
MAC management
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Menzo Wentink/Jouni Malinen
|
6191
|
It says ""Since the channel access in a DMG BSS allows DMG STAs to send frames directly to each other, a DMG STA shall not use the TDLS protocol." -- what does this mean? The channel
access (EDCA) in a non-DMG also allows non-DMG STAs to send frames directly to each other, but the point is that they're not sent via the AP (or possibly PCP, in the DMG case)
|
Delete the cited sentence
|
MAC
|
MAC management
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Menzo Wentink/Jouni Malinen
|
6381
|
"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 10.3.4.5 and 10.3.5.7
|
MAC
|
MAC management
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Menzo Wentink/Jouni Malinen
|
6401
|
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")
|
I'm reliably informed that the intent is that an OC indicating 40 MHz (or up to 40 MHz) is used to indicate a 40 MHz PPDU only -- need to say that explicitly
|
MAC
|
MAC management
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Menzo Wentink/Jouni Malinen
|
6463
|
"The Notify Channel Width frame may be used by a non-AP STA to notify another STA that the STA wishes to receive frames in the indicated channel width." -- it may also be used by an AP
|
Delete "non-AP" in the cited text
|
MAC
|
MAC management
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Menzo Wentink/Jouni Malinen
|
6464
|
It says "If the above three conditions are met, the AP should not transmit a 40 MHz PPDU containing one or more frames with a group address in the Address 1 field if the most recently
received Notify Channel Width frame for any of the STAs associated with the AP has the Channel Width field equal to 0." -- what if no NCW frame was received?
|
Change the cited text to "If the above three conditions are met, the AP should not transmit a 40 MHz PPDU containing one or more frames with a group address in the Address 1 field unless
either the AP has not received a Notify Channel Width frame from any STA in the BSS or the Channel Width field of the most recently received Notify Channel Width frame at the AP that was transmitted by each STA that transmitted a Notify Channel Width frame
is nonzero."
|
MAC
|
MAC management
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Menzo Wentink/Jouni Malinen
|
6798
|
"b) At an AP having dot11InterworkingServiceActivated equal to true, subsequent to receiving an if the MLME-REASSOCIATE.indication primitive withhas the EmergencyServices parameter set
to true that and the RSN parameter does not include an RSNE parameter, the SME shall accept the reassociation request even if dot11RSNAActivated is true and dot11PrivacyInvoked is true thereby granting access, using unprotected frames (see 8.2.4.1.9 (Protected
Frame field)), to the network for emergency services purposes." -- there might be other reasons the reassoc request can't be accepted (some other fatally bad parameter).
|
Reword it to say that the SME shall not reject the request merely because blah blah blah
|
MAC
|
MAC management
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Payam Torab Jahroni
|
5977
|
A-PPDU aggrergation is not defined for DMG ODFM (how adjacent PPDUs are transmitted is undefined)
|
Define the A-PPDU aggregation; use DMG SC definnition as reference.
|
GEN
|
PHY
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Payam Torab Jahroni
|
5978
|
A-PPDU aggrergation is not defined for DMG low-power SC (how adjacent PPDUs are transmitted is undefined)
|
Define the A-PPDU aggregation; use DMG SC definnition as reference.
|
GEN
|
PHY
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
sigurd Schelstraete
|
5880
|
It would be nice to indicate "A-MPDU pre-EOF padding" in the figure
|
Add arrow showing beginning to end of A-MPDU pre-EOF padding
|
MAC
|
Frame formats
|
Submission Required
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Sigurd Schelstraete
|
5896
|
The sentence "The behavior described in this subclause is specific to the use of the HT variant HT Control field" is not clear enough.
|
Replace with "This subclause applies to PPDUs containing an HT variant HT Control field"
|
MAC
|
Motion MAC-AP pulled
|
Discuss
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Vinko Erceg
|
6304
|
"reset the PHY CS/CCA timers" -- what PHY CS/CCA timers
|
Refer explicitly to the timers being reset
|
GEN
|
PHY
|
|
|
Assigned
|
CS
|
Clarity/consistency (Small scope)
|
Youhan Kim
|
6477
|
aRxPHYStartDelay is an implementation-dependent quantity, not something which is fixed for a given PHY
|
Change 534.28 to "The delay, in microseconds, from start of the PPDU at the antenna to the PHY-RXSTART.indication primitive." Change 2187.52, 2214.37, 2274.23, 2287.20, 2382.46, 2453.35
to "Implementation dependent"
|
GEN
|
PHY
|
Discuss
|
|
Assigned
|
E
|
Enhance or change existing feature
|
Adrian Stephens
|
5070
|
Anything that purports to identify elements using an Element ID by itself does not support the Element ID extension mechanism introduced in D4.0. The Request element needs to be extended.
|
Create an Extended Request element, which contains a sequence of 2 octet tuples consisting of an Element ID octet and an optional Element ID Extension octet. We might also want to create
a forward compatible method to support 3-octet element IDs for some time in the future.
Whereever a frame supports a Request element, add the Extended Request element. Add text in clause 9 that indicates that any non-extended element IDs requested are put in the existing Request element, and any new ones in the Extended Request element.
|
MAC
|
Frame formats 8.4
|
Submission Required
|
|
Assigned
|
E
|
Enhance or change existing feature
|
Adrian Stephens
|
6488
|
Non-HT BA is obsolete, as is HT-delayed BA. Their presence needlessly complicates the spec
|
Mark them all as so (or deprecated -- I can't remember which one you're supposed to use for the black spot)
|
MAC
|
|
|
|
Assigned
|
E
|
Enhance or change existing feature
|
Adrian Stephens
|
6765
|
One instance of "AES-GCMP" (all others are "AES-GCM").
|
Change the errant one to "AES-GCM"
|
MAC
|
Motion MAC-BA Pulled
|
Discuss
|
|
Assigned
|
E
|
Enhance or change existing feature
|
Graham Smith
|
5155
|
This statement about ignoring unknown values should be extended to over the Element ID extension case.
|
Add statement that a STA that supports any Element ID that implies a n Element ID extension shall parse the Element ID extension, and skip any elements it identifies that it does not
understand.
|
MAC
|
Motion MAC-BA Pulled
|
Discuss
|
|
Assigned
|
E
|
Enhance or change existing feature
|
Mark Rison
|
6677
|
Get rid of the wacko HT modes signalled by CH_OFF_20U/L, since they're not used.
|
As it says in the comment
|
GEN
|
GEN Assigned to Mark RISON
|
Submission Required
|
|
Assigned
|
E
|
Enhance or change existing feature
|
Menzo Wentink
|
5964
|
Explicit feedback beamforming feedback generation can take more time than is available to respond to the request for feedback. Allowing a non-FB frame to preced the FB frame should be
included in order to provide an option for additional computational time when needed.
|
Allow a QoS NULL frame or other MPDU to be inserted immediately preceding the MGMT Action FB frame in the Explicit TXBF exchange.
|
MAC
|
MAC operation
|
|
|
Assigned
|
E
|
Enhance or change existing feature
|
Menzo Wentink
|
5966
|
EIFS can be avoided at devices that do not implement dynamic EIFS (yet) by requiring that a TXOP is always terminated with a transmission of an ACK at the lowest rate within the PHY.
(Dynamic EIFS is defined in 9.3.7, P1042L13.)
|
Require that the TXOP holder terminates a TXOP with an ACK at the lowest rate within the PHY (i.e. at 6 Mbps for 11ac).
|
MAC
|
HCF
|
Submission Required
|
|
Assigned
|
E
|
Enhance or change existing feature
|
Menzo Wentink/Jouni Malinen
|
6370
|
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
|
Have to keep the TID in there for backward-compatibility, but specify that it need not be checked
|
MAC
|
MAC management
|
|
|
Assigned
|
E
|
Enhance or change existing feature
|
Payam Torab Jahroni
|
5995
|
When the data is sent in OFDM, there is a different channel estimate field, therefore Single Carrier devices cannot use this field to decode the header. Therefore SC only devices cannot
decode the header (which is also sent in OFDM) and therefore cannot determine the length of the packet.
|
We propose to send in the beacons an indication of OFDM intolerance. Details will come in a different presentation.
|
GEN
|
PHY
|
Submission Required
|
|
Assigned
|
E
|
Enhance or change existing feature
|
Peter Ecclesine
|
5970
|
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.
|
For Channel Switch, Extended Channel Switch and Mesh Channel Switch, define a Channel Switch Mode or Reason Code to indicate this is not an active channel switch, but indicated the future
preferred channel to be scanned if STAs leave this channel. Define a specific value of Channel Switch Count that is used when the element indicates the future preferred channel.
|
MAC
|
Frame formats 8.4
|
Submission Required
|
|
Assigned
|
E
|
Enhance or change existing feature
|
Peter Ecclesine
|
5972
|
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.
|
For Channel Switch, Extended Channel Switch and Mesh Channel Switch, define a Channel Switch Mode or Reason Code to indicate this is not an active channel switch, but indicated the future
preferred channel to be scanned if STAs leave this channel. Define a specific value of Channel Switch Count that is used when the element indicates the future preferred channel.
|
MAC
|
Frame formats 8.4
|
Submission Required
|
|
Assigned
|
E
|
Enhance or change existing feature
|
sigurd Schelstraete
|
5879
|
"Beamformee STS Capability" links the sounding feedback capability of a STA with the total number of streams that a STA can receive in an MU PPDU. There is no reason these values should
be the same and they should be decoupled to be future-safe.
The issue is explained in more detail in document IEEE 802.11-15/0057.
|
Will bring a detailed text proposal for this comment.
|
MAC
|
Frame formats 8.4
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Adrian Stephens
|
5310
|
"A Yes in the Extensible column": but what is in the column is "Yes" (in quotes because that is the symbol that is actually in the column).
|
Replace 'A Yes in the Extensible' with 'A "Yes" in the Extensible'.
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Edward Au
|
5318
|
"A Yes in the Extensible column": but what is in the column is "Yes" (in quotes because that is the symbol that is actually in the column).
|
Replace 'A Yes in the Extensible' with 'A "Yes" in the Extensible'.
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Edward Au
|
5693
|
What is the difference between "WNM-Notification and WNM notification? If there is no difference in function, then replace the name "WNM-Notification" with "WNM notification".
|
Replace: "WNM-Notification" with "WNM notification" throughout the text, except when it is part of the name of a frame, field, etc. and it uses initial caps: "WNM Notification".
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Edward Au
|
5695
|
"WNM-Notification capability": this is not the name of a frame, field, element, etc., so it does not need initial caps.
|
On line 8 replace "WNM-Notification" with "WNM notification".
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Graham Smith
|
5082
|
"dec(A[b:c]) is the cast to decimal operator" -- this is misleading terminology. There is nothing here special about base 10 arithmetic (decimal).
|
Replace "dec" with "value" in these equations and replace "is the cast to decimal" with "is the value".
|
MAC
|
MAC operation
|
|
|
Assigned
|
ED
|
Editorial
|
Graham Smith
|
5125
|
"shall set the +HTC Support subfield " - there is no such subfield
|
Change "+HTC" to "+HTC-HT".
Make similar changes at 1397.41
|
MAC
|
MAC operation
|
|
|
Assigned
|
ED
|
Editorial
|
Graham Smith
|
5134
|
"Otherwise, the STA is A-PPDU incapable." This is awkward.
There is no need to define "incapable".
|
Replace with "Otherwise, the STA is not A-PPDU capable."
|
MAC
|
MAC operation
|
|
|
Assigned
|
ED
|
Editorial
|
Jon Rosdahl
|
5237
|
Since this standard uses the externally defined term "Address Resolution Protocol", it needs to provide reference to the source of that term.
|
Insert the line: "IETF RFC 826, An Ethernet Address Resolution Protocol, David C. Plummer, November 1982."
|
GEN
|
GEN Review/discuss
|
Discuss
|
|
Assigned
|
ED
|
Editorial
|
Jon Rosdahl
|
6623
|
If you do insist on using exp(), define it in Subclause 1.5
|
As it says in the comment
|
GEN
|
GEN Review/discuss
|
Discuss
|
|
Assigned
|
ED
|
Editorial
|
Mark Hamilton
|
5131
|
"that transmits a VHT PPDU, which contains one or more PSDUs," -- the "contains on or more PSDUs" is part of the condition, so "which" is incorrect.
|
change ", which contains" to "that contains"
|
MAC
|
A-MPDU operation
|
Review
|
|
Assigned
|
ED
|
Editorial
|
Mark Hamilton
|
5566
|
"setQuiet": typo.
|
On lines 57 and 60 and on page 1642 line 2 replace "setQuiet" with "set Quiet".
|
MAC
|
Editorials
|
Review
|
|
Assigned
|
ED
|
Editorial
|
Mark Hamilton
|
5573
|
"An attempt may be made to move a BSS to a new operating channel.": if this were actually a normative statement, it would be a passive normative -- with no indication of the subject;
can any STA do this, or in an infrastructure BSS just the AP, or...? But this is likely just an informative comment, so the "may" is misplaced.
|
Replace "An attempt may be made to move" with "A channel switch is an attempt to move".
|
MAC
|
DFS
|
Review
|
|
Assigned
|
ED
|
Editorial
|
Mark Hamilton
|
5584
|
"Each STA shall include a Channel Map field within the IBSS DFS elements that it transmits.": this implies _all_ such elements, but does not state the requirement directly. Also, once
again, the field is just _in_ the element.
|
Replace "field within the IBSS DFS elements" with "field in all IBSS DFS elements".
|
MAC
|
DFS
|
Review
|
|
Assigned
|
ED
|
Editorial
|
Mark Hamilton
|
5585
|
"is essential.": per the IEEE Style Manual requirements shall use "shall"/"should"/"may" and non-requirements should not appear to be requirements.
|
Replace (on line 5) "The ability to send" with "Each STA shall have the ability to send" and on line 6 delete "is essential".
|
MAC
|
DFS
|
Review
|
|
Assigned
|
ED
|
Editorial
|
Mark Hamilton
|
5596
|
"There are several circumstances when DFS owner recovery is required": "required" is a normative term that is out of place in an IEEE standard.
|
Replace: "recovery is required"
with: "recovery is needed"
|
MAC
|
DFS
|
Review
|
|
Assigned
|
ED
|
Editorial
|
Mark Hamilton
|
5622
|
"the mesh STA is capable of operating in multiple operating classes": 'multiple" implies simultaneity - doubt that a mesh STA is capable of operating in several classes at once.
|
Replace "multiple" with "several".
|
MAC
|
DFS
|
Review
|
|
Assigned
|
ED
|
Editorial
|
Mark Hamilton
|
5625
|
"During a non-HT OBSS scan operation, the channel scan duration is a minimum of dot11OBSSScanPassiveTotalPerChannel TU": this really looks like the "is" should be a "shall be". Also the
total per channel TUs are likely to be more than 1, so replace "TU" with "TUs".
|
Replace "is a minimum" with "shall be a minimum" and on lines 27 and 28 replace "TU" with "TUs".
|
MAC
|
DFS
|
Review
|
|
Assigned
|
ED
|
Editorial
|
Mark Hamilton
|
5700
|
In an IEEE standard the use of "may" is restricted to normative statements in the subject of the standard.
|
Replace "may employ" with "might employ", on line 63 replace "may be different" with "might be different", and on page 1787 replace "may" with "might" on lines 4, 7 and 8.
|
MAC
|
Interworking
|
Review
|
|
Assigned
|
ED
|
Editorial
|
Mark Rison
|
6537
|
Use minuses not hyphens for subtraction and negative numbers
|
As it says in the comment
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Mark Rison
|
6539
|
There are still a bunch of desires (nearly 100), under the "desir" stem (desirable, desiring)
|
Change them in the same way as the CID 2051 resolution
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Mark Rison
|
6581
|
There should be a space before units
|
Make sure there is a (non-break) space between a number and its unit, except in identifiers, variables, etc. (I can provide a list of locations)
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Mark Rison
|
6608
|
There are lots of "Note that"s. Some appear to be normative (they are followed by a modal like "should") and some appear to be purely informative
|
Delete "Note that" before the normative ones and change "Note that" to "NOTE---" before the informative ones
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Mark Rison
|
6620
|
Either always use dedicated glyphs (Unicode codepoints) for 1/2 etc. or never do so
|
As it says in the comment
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Mark Rison
|
6622
|
Don't use exp, use e
|
As it says in the comment
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Mark Rison
|
6631
|
Proprietary codepoints should not be used, as this complicates searching (especially with non-Adobe tools)
|
Replace Unicode characters in the private use area(s) with their canonical equivalents; I can provide a list of locations
|
GEN
|
GEN Assigned to Mark RISON
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Mark Rison
|
6632
|
Canonical codepoints should be used, to help searching
|
Canonicalise the use of Unicode characters (e.g. different ways to represent "micro", "delta", "degree", "multiply"); I can provide a list of locations
|
GEN
|
GEN Assigned to Mark RISON
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Mark Rison
|
6633
|
There is inconsistency as to the capitalisation and hyphenation of "self protected", "vendor specific", "vendor specific protected", "spectrum management", "fast session transfer", "radio
measurement"
|
Make the capitalisation and hyphenation consistent
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Mark Rison
|
6686
|
"that the transmitter of this frame is providing to the destination of the frame" is a bit odd.
|
Make it sound less odd
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Mark Rison
|
6702
|
"bit " v. "B" inconsistency (also case of "Bit")
|
Be consistent
|
EDITOR
|
Editorials - assigned
|
|
|
Assigned
|
ED
|
Editorial
|
Mark Rison
|
6731
|
It says "the status code is SUCCESS"
|
Change "status code" to "Status Code" throughout
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Mark Rison
|
6741
|
Fix the case of "TIM Broadcast" (as for WNM-Sleep Mode under CID 3369).
|
As it says in the comment
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Mark Rison
|
6758
|
Add non-break space after , except for the pilot subcarriers and unitless contexts.
|
As it says in the comment
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Mark Rison
|
6766
|
"A non-AP STA shall be in Active mode upon Association or Reassociation." appears before active mode has been introduced.
|
Add a forward reference
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Mark Rison
|
6773
|
"properly" (formatted, received, etc.) -- the spec should be written with the implicit understanding that things are done properly!
|
Delete "properly" throughout
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Mark Rison
|
6800
|
The type for parameters should not be "As defined in Foo element", just "Foo element".
|
As it says in the comment
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Mark Rison
|
6810
|
Identifiers don't really "name a" $something, they, well, identify them.
|
Change "name" to "identify"
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Mark Rison
|
6812
|
"OFDM"/"SC" "packets" should be "modulations".
|
As it says in the comment
|
EDITOR
|
Editorials - assigned
|
Submission Required
|
|
Assigned
|
ED
|
Editorial
|
Menzo Wentink/Jouni Malinen
|
5985
|
aTSFAccuracy is DMG-specific.
|
Rename all instances of aTSFAccuracy to aDMGTSFAccuracy (I think 3 instances).
|
MAC
|
MAC management
|
|
|
Assigned
|
ED
|
Editorial
|
Menzo Wentink/Jouni Malinen
|
6066
|
CID 3100 changed "parameters" to "attributes", but missed two.
|
Change "The parameters that define some of the MAC characteristics" to "The attributes that define some of the MAC characteristics", and change the column heading "Parameter" to "Attribute"
in Table 10-24.
|
MAC
|
MAC management
|
|
|
Assigned
|
ED
|
Editorial
|
Youhan Kim
|
6782
|
It says "Transmission of HT PPDU with" and "Transmission of HT PPDU is"
|
Change "PPDU" to "PPDUs" in both cases
|
GEN
|
PHY
|
Discuss
|
|
Assigned
|
F
|
New feature
|
Matthew Fischer
|
5961
|
Just as there is an MPDU density limitation in some designs and a field to signal this limitation, there should be a field to allow a limitation on the AMSDU density.
|
Insert a field in the Ext Cap IE to express an AMSDU density limitation per MPDU.
|
MAC
|
Frame formats 8.4
|
Submission Required
|
|
Assigned
|
F
|
New feature
|
Matthew Fischer
|
5962
|
With increasing PHY rates and PPDU BW values, the efficiency of medium utilization continues to drop unless PPDU durations can be maintained. PPDU durations at the higher PHY rates are
limited by the maximum number of MPDUs that can be included in a single AMPDU which is in turn currently limited by the maximum BA window size. The maximum BA window size needs to be increased to allow medium efficiency to increase.
|
Update the BA mechanism to allow for a maximum BA window size of 256 MPDUs. This requires modification to the BA frame, the BA behavioral subclause and other areas.
|
MAC
|
Frame formats
|
Submission Required
|
|
Assigned
|
F
|
New feature
|
Matthew Fischer
|
5963
|
Just as the DMG STA exchange can include information about the current RX buffer status, non-DMG STAs would benefit by similar information.
|
Include a bit in the BA frame that signals a buffer FULL condition at the recipient.
|
MAC
|
Frame formats
|
Submission Required
|
|
Assigned
|
F
|
New feature
|
Menzo Wentink
|
5222
|
End to end prioritization of internal queues is important to manage quality of service. Current approach limits TXOP under RD to be used by the same AC in both direction. End to end internal
links can be established over P2P TSPEC. TSID allows queue identification over single AC w/o overhead to switch between TS of the same AC. In the current definition reverse direction cannot be limited to TSID so no way to keep quality of service in case of
multiple queues sharing the same AC.
|
propose to support end to end quality of service of queues identified by TSID when the access policy is set to SEMM. It still keeps the current approach if there is no TSPEC associated
with or the access policy is EDCA.
|
MAC
|
MAC operation
|
|
|
Assigned
|
F
|
New feature
|
Michael Fischer
|
6107
|
It is possible (even without the inclusion of Vendor Specific elements) for the length of the Beacon frame to exceed the maximum frame size for (at least) the PHYs defined in clauses
16 (DSSS), 17 (HR), 18 (OFDM), and 19 (ERP). If this ever occurs it creates an significant risk of interoperability problems because a conformant implementation is supposed to meet all mandatory normative requirements, but in this situation two of said requirements
-- the contents of the Beacon frame and the maximum frame size -- are in direct conflict.
|
There are several ways to resolve this situation, and I consider it of primary importance for there to be an unambiguous statement of what should be transmitted in cases where this situation
arises. What I consider to be the simplest approach that does not preclude behaviors that are currently permitted is to define which elements are mandatory in all Beacon frames, which elements only need to be sent every Nth beacon, and a rule to sequence the
elements of the second type such that each does get sent at least once in every N Beacons. Document 11-15-0531-00-000m (a submission by this commenter to the May 2015 session in Vancouver) contains a proposal for achieving this. However, this commenter is
certainly open to other approaches of resolving this problem.
|
MAC
|
Frame formats
|
Submission Required
|
|
Assigned
|
F
|
New feature
|
Michael Fischer
|
6108
|
It is possible (even without the inclusion of Vendor Specific elements) for the length of the Probe Response frame to exceed the maximum frame size for (at least) the PHYs defined in
clauses 16 (DSSS), 17 (HR), 18 (OFDM), and 19 (ERP). If this ever occurs it creates an significant risk of interoperability problems because a conformant implementation is supposed to meet all mandatory normative requirements, but in this situation two of
said requirements -- the contents of the Probe Response frame and the maximum frame size -- are in direct conflict.
|
There are several ways to resolve this situation, and I consider it of primary importance for there to be an unambiguous statement of what should be transmitted in cases where this situation
arises. This problem is closely related to the equivalent situation that exists for Beacon frames, but is harder solve because the alternative of sending certain elements only in every Nth Beacon, as discussed in document 11-15-0531-00-000m (a submission by
this commenter to the May 2015 session in Vancouver) is not applicable to Probe Responses. The only obvious approach for Probe Responses is to define which elements are mandatory and which elements may optionally be omitted if insufficient space is available
(perhaps with a precedence for deciding which to omit). The document cited above contains some suggestions in this regad.
|
MAC
|
Frame formats
|
|
|
Assigned
|
F
|
New feature
|
Peter Ecclesine
|
5969
|
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.
|
For Channel Switch, Extended Channel Switch and Mesh Channel Switch, define a Channel Switch Mode or Reason Code to indicate this is not an active channel switch, but indicated the future
preferred channel to be scanned if STAs leave this channel. Define a specific value of Channel Switch Count that is used when the element indicates the future preferred channel.
|
MAC
|
Frame formats 8.4
|
Submission Required
|