|
Bajko, Gabor
|
7147
|
806.38
|
9.4.2.22.10
|
The mBSSID feature, as currently worded can be interpreted as meaning that if a non-AP STA can support n number of BSSIDs on the same antenna connector, then the mBSSID field would indicate
all of those BSSIDs, regardless of whether they are actively beaconing or not.The current wording could also be interpreted as only the BSSIDs which are 'configured' on the STA to be indicated, which was the original intent of the feature. The suggested changes
remove the ambiguity and clarify the intent of the feature.see resolution in 11-16-0149-00-0000
|
see resolution in 11-16-0149-00-0000
|
MAC
|
Frame Formats
|
|
Cordeiro, Carlos
|
7136
|
2448.13
|
20.5.1
|
This is a pile on to CID5857. As discussed in https://mentor.ieee.org/802.11/dcn/15/11-15-1040-01-000m-dmg-unified-header.docx, compliant DMG devices that support only Control and SC
modes ("SC-only" devices) will be unable to decode the OFDM mode and LPSC mode packet headers, and as a result unable to calculate the duration of these packets. This is an important interoperability issue.
|
Propose to insert the following in clause 20.5.1: "The use of the DMG OFDM mode is deprecated." This would send a signal for vendors not to implement this PHY, and would pave the way
for 802.11ay to then design a proper OFDM PHY that does not exhibit the interop issue that the current OFDM PHY does.
|
GEN
|
DMG PHY
|
|
Cordeiro, Carlos
|
7138
|
2463.15
|
20.6.3.1.2
|
This is a pile on to CID5857 and CID5995. As discussed in https://mentor.ieee.org/802.11/dcn/15/11-15-1040-01-000m-dmg-unified-header.docx, there is an interoperability issue that has
been uncovered with DMG OFDM mode. Essentially, this will prevent vendors from supporting the OFDM PHY, given that it is not desirable to implement a PHY that does not interoperate with the DMG control mode or DMG SC mode.As a result of the above, the maximum
data rate that can be supported by DMG devices is limited to MCS12 of the SC mode, which is about 4.6 Gbps. This is much lower than what could otherwise be achieved with OFDM at 6.8 Gbps.
|
Define new MCSs to the DMG SC mode to allow higher rates. In particular, define 64 QAM based MCSs for SC.
|
GEN
|
DMG PHY
|
|
Ecclesine, Peter
|
7170
|
743.47
|
9.4.2.19
|
In some DFS bands it is important to close the channel as quickly as possible, and one means is to indicate well ahead of time the future preferred channel, so STAs know which channel
the Master intends to migrate the BSS. The Channel Switch Mode field should also have a value to indicate a future preferred channel switch target channel so if the AP or DFS owner ceases transmission on this channel, the other STAs know where to scan next
for the beaconing STA.
|
See 802.11-15/828r8 proposed resolutions of SB0 CIDs 5969, 5970 and 5972 for the proposed text changes.
|
MAC
|
Frame Formats
|
|
Fischer, Michael
|
7139
|
1340.25
|
10.13.6
|
This NOTE in clause 10.13.6 cites a restriction based on rules in 10.13.1 regarding prohibition of inclusion of MPDUs of more than one TID. However, it does not appear that 10.13.1 (and,
in particular, the sub-tables of table 9-420) impose this stated restriction. The actual scope of what TIDs can be included in an A-MPDU does have implications that can affect MAC implementations.
|
Harmonize the statements in 10.13.6, 10.13.1, and the tables 9-420 through 9-425 regarding the permissible contents of an A-MPDU. If the NOTE is correct, clarification is probably needed
in 10.13.1 and/or the tables. If the NOTE is incorrect, it should be removed.
|
MAC
|
MAC Operation
|
|
Fischer, Michael
|
7157
|
3585.27
|
N.3
|
The list of primary functions of an ACM_STA is incomplete. This entity also performs power save buffering, traffic indication, and delivery. Indeed, the principal difference between a
STA and an ACM_STA appears to be the existence of this power save functionality.
|
Add an item "c" to the list of primary functions which states something to the effect "Perform power save buffering, traffic indication, and delivery for mobile units." Figure N-6 should
probably be updated to show the power save support.
|
MAC
|
Architecture
|
|
Fischer, Michael
|
7158
|
543.07
|
7.1
|
The DS concept in 802.11 actually provides two, rather distinct, services. One service moves data among the various BSSes of an ESS as well as mesh gates and a portal. The other service
is for management of station mobility within the ESS. The DS SAP defined in this clause is a mixture of these two, with the DS-UNITDATA primitives constituting the DS data service and the DS-STA-NOTIFY primitive constituting (part of?) the mobility service.
The mixing of these two concepts makes it unnecessarily difficult to develop a coherent model of how 802.11 functions as a MAC/PHY within and 802.1 bridged LAN.
|
Add a statement that the DS includes both a data service (illustrated in figure 7-1) and a mobility service, and clarify that DS-UNITDATA is the interface to the data service whereas
DS-STA-NOTIFY is (at least part of) the interface to the mobility service. Describing the mobility service appears to be beyond the scope of a maintenance activity, but explicitly identifying the existence of something that has actually been present throughout
the history of 802.11, and providing a way to refer to this service will remove substantial obstacles to future activities in this area.
|
MAC
|
Architecture
|
|
Hamilton, Mark
|
7808
|
96.01
|
4.4
|
Review 4.4 through 4.9. How are these descriptions different/aligned with clauses 5, 6, 7 and 8?
|
Perform technical and editorial review and remove duplication and bring like concepts together.
|
MAC
|
Architecture
|
|
Hamilton, Mark
|
7815
|
3293.42
|
C.3
|
Why would APCivicLocationTable (and LCI version) be a table of locations (each of which is a sequence of information)?
|
Change the APCivicLocationTable (and LCI version), to be a single sequence (not a table of sequences).
|
GEN
|
MIB
|
|
Hamilton, Mark
|
7817
|
133.54
|
5.1.5.1
|
In Figure 5-1, put BA sscoreboarding between Address 1 address filtering and Duplicate Detection.
|
In Figure 5-1, add a block to the Receiving flow side for "Block Ack scoreboarding", between "Address 1 address filtering" and "Duplicate Detection". Use "(null)" for the transmitting
flow side. Same thing in Figure 5-2.
|
MAC
|
Architecture
|
|
Hamilton, Mark
|
7819
|
131.29
|
5.1.5.1
|
Fix 5.1.5.1 4th paragraph to be in the right order.
|
Align the order of items in the text with Figure 5-1 (running up the Receiving side of the stack).
|
MAC
|
Terminology
|
|
Hamilton, Mark
|
7821
|
118.21
|
4.10.3
|
4.10.3 is way too detailed for clause 4 (frame exchange diagrams, etc.)
|
Move the details (probably to clause 11). Same for 4.10.4, 4.10.5 and 4.10.6.
|
EDITOR
|
Editorials
|
|
Hamilton, Mark
|
7825
|
133.01
|
5.1.5.1
|
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 802.11-16/0151r0 for the detailed proposal.
|
MAC
|
Architecture
|
|
Hamilton, Mark
|
7826
|
653.35
|
9.3.5
|
Figure 9-63 is missing some DSes
|
Insert a box labelled "DS" between the Gate and Portal, and another similar one between the Gate and AP.
|
MAC
|
Frame Formats
|
|
Hamilton, Mark
|
7827
|
3505.13
|
R.3.2
|
This subclause has some significant problems with the architecture of an "AP" and its "BSS". (A single AP can't have multiple BSSIDs, for example. This is probably multiple APs and probably
also multiple ESSs, SSIDs, DSs and Portals. There could be a single physical device that includes the multiple APs, but that is a different architectural structure, and not made clear here.)
|
An Interworking expert will be needed to sort this out.
|
GEN
|
Architecture
|
|
Hiertz, Guido
|
7160
|
1899
|
12
|
The 802.11 standard misses a method to operate an encrypted WLAN without authentication.
|
Include the changes proposed in 11-15/1184 into the standard.
|
GEN
|
Security
|
|
Kasher, Assaf
|
7142
|
2643.18
|
20.6.3.1.2
|
The MCS table contains MCSs only up to 16QAM rate 3/4. Higher MCSs are missing such as 64QAM rates, 5/8, 3/4, 13/16. Also a code rate of 7/8 is mising between MCS9 (QPSK 13/16) and MCS10
(16-QAM 5/8)
|
Document with the details of changes will be provided
|
GEN
|
VHT PHY
|
|
Kasher, Assaf
|
7143
|
2448.08
|
20.5
|
The is a major interoperability issue with OFDM tarnsmissions. THe header of OFDM TX cannot be decoded by devices supporting only mandatory SC modulation. Therefore, these devices cannot
determine the duation of OFDM packets. There are no know implemenation of devices with OFDM.
|
deprecate OFDM.
|
GEN
|
DMG PHY
|
|
Malinen, Jouni
|
7132
|
2072.4
|
13.4.2
|
The page 2072 lines 33-51 is the only place in the standard where the contents of the FTE and MDE in EAPOL-Key messages 2 and 3 of the 4-way handshake is described. The title of this
subclause is "FT initial mobility domain association in an RSN" which is not exactly ideal for describing 4-way handshake behavior since that handshare is used both in the initial mobility domain association and also in cases where FT protocol authentication
is used. For the latter, 4-way handshake is used to rekey PTK either by AP or non-AP STA request, e.g., due to a configured maximum lifetime for the PTK (or EAP authentication; EAP re-authentication is followed by 4-way handshake).An interoperability issue
has come up in this area since there are deployed AP devices that do not follow these FTE/MDE expectations for the case where 4-way handshake is initiated on an association that used the FT protocol. This results in the association getting dropped when trying
to go through the exchange.It would be good for the standard to be clearer on how the 4-way handshake works in all FT cases.It should also be noted that the final paragraph of this subclause discusses one case of PTKSA lifetime expiration detected by the non-AP
STA based on TIE[KeyLifetime]. This is also a bit unclear on whether this is supposed to apply only for the initial mobility domain association (likely not) or also FT protocol cases. It is possible that there was an intent to not allow EAPOL exchanges at
all in an association started with FT protocol. If that is indeed the case, this is not described completely enough (and those example deployed APs speak on this..). If the group decides that this is the approach to use here, the proposed change in the comment
should be replaced with such description that makes it clear that neither the AP nor the non-AP STA shall initiate an EAPOL frame exchange after the initial 4-way handshake in the initial mobility domain association or in association started with FT protocol.
It should be noted that this would break TKIP counter measures since the non-AP STA would have no means for notifying the AP of a receipt of a Michael MIC failure (e.g., when using TKIP as the group cipher).
|
Incorporate changes in https://mentor.ieee.org/802.11/dcn/16/11-16-0173-02-000m-ft-4-way-handshake.docx
|
GEN
|
MAC Operation
|
|
Malinen, Jouni
|
7159
|
2007
|
12.7.6
|
The description of 4-way handshake messages in the subclauses of 12.7.6 have multiple indentation levels and long sentences with multiple conditions for including elements mixed with
other actions. It would be beneficial to reword these descriptions to make the standard easier to read and understand.
|
Clean the subclauses of 12.7.6.
|
EDITOR
|
Editorials
|
|
McCann, Stephen
|
7163
|
977.13
|
9.4.2.96
|
The use of the terms "ANQP query", "ANQP Query" and "ANQP query request" all mean the same thing. When these are an action (as opposed to a Noun), the term should be "ANQP request", as
the verb 'query' is already within the ANQP acronym - Access Network Query Protocol.
|
Change all occurances of "ANQP query", "ANQP Query" and "ANQP query request" to "ANQP request", when these terms are used as an action and not as Nouns.
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7177
|
1342.21
|
10.16
|
In order to reduce power consumption, there should be a dynamic mechanism to request to a peer that it not transmit to the requesting device using LDPC
|
Add a mechanism, based on extending Operating Mode Notification or otherwise
|
MAC
|
MAC Operation
|
|
RISON, Mark
|
7187
|
716.05
|
9.4.1.53
|
Does the Extended NSS BW Support stuff apply to HT PPDUs too?
|
Add a table NOTE to say it only applies to VHT PPDUs
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7188
|
716.08
|
9.4.1.53
|
"In a VHT STA see Table 9-74 (Setting of the Channel Width subfield andDynamic Extended NSS BW subfield at a VHT STA transmitting the OperatingMode field)(Setting of the Channel Width
subfield and Dynamic Extended NSSBW subfield at a VHT STA transmitting the Operating Mode field)" has duplication
|
Remove the second paren. Check all the other subclause parens in the change which added Extended NSS BW Support as it looks as if they might have been included as-is
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7192
|
3617.6
|
R.7
|
"MPDU_pA_MPDU" is clearly nothing to do with the number of MPDUs per A-MPDU (look at the units!), though it's not clear what it is
|
Change to "mysterious_quantity" (3 instances, all on this page)
|
MAC
|
Annex R
|
|
RISON, Mark
|
7195
|
3617.51
|
R.7
|
"min(BA_WIN_Size, max(1,MPDU_pA_MPDU))" is unitally inconsistent (dimensionless, dimensionless, "s/b")
|
I really have no idea what's going on here
|
MAC
|
Annex R
|
|
RISON, Mark
|
7204
|
|
|
There are 195 instances of "Duration field" and 122 instances of "Duration/ID field". Since the only frame that can carry an ID is the PS-Poll frame, some of the latter should probably
be the former
|
Change "Duration/ID field" to "Duration field" where it cannot apply to a PS-Poll frame
|
EDITOR
|
Terminology
|
|
RISON, Mark
|
7207
|
335.01
|
6.3.57
|
The fixes made in 6.3.58 for FTM need to be made here too
|
E.g. fix the time at which the MLME-TIMINGMSMT.indication is sent, and the descriptions of where t1-t4 come from in each of the frames
|
MAC
|
MAC SAP
|
|
RISON, Mark
|
7209
|
661.62
|
9.4.1.8
|
"A DMG STA sets the 8 MSBs of the AID field to 0." is not clear. Is it trying to say that the 8 MSBs are reserved?
|
If so, say so. If not, then the sentence should be deleted, as it follows naturally from putting a value of 1-254 in a 16-bit field
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7210
|
661.41
|
9.4.1.8
|
In 9.4.1.8 AID field the MSBs are no longer required to be set. Might some existing implementations have set them, and if so might some existing implementations get confused if they are
not set? Note this is about the AID field in MMPDUs, not the ID field in PS Polls
|
Say the two MSBs are reserved, to try to make everyone (equally un)happy
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7211
|
2445.1
|
20.4.3.2.1
|
If b0 is used for "differential detector initialisation", whatever that is, it cannot be reserved, can it?
|
Either make the rightmost cell blank (if it's indeed just reserved", or change the leftmost cell to say "Differential detector initialisation" and make the rightmost cell blank (if it's
used for DDI, but the notion does not seem to be covered)
|
GEN
|
DMG PHY
|
|
RISON, Mark
|
7214
|
3.01
|
1.5
|
Define min and max in 1.5 and then stop defining it elsewhere (and use lowercase everywhere)
|
As it says in the comment
|
EDITOR
|
Editorials
|
|
RISON, Mark
|
7218
|
2946.39
|
C.3
|
dot11BeaconRssiTable makes no sense. It seems to suggest there could be 2**32 entries, each with a MAC address and an RSSI
|
Add a mechanism which allows the size of the table to be limited, e.g. the SME requests specific BSSIDs, or the device advertises some kind of limit
|
GEN
|
MIB
|
|
RISON, Mark
|
7220
|
743.26
|
9.4.2.19
|
It is not clear whether a STA that receives a Channel Switch Mode of 1 ("shut up immediately") may continue to transmit to devices outside the BSS. Perhaps not in a non-DMG infraBSS ("The
AP may force STAs in the BSS to stop transmissions until the channel switch takes place by setting the Channel Switch Mode field in the Channel Switch Announcement element to 1.", and more weakly "The AP may request STAs in the BSS to stop transmissions until
the channel switch takes place by setting the Extended Channel Switch Mode field to 1 in the Extended Channel Switch Announcement element.") but yes in an IBSS ("The DFS owner may attempt to silence STAs in the IBSS until the channel switch takes place using
the Channel Switch Mode field in the Channel Switch Announcement element." and " An IBSS STA may treat a Channel Switch Mode field equal to 1 as advisory") or a DMG BSS ("A [DMG] STA may ignore the Channel Switch Mode field", though this is contradicted by
"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.")?
|
Use clearer wording to express what appears to be the intent: non-DMG infra STA shall shut up, DMG or IBSS STA may continue to babble
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7221
|
2531.35
|
19.3.21
|
The term "PHY header" (with case variation) is used but not defined in Clause 19 (and arguably subsequent PHY clauses) and in the MAC
|
Add text to Clause 19 that defines what is meant by "PHY header" and also fix the case to "PHY header" throughout
|
GEN
|
VHT PHY
|
|
RISON, Mark
|
7223
|
1453.04
|
10.32.3
|
"An HT beamformer may use the following worst-case parameters to estimate the duration of the expected frame that contains the feedback response: Basic HT-MCS, HT-Mixed Format, Supported
Grouping." -- what about a VHT beamformer
|
Add an equivalent statement to the VHT BF subclause (10.34.5)
|
MAC
|
MAC Operation
|
|
RISON, Mark
|
7225
|
|
|
The description of the PHYCONFIG_VECTOR is missing for DSSS, HR/DSSS, ERP, DMG and TVHT
|
Add such a description
|
GEN
|
Other PHY
|
|
RISON, Mark
|
7226
|
549.01
|
8.3.4.4
|
The description of the vectors in Clause 8 makes no sense. The various PHYs have very different vectors, so trying to have a generic description just doesn't work ("The name of the field
used to specify the Tx data rate and report the Rx data rate may vary for different PHYs").FWIW, my notes on D4.0 say that the parameters were disposed of as follows:active_rxchain_set: 10.2.5operating_channel: 22.2.4.2, 22.2.4.3channel_offset 22.2.4.2, 22.2.4.3ant-config:
T21.1 onlygroup_id_management: 10.41, 22.3.11.4, 22.3.20partial_aid_list_gid00: 9.20, 22.3.20partial_aid_list_gid63: 9.20, 22.3.20listen_to_gid00: 10.41, 22.3.20listen_to_gid63: 10.41, 22.3.20
|
Delete this subclause (or make it just say that each PHY defines its vectors), and move all the information to the PHY clauses. The PHYCONFIG_VECTORs should be described in tabular form,
as the TX/RXVECTORs are
|
GEN
|
PHY SAP
|
|
RISON, Mark
|
7237
|
2236.3
|
16.2.3.6
|
The Example of LENGTH calculations for CCK should show the boundary case, i.e. the case where LENGTH-LENGTH' is exactly 8/11
|
Add such a row
|
GEN
|
Other PHY
|
|
RISON, Mark
|
7240
|
1017.26
|
9.4.2.129
|
"A non-PCP and non-AP STA that receives a DMG Operation element can use the value of this field to configure the AssociateFailureTimeout parameter in the MLME-ASSOCIATE.request primitive
and theReassociateFailureTimeout parameter in the MLME-REASSOCIATE.request primitive." -- there are no such parameters anymore (we deleted them in favour of dot11(Re)AssociationResponseTimeOut)
|
Given that there are various other FailureTimeoutParameters, perhaps we should reverse our prior change and deprecate the MIB variable instead
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7244
|
162.13
|
6.3.5.3.1
|
What happens if the AuthenticateFailureTimeout in the MLME-AUTHENTICATE.request (which gives the overall timeout) is more than the dot11AuthenticationResponseTimeOut (which is for consecutive
frames in an auth sequence)?
|
Add words to say that the former shall be no more than the latter times the number of message pairs in the sequence
|
MAC
|
MAC SAP
|
|
RISON, Mark
|
7255
|
946.18
|
9.4.2.72
|
It says " the Capability information field of the BSS" -- what's that?
|
Change to "the contents of the Capability Information field in beacons for the BSS"
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7272
|
|
|
There are references to "PS STA"s, but the term is undefined. Does it mean a STA which can do PS or one which is currently in PS mode?
|
Define the _expression_ as refererring to a STA that is in PS mode
|
GEN
|
Terminology
|
|
RISON, Mark
|
7273
|
|
|
There seem to be at least three flavours of awake window: mesh, TDLS and DMG. The first seems to be so denoted, but the others not
|
Add "TDLS" or "DMG" before "awake window" where "mesh" is not present there
|
GEN
|
Terminology
|
|
RISON, Mark
|
7277
|
1771.2
|
11.24.6.4
|
What does "or clock estimate" mean?
|
Delete NOTE 2
|
MAC
|
MAC Management
|
|
RISON, Mark
|
7278
|
144.01
|
6
|
In Clause 6, when an OperationalRateSet is passed down in MLME-JOIN/START.request, it can't include rates not in dot11SupportedDataRatesRxTable
|
Add this caveat to the "Valid range" cell (where it currently says 1-127). Make a similar statement about HT-MCS and VHT-MCSes
|
MAC
|
MAC SAP
|
|
RISON, Mark
|
7292
|
144.01
|
6
|
There are some parameters called "SupportedRate", but this concept is not defined
|
Change to "OperationalRateSet" for MLME-(RE)ASSOCIATE.indication and MLME-DLS.*
|
MAC
|
MAC SAP
|
|
RISON, Mark
|
7298
|
2875.55
|
C.3
|
It makes no sense for capability variables to have a DEFVAL, as they by definition have to take the value corresponding to the device's capabilities
|
Delete the DEFVAL line for all capability variables
|
GEN
|
MIB
|
|
RISON, Mark
|
7311
|
2330.39
|
19.2.5
|
"the MAC shall" in a PHY clause
|
Move to a MAC clause
|
GEN
|
MAC Operation
|
|
RISON, Mark
|
7312
|
2504.27
|
21.2.5.2
|
"the MAC shall" in a PHY clause
|
Move to a MAC clause
|
GEN
|
MAC Operation
|
|
RISON, Mark
|
7320
|
564.01
|
9.2.2
|
Like ASCII strings, UTF-8 strings should not be terminated
|
Add "or UTF-8" after "ASCII"
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7334
|
2405.21
|
19.3.21
|
There is no "Figure 19-26 (PHY receive procedure for HT-greenfield format PPPDU)."
|
Find it, put it in, and delete one of the Ps in "PPPDU"
|
GEN
|
Other PHY
|
|
RISON, Mark
|
7347
|
828.35
|
9.4.2.25
|
A, uh, popular implementation of the RSN protocol cannot cope with RSNE counts that are zero (it does *not* skip over them and just use the defaults)
|
In 9.4.2.25.2 after "The Pairwise Cipher Suite Count field indicates the number of pairwise cipher suite selectors that are contained in the Pairwise Cipher Suite List field." add "The
value 0 is reserved."In 9.4.2.25.3 after "The AKM Suite Count field indicates the number of AKM suite selectors that are contained in the AKM Suite List field." add "The value 0 is reserved."In 9.4.2.25.5 change " The PMKID Count specifies the number of PMKIDs
in the PMKID List field. The PMKID list contains 0 or more PMKIDs" to "The PMKID Count field specifies the number of PMKIDs in the PMKID List field. The value 0 is reserved. The PMKID List field contains PMKIDs"
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7349
|
|
|
It was stated during D4.0 comment resolution (*cough*Adrian*cough*) that "transmission of the Beacon at TBTT is a famously individual and unnamed channel access function"
|
Add a subclause on this CAF
|
MAC
|
MAC Management
|
|
RISON, Mark
|
7352
|
|
|
The case of "authentication transaction sequence number" is not always upper and it's not always followed by field even when it is. My notes have the following examples:"An SAE Commit
message shall use Authentication Transaction Sequence Number one (1). an SAE Confirm message shall use Authentication Transaction Sequence Number two (2)." (and note wrong case after full stop) and "(Authentication transaction sequence number" (4x) and "Authentication
transaction sequence number values 1 and 2"
|
Change everywhere to upper and append "field" where missing (except perhaps for all-lowercase where you argue it's the same distinction as "beacon" v. "Beacon frame"). I note some of
the fields in Table 9-35---Authentication frame body are not all-caps, either
|
EDITOR
|
Editorials
|
|
RISON, Mark
|
7377
|
1966.22
|
12.6.1.3.2
|
"A STA performing secure password-based, or PSK, authentication uses" -- what is "secure PSK"? Is there an insecure PSK? If so, insecure PSK should be defined and obsoleted. If not, "secure"
should be deleted
|
Change to "A STA performing password-based authentication can use"
|
GEN
|
Security
|
|
RISON, Mark
|
7379
|
1766.56
|
11.24.6.3
|
"In the case of requests for 160 MHz bandwidth, the initiating STA can indicate whether it uses a single or two separate RF LOs." -- it not only can but shall (i.e. it shall not lie).
Ditto the rSTA shall so indicate
|
Change "can" to "shall" and extend the statement to cover the responding STA too
|
MAC
|
MAC Management
|
|
RISON, Mark
|
7385
|
|
|
The PHY clauses talk of "MPDU"s, but most of these if not all should be about "PSDU"s
|
Change "MPDU" to "PSDU" in the PHY clauses, except where it really does refer to the entity from a MAC rather than a PHY viewpoint
|
EDITOR
|
Editorials
|
|
RISON, Mark
|
7393
|
1616.06
|
11.3.1
|
"The state variable is kept within the MLME (i.e., is written and read by the MLME). The SME may also read this variable." -- err, how?
|
Add a SAP primitive allowing the SME to find out about changes to the state variable for a given peer
|
MAC
|
MAC Management
|
|
RISON, Mark
|
7395
|
1292.01
|
10.3.4.3
|
What is DMG stuff doing in the middle of this "Backoff procedure for DCF"? Somewhere else it says a DMG STA is a QoS STA and a DMG BSS is a QoS BSS
|
Move this stuff to more appropriate DMG subclause
|
EDITOR
|
Editorials
|
|
RISON, Mark
|
7396
|
1281.32
|
10.3.2.9
|
"After transmitting an MPDU that requires an Ack frame as a response (see Annex G), the STA shall wait for an AckTimeout interval" -- isn't a BA analogue of this needed?
|
Extend this para to cover the case where a BA is required
|
MAC
|
MAC Operation
|
|
RISON, Mark
|
7399
|
1045.09
|
9.4.2.154
|
Why is a No-LLC field needed? Doesn't a zero-length LLC Header Copy field already indicate this?
|
Delete the No-LLC header field
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7400
|
1045.22
|
9.4.2.154
|
Is Table 9-244 normative, i.e. are no other LLC Header Copy field sizes allowed, and are no other LLC header types allowed?
|
Make the table informative
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7417
|
|
|
In clauses 19, 20, 21 the wording is different in the PHY service interface intro:19) The PHY interfaces to the MAC through the TXVECTOR, TXSTATUS, RXVECTOR, and PHYCONFIG_VECTOR.20)
The PHY provides an interface to the MAC through an extension of the generic PHY service interface defined in 8.3.4 (Basic service and options). The interface includes TXVECTOR, RXVECTOR, andPHYCONFIG_VECTOR.21) The PHY provides an interface to the MAC through
an extension of the generic PHY service interface defined in 8.3.4 (Basic service and options). The interface includes TXVECTOR, RXVECTOR, andPHYCONFIG_VECTOR.
|
Make these consistent: include TXSTATUS for 20 and 21, don't claim it's an extension (since the vectors are all under 8.3.4) and generally align the wording
|
GEN
|
PHY SAP
|
|
RISON, Mark
|
7419
|
|
|
10.8 says "For MSDUs or A-MSDUs belonging to the service class of QoSAck when the receiver is a QoS STA, the QoS Data frames that are used to send these MSDUs or A-MSDUs shall have the
Ack Policy subfield in the QoS Control field set to Normal Ack, Block Ack, Implicit Block Ack Request, or PSMP Ack." But 5.1.1.4 says "When an MSDU is received from the MAC SAP with [QoSAck] and the recipient STA is a QoS STA [...] the MSDU is transmitted
using a QoS Data frame with the Ack Policy subfield in the QoS Control field set to either Normal Ack (normal acknowledgment) or Block Ack."
|
Work out which is right and make the other one say the same. Even better, avoid the duplication
|
MAC
|
MAC Operation
|
|
RISON, Mark
|
7421
|
1949.37
|
12.5.5.3.6
|
It says "A GCMP protected individually addressed robust Management frame shall be protected with the TK." -- what about other GCMP-protected frames? Note for the recipient this is clearer:
"A GCMP protected individually addressed robust Management frame shall use the same TK as a Data frame."
|
Change to "A GCMP protected frame shall be protected with the appropriate TK, where a GCMP protected individually addressed robust Management frame shall use the same TK as a Data frame."
|
GEN
|
Security
|
|
RISON, Mark
|
7427
|
1740.44
|
11.23.1
|
"A DMG STA shall not use the TDLS protocol." -- may it use DLS?
|
Change to "A DMG STA shall not use the DLS or TDLS protocols."
|
MAC
|
MAC Management
|
|
RISON, Mark
|
7428
|
|
|
The definition of "non-HT PPDU" excludes PPDUs sent by 11abg PHYs - this does not sound right (e.g. wording like "is carried in a non-HT PPDU" would then break)
|
Either change the definition to include PPDUs sent by 11abg PHYs, or examine the 71 or so instances and decide which should become "DSSS, HR/DSSS, ERP or OFDM PPDU"
|
GEN
|
Definitions
|
|
RISON, Mark
|
7429
|
1579.25
|
11.2.2.5.2
|
"The non-AP STA may transmit multiple ADDTS Request frames to the AP where the last received ADDTS Request frame will override any previously received ADDTS Request frame." -- this seems
too general: it only applies if the TID/direction are the same. Any anyway, what is this doing in 11.2.2.5.2 U-APSD coexistence
|
Confirm the specific rules for one ADDTS Req overriding an earlier one are covered elsewhere, then delete this sentence
|
MAC
|
MAC Management
|
|
RISON, Mark
|
7438
|
2875.55
|
C.3
|
There are 5 instances of "This field contains the fixed-point Part of Altitude." Where is the fractional part held?
|
Add 5 MIB variables to hold the corresponding fractional parts
|
GEN
|
MIB
|
|
RISON, Mark
|
7442
|
1772.18
|
11.24.6.4
|
"When the ASAP field is set to 0 by a responding STA, the Follow Up Dialog Token, TOD, TOA, TODError, and TOA Error fields in the Fine Timing Measurement frame following the initial Fine
Timing Measurement frame shall be reserved. " -- also if this frame is re-transmitted (i.e. was not acked)
|
As it says in the comment
|
MAC
|
MAC Management
|
|
RISON, Mark
|
7444
|
3614.27
|
R.5.3
|
There are 4 instances of "RM capability" in this subannex, and one in the MIB, but what does it mean?
|
Change to a defined term, e.g. LCI/civic location measurement capability
|
MAC
|
Annex R
|
|
RISON, Mark
|
7446
|
|
|
We should not be using "packet" except in specific cases like "Packet Number" and "Null Data Packet" (see also CID 5362)
|
Scrub them from 19.3.18.5, 20.3.6.4, I.1.8, T19-9, T19-10, 20.10.2.2.4, TK-2, F19-21, F20-2, F20-6, F20-7, F20-23, 6.5.9, 6.5.10, T8-4, T9-51, T9-161, T9-165, 9.4.2.130, 9.4.2.136, 9.4.2.142.1,
9-245, 9.4.2.158.2, 9.4.2.167, 9.5.3, 9.5.4, 10.3.2.3.3, 10.7.7.1, 10.7.7.5, 10.26.5.1, 10.30, 10.32.2.4.3, 10.32.3, 10.34.1, 10.36.6.2, 10.38.3.1, 10.38.3.2, 10.38.6, 10.38.7, 10.41.3.2.3, 11.6, 12.5.4.4, 12.6.21, 13.6.3, 14.12.2, endemically in the PHYs
(and hence the PICS), C.3, G.4, I.5, I.6, I.7, I.8, K.4, P.2, T.2.4, T.2.7changing to MPDU/PPDU/frame as appropriate (it might help to define "sounding packet" so this term can continue to be used)
|
GEN
|
Terminology
|
|
RISON, Mark
|
7448
|
532.01
|
6.5
|
The PHY test modes are not used anywhere, and are not defined for PHYs other than DSSS and DMG
|
Delete subclauses 6.5.5/6/9.10. Alternatively, add test modes for the other PHYs and also add text in the PHY clauses to indicate how the test modes are to be used (e.g. state in 16.4.5.10
Transmit modulation accuracy), RX is a bit more ambiguous (see 16.4.6.2 Receiver minimum input level sensitivity and 17.3.7.9 Transmit modulation accuracy) which arguments are needed in the primitives to effect the requisite testing; if kept then old stuff
like 33 Mb/s also needs to be deleted
|
MAC
|
MAC SAP
|
|
RISON, Mark
|
7455
|
2229.35
|
15.4.6.5
|
"within 5 us of the start of a MAC slot boundary"-- how does the PHY know where the MAC slot boundaries are?
|
If the answer is PHY-CCARESET.request, say so, and make sure the MAC is required to send this at every slot boundary
|
GEN
|
Other PHY
|
|
RISON, Mark
|
7456
|
2259.33
|
16.3.8.5
|
"within 5 us of the start of a MAC slot boundary"-- how does the PHY know where the MAC slot boundaries are?
|
If the answer is PHY-CCARESET.request, say so, and make sure the MAC is required to send this at every slot boundary
|
GEN
|
Other PHY
|
|
RISON, Mark
|
7477
|
1296.42
|
10.3.7
|
aRxTxTurnaroundTime = aTxPHYDelay + aRxTxSwitchTime + aTxRampOnTime so the spec should make it clear these 4 parameters are not independent (the PHY characteristics tables say they are
implementation-dependent and refer back to 10.3.7, but 10.3.7 does not show the dependency (it's buried in the table in 6.5.4.2)
|
As it says in the comment
|
MAC
|
MAC Operation
|
|
RISON, Mark
|
7478
|
1574.36
|
11.2.2.1
|
"When a STA enters normal (non-APSD) PS mode, any downlink block ack agreement without an associated schedule is suspended for the duration of this PS mode." -- what does "suspended"
mean? For example, does this mean fragmentation is allowed?
|
Change to say that A-MPDUs shall not be used for that BA agreement
|
MAC
|
MAC Management
|
|
RISON, Mark
|
7483
|
2875.55
|
C.3
|
"This is a capability variable. Its value is determined by device capabilities." is duplication (how can a capability variable not be determined by device capabilities, or something determined
by device capabilities not be a capability variable?)
|
Delete the second sentence in each case
|
GEN
|
MIB
|
|
RISON, Mark
|
7484
|
1348.59
|
10.22.2.2
|
The rules for "successful transmission and transmission failure" for the purposes of EDCA backoff are made harder to follow because terms are not used consistently:: "If $blah, the STA
concludes that the transmission of the MPDU has failed." and then "$foo shall be interpreted as failure of the MPDU transmission." and then "$bar is defined to be a failure." They should all be of the same form (e.g. "shall be considered transmission failure")
|
In this subclause, always use "MPDU", not "frame", and express the rules in the same way (so e.g. not "the STA concludes that the transmission of the MPDU has failed" and then "The recognition
of a valid response frame [...] shall be interpreted as a successful response.")
|
MAC
|
MAC Operation
|
|
RISON, Mark
|
7486
|
|
|
There are 12 statements of the form "STA shall set dot11FooActivated to true/false". But dot11FooActivated is set by the SME, not the STA. Also, If dot11FooActivated is supposed to be
set internally, then dot11OCBActivated is wrong
|
Delete all these statements
|
GEN
|
MIB
|
|
RISON, Mark
|
7499
|
549.25
|
8.3.4.4
|
"At most 4 bits out of 8 may be set to 1." for ACTIVE_RXCHAIN_SET - does this mean that a VHT STA with > 4 receive chains can't use SMPS (because a STA with SMPS is required to enable
all rx chains when not in SMPS mode)?
|
Delete this restriction
|
MAC
|
PHY SAP
|
|
RISON, Mark
|
7500
|
738.13
|
9.4.2.9
|
Coverage class can only be specified in units of about 900 m. This is not useful for medium-size BSSes (of the order of 100 m, say). Brian HART adds "And it doesn't deal with OBSS, where
slotted Aloha becomes heterogeneously slotted Aloha (aka unslotted Aloha)."
|
Add coverage class values providing finer control
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7504
|
1764.23
|
11.24.6
|
There should be a mechanism to allow the responding STA to ask the initiating STA to re-initiate an FTM session (because it wants to change the parameters)
|
As it says in the comment. A bit in the FTM frame could be used to signal this
|
MAC
|
MAC Management
|
|
RISON, Mark
|
7521
|
|
|
More generally, what is the range of all the "random number"s in the spec and the things that are chosen "randomly"?
|
Specify the range and distribution in each case
|
GEN
|
Math
|
|
RISON, Mark
|
7523
|
1069.28
|
9.4.2.170.1
|
"Operating Class field is 1 octet in length and indicates the band and bandwidth of the primary channel of the APs in this Neighbor AP Information field." makes no sense, since the bandwidth
of the primary channel is always 20 MHz (excluding 11a oddities)
|
Just say it defines the operating class for the BSS, or words to that effect. Also add an article, and to the start of the next para too
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7528
|
2875.55
|
C.3
|
There are millions of MIB variables/tables to do with LCIs and civic locations, and it is not clear which are used in which contexts (TVWS, DSE, FTM, neighbour report, etc.)
|
Add some words to the parent MIB node to disambiguate them all (including the way in which/why an index is used, where an index is used)
|
GEN
|
MIB
|
|
RISON, Mark
|
7529
|
647.08
|
9.3.3.15
|
There is no reason Action No Acks can't have MICEs. While at the moment it may be the case that such frames carry "information [...] that is of time critical but transient value" (resolution
of CID 6343), this is not a property of Action No Acks per se
|
Add MICEs to Table 9-39 as in Table 9-38
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7532
|
1880.47
|
11.42
|
"A STA that is not a VHT STA shall setdot11OperatingModeNotificationImplemented to false." -- there is no justification for this. Why can't an HT non-VHT STA do OMN?
|
Delete this sentence
|
MAC
|
MAC Management
|
|
RISON, Mark
|
7540
|
1283.09
|
10.3.2.12
|
In 10.3.2.12 Duplicate detection and recovery, what is meant by "QoS Data"? In "a TID subfield in the QoS Control field within QoS Data frames" it appears to refer to any Data frame with
b7 set, but it's not clear in "A STA operating as a QoS STA transmitting a QoS Data frame", "A STA receiving frames that are not QoS Data", "A QoS STA receiving an individually addressed QoS Data frame"
|
Use either "with Subtype field equal to QoS Data" or "QoS (+Data)" (or whatever it is) phraseology, depending on what is intended
|
MAC
|
MAC Operation
|
|
RISON, Mark
|
7542
|
|
|
The changes made for CID 6375 need to be makde for reassociation too
|
As it says in the comment
|
MAC
|
MAC Management
|
|
RISON, Mark
|
7549
|
1146.29
|
9.6.8.16
|
The TDLS Discovery Response frame format (which is the only TDLS frame which is not tunnelled in a Data frame) does not have space for VSIEs. Note this is not the usual thing where you
have an Action field being described, where the Action frame containing the Action field can have some VSIEs after it
|
Allow for VSIEs at the end of the frame
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7558
|
643.01
|
9.3.3.12
|
Table 9-35---Authentication frame body should not explicitly discuss which type of authentication, since this then needs to be kept in sync with Table 9-36---Presence of fields and elements
in Authentication frames. Just always say just "A Blah element is present only in certain Authentication frames as defined in Table 9-36 (Presence of fields and elements in Authentication frames)." This also fixes the spurious article in "present in the FT
Authentication frames" (5 instances).
|
As it says in the comment
|
EDITOR
|
Frame Formats
|
|
RISON, Mark
|
7561
|
3179.35
|
C.3
|
dot11STALCITable OBJECT-TYPE"This table represents the geolocation of the STA as specified in 11.44.1 (General)."is too vague. The way it represents it (AIUI from the TGmc teleconf on
2015-06-05) is as a bounding polygon containing the STA
|
Describe this bounding polygon thing here or in 11.44.1
|
GEN
|
MIB
|
|
RISON, Mark
|
7562
|
3179.44
|
C.3
|
dot11STALCIEntry OBJECT-TYPE"STA's location information in geospatial coordinates" is not true, AIUI from the TGmc teleconf on 2015-06-05. Each entry is a point on a bounding polygon
containing the STA
|
Describe this bounding polygon thing here or in 11.44.1
|
GEN
|
MIB
|
|
RISON, Mark
|
7563
|
3612.65
|
R.4.2.11
|
dot11APLCITable - where is this used? (Cf. dot11APCivicLocationTable, mentioned in clause 9.4.5.13 AP Civic Location ANQP-element)
|
Add something on dot11APCLITable somewhere
|
MAC
|
Annex R
|
|
RISON, Mark
|
7572
|
222.31
|
6.3.19.1
|
"If the Direction element of the SetKeyDescriptor indicates Transmit or Both then the MAC uses the key information for the transmission of all subsequent frames to which the key applies."
-- it should be clearer this applies to the Key ID also, i.e. all subsequent frames transmitted for that type and peer specify the Key ID given
|
As it says in the comment
|
MAC
|
MAC SAP
|
|
RISON, Mark
|
7584
|
2588.45
|
21.3.18.5.1
|
"The thresholds in this subclause are compared with the signal level at each receiving antenna." -- why is this not stated for the HT PHY
|
Add a similar statement to the HT PHY
|
GEN
|
VHT PHY
|
|
RISON, Mark
|
7588
|
1593.48
|
11.2.2.16.4
|
The FMS Status subelement includesboth a delivery interval and a max delivery interval, but clearlythe delivery interval only specifies the delivery interval (duh!).There are two cases
here: one wherethe AP said "Alternate proposed, due to AP changed the delivery interval" and one where itsaid "Alternate proposed, due to AP changed the maximum delivery interval". So need to say that the FMS Statussubelement only specifies one or the other
respectively?Or should the statement be:If the Element Status value in FMS Status subelement is one of [...]:--- The AP does not deliver the requested streams at the delivery interval and maximum delivery interval as specified by the non-AP STA in the FMS
Request element. The FMS Statussubelement specifies a delivery interval and a maximum delivery interval that the AP is willing to accept for the specifiedstreams if the non-AP STA sends another FMS Request with that delivery interval and maximum delivery interval
specified.--- The non-AP STA may submit a new FMS Request that includes the delivery interval value and maximum delivery intervalreceived from the AP. If the AP accepts this new FMS Request, it shall respond as described in 10.2.2.16.2 (FMS general procedures).?
|
As it says in the comment
|
MAC
|
MAC Management
|
|
RISON, Mark
|
7591
|
1063.21
|
9.4.2.167
|
This subclause sometimes identifies frames by "sent by the initating/responding STA" and sometimes by "in the initial FTM frame"
|
Be consistent. Either always talk of the sender or always of the frame
|
EDITOR
|
Editorials
|
|
RISON, Mark
|
7596
|
1568.5
|
11.1.4.3.5
|
What about other things that need to be tied specifically to the probe request?
|
Add " If dot11RadioMeasurementActivated is true and the RSNI element was requested, an RSNI element containing the RSNII of the Probe Request frame shall be included (see 9.4.x.x (RSNI
element) and Table 9-x (RSNI values)).NOTE--If no RSNI measurement result is available, the RSNI value is set to indicate "Measurement not available" (seeTable 9-x (RCPI values))." and similarly for any other frame-dependent elements
|
MAC
|
MAC Management
|
|
RISON, Mark
|
7597
|
1842.42
|
11.30.1
|
What about other things that need to be tied specifically to the probe request?
|
Add " If dot11RadioMeasurementActivated is true and the RSNI element was requested, an RSNI element containing the RSNII of the Probe Request frame shall be included (see 9.4.x.x (RSNI
element) and Table 9-x (RSNI values)).NOTE--If no RSNI measurement result is available, the RSNI value is set to indicate "Measurement not available" (seeTable 9-x (RCPI values))." and similarly for any other frame-dependent elements
|
MAC
|
MAC Management
|
|
RISON, Mark
|
7602
|
3237.62
|
C.3
|
Either get rid of dot11EDThreshold, or extend its use to all the PHYs (i.e. not just DSSS and HR/DSSS)
|
As it says in the comment
|
GEN
|
MIB
|
|
RISON, Mark
|
7603
|
1766.49
|
11.24.6.3
|
A STA should be required to specify a FTM Format and Bandwidth that it (and the BSS, if associated) support
|
As it says in the comment
|
MAC
|
MAC Management
|
|
RISON, Mark
|
7607
|
7.3
|
3
|
The TK/MK stuff is incomplete/inconsistent:3.1 has GMK, GTK, IGTK. Why are these not in 3.2?3.2 has 4WH, 4WSTKH, FT4WH, GKH, GTKSA, PMK, PMKSA, PTK, PTKSA, PKH, SMK, SMKH, SMKSA, STK,
STKSA.3.4 has GMK, GTK, GTKSA, IGTK, IGTKSA, MGTK, [no MGTKSA], MTK, PMK, PMKID, PMKSA, PTK, PTKSA, SMK, [no SMKID], SMKSA, STK, STKSA.Missing TPKSA, mesh PMKSA, mesh TKSA, mesh GTKSA.
|
Move the identified definitions from 3.1 to 3.2Add the identified missing expansions in 3.4Add missing definitions in 3.2
|
GEN
|
Security
|
|
RISON, Mark
|
7608
|
534.55
|
6.5.4.2
|
"The relationship between aMACProcessingTime and the IFS and slot timing is described in 9.3.7 (DCF timing relations) and illustrated in Figure 9-19 (DCF timing relationships)." -- needs
to be extended to EDCA
|
Add references to the EDCAF timing relations subclause and figure
|
MAC
|
MAC SAP
|
|
RISON, Mark
|
7612
|
22.01
|
3.2
|
Cf CID 5746, we have "mesh profile" in Clause 3, but not "mesh configuration"
|
Add a definition of "mesh configuration"
|
GEN
|
Definitions
|
|
RISON, Mark
|
7614
|
948.25
|
9.4.2.75
|
"The Current Count field is reserved when the FMS Counter field is included in the FMS Status subelement." -- but the FMS Counter field is not an optional field, so is always included.
Is this saying that if an FMS Status subelement is present in an MMPDU that also includes an FMS Descriptor element, then the Current Count field of the latter is reserved?
|
If that's indeed what it's trying to say, make it say it, otherwise make it say what it's actually trying to say
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7615
|
26.08
|
3.2
|
The definition of "base channel" is not clear. For example, in an 80 MHz BSS, with a STA that only supports 40 MHz but has sent an Notify Channel Width or Operating Mode Notification
specifying 20 MHz, is the "base channel" from that STA's perspective a 20, 40 or 80 MHz channel?
|
Make it clear whether the "base channel" is the BSS bandwidth, the maximum bandwidth supported by the STA, or the operating bandwidth
|
GEN
|
Definitions
|
|
RISON, Mark
|
7616
|
26.08
|
3.2
|
The definition of "base channel" is not clear. If the "base channel" varies when the STA's operating bandwidth changes (through Notify Channel Width or Operating Mode Notification) then
what does that do to any existing TDLS link where one or the other device does not support "TDLS Wider Bandwidth"?
|
Make it clear whether the "base channel" is the BSS bandwidth, the maximum bandwidth supported by the STA, or the operating bandwidth, and make sure this is compatible with devices that
do not support TDLS Wider Bandwidth
|
GEN
|
Definitions
|
|
RISON, Mark
|
7617
|
22.01
|
3.2
|
The definitions of GMK, GTK, IGTK, PMK, PTK, SMK, STK (maybe also AEK and MTK) need to be aligned
|
As it says in the comment
|
GEN
|
Security
|
|
RISON, Mark
|
7618
|
22.01
|
3.2
|
The definition of "temporal encryption key" needs to cover TKs other than group and pairwise ones
|
As it says in the comment
|
GEN
|
Definitions
|
|
RISON, Mark
|
7619
|
22.01
|
3.2
|
The definition of "temporal key"/"TK" should be generic (i.e. include GTK and IGTK and STK and MTK) but sometimes refers only to the TK (temporal key) in a PTK (transient key)
|
Problem is that PTK already has a different meaning... Find a way to distinguish temporalKs and transientKs
|
GEN
|
Definitions
|
|
RISON, Mark
|
7621
|
2223.22
|
15.4.4.7
|
What does "The TX-to-RX turnaround time shall be measured at the air interface from the trailing edge of the last transmitted symbol to valid CCA detection of the incoming signal. The
CCA should occur within 25 us (10 us for turnaround time plus 15 us for energy detect) or by the next slot boundary occurring after 25 us has elapsed (refer to 15.4.6.5 (CCA)). A receiver input signal 3 dB above the ED threshold described in15.4.6.5 (CCA)
shall be present at the receiver." mean? Does it mean that an 11-original device can be "deaf" to CCA for 25 us after it has transmitted?
|
Reword to be clear that no, a device can't just skip CCA for 25 us
|
GEN
|
Other PHY
|
|
RISON, Mark
|
7622
|
2252.62
|
16.3.6.8
|
What does "The TX-to-RX turnaround time shall be measured at the air interface from the trailing edge of the last transmitted symbol to valid CCA detection of the incoming signal. The
CCA should occur within 25 us (10 us for turnaround time plus 15 us for energy detect) or by the next slot boundary occurring after 25 us has elapsed (refer to 16.3.8.5 (CCA)). A receiver input signal 3 dB above the ED threshold described in16.3.8.5 (CCA)
shall be present at the receiver." mean? Does it mean that an 11b device can be "deaf" to CCA for 25 us after it has transmitted?
|
Reword to be clear that no, a device can't just skip CCA for 25 us
|
GEN
|
Other PHY
|
|
RISON, Mark
|
7623
|
2229.01
|
15.4.6.5
|
If aCCAtime needs to fit in slot time, does this mean it's necessary to detect a DSSS preamble within a slot time? This only allows about 8 bits of preamble, which seems insufficient.
Even worse is "With a valid signal (according to the CCA mode of operation) present at the receiver antenna within 5 us of the start of a MAC slot boundary, the PHY-CCA.indication(BUSY) primitive shall be generated before the end of the slot time.", which
seems to require ability to detect a DSSS preamble within 4 us (9 us slots minus 5 us before the valid signal turns up after the start of the slot) for CCA modes 2 or 3, even if the rx-tx turnaround time is 0!
|
Clarify how aCCAtime works for DSSS
|
GEN
|
Other PHY
|
|
RISON, Mark
|
7624
|
2258.61
|
16.3.8.5
|
If aCCAtime needs to fit in slot time, does this mean it's necessary to detect a DSSS preamble within a slot time? This only allows about 8 bits of preamble, which seems insufficient.
Even worse is "With a valid signal (according to the CCA mode of operation) present at the receiver antenna within 5 us of the start of a MAC slot boundary, the PHY-CCA.indication(BUSY) primitive shall be generated before the end of the slot time.", which
seems to require ability to detect a DSSS preamble within 4 us (9 us slots minus 5 us before the valid signal turns up after the start of the slot) for CCA modes 4 or 5, even if the rx-tx turnaround time is 0!
|
Clarify how aCCAtime works for HR/DSSS
|
GEN
|
Other PHY
|
|
RISON, Mark
|
7625
|
|
|
See other comments on aCCAtime, and then consider: more generally, which ED and PD requirements are required within aCCAtime, and which not?
|
Clarify
|
GEN
|
Carrier Sense
|
|
RISON, Mark
|
7626
|
1602.16
|
11.2.3.5
|
"The following rules describe operation of the ATIM frame and frame transmission to STAs in PS mode in a non-DMG IBSS and in a DMG BSS:". Either the "BSS" was intended to be "IBSS", in
which case it collapses to "in an IBSS", or this is wildly confusing as it's in a subsubsubclause and subsubclause which are about IBSSen (fear it's the latter...)
|
Assuming it's the latter, move the DMG-related behaviour to 11.2.6 or a new 11.2.7 just for DMG BSSen (since 11.2.6 is only for DMG infra BSSen)
|
MAC
|
MAC Management
|
|
RISON, Mark
|
7627
|
656.38
|
9.4.1.4
|
"An AP ignores the Privacy subfield within received (Re)Association Request frames" -- this is clearly behaviour not format
|
Move to Clause 12
|
EDITOR
|
Editorials
|
|
RISON, Mark
|
7629
|
563.01
|
9
|
There are normative modal verbs in this subclause
|
Move behavioural ones (e.g. "may respond", "should discard") to Clause 10 or 11. Change "may be present" to "is optionally present". Change the other "may"s to "can" or "might". Change
the other "should"s to "ought to". Change "shall include" to "includes"
|
EDITOR
|
Editorials
|
|
RISON, Mark
|
7636
|
|
|
The term "awake window" (and capitalised versions thereof) is used in contexts other than "mesh awake window" but is not defined. It appears to be a DMG thing, but there seem perhaps
to be TDLS awake windows too, and things called "ATIM Window/Awake Windows" too
|
Change the DMG-specific ones to "DMG awake window" (case-appropriately), the TDLS ones to "TDLS awake window" (ditto) and if any are left after that, work out what exactly they refer
to! In Waikoloa, Payam TORAB said that at least some "awake window"s should be "ATIM window"s
|
EDITOR
|
Terminology
|
|
RISON, Mark
|
7641
|
|
|
Re CID 5083: Now that we have names for the status codes (Table 9-45), we should use those, not numbers (so 0 -> SUCCESS, 76 ->ANTI_CLOGGING_TOKEN_REQUIRED etc.)
|
As it says in the comment
|
EDITOR
|
Editorials
|
|
RISON, Mark
|
7650
|
2925.61
|
C.3
|
What happens if dot11RSNAActivated is true but the Assoc Req/Rsp doesn't contain an RSNE? Or vice-versa?
|
Mandate that an RSNE be passed over each SAP primitive if dot11RSNAActivated is true and that primitive carries a SAP; mandate that an RSNE not be passed if dot11RSNAActivated is false
|
GEN
|
MIB
|
|
RISON, Mark
|
7655
|
1574.62
|
11.2.2.2
|
"initiated by the STA" -- so this means that the PM mode cannot be changed during RD. However, only timing distinguishes the last frame of a RD exchange from the first frame of a non-RD
exchange, which is awkward to validate
|
Allow the PM mode to be changed in RD
|
MAC
|
MAC Management
|
|
RISON, Mark
|
7656
|
569.44
|
9.2.4.1.7
|
There is wide variation in the setting of the PM bit in Control frames
|
Say that the PM bit is ignored (not reserved, because some implementations do set it to 1) in Control frames
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7657
|
569.44
|
9.2.4.1.7
|
Many implementations fail to distinguish between probe reqs to an associated AP and other probe requests (especially since in 802.11-2007 probe reqs did not carry a valid PM bit)
|
Say that the PM bit is ignored (not reserved, because some implementations do set it to 1) in probe reqs
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7665
|
1056.37
|
9.4.2.158.3
|
"the Extended NSS BW Support bits" -- what bits? Of what?
|
Change to "the Extended NSS BW Supportsubfield in the ". Also change "bits" to "subfield" at 1053.42, 717.23 and 1056.39, and for the last two also add the missing "Support" before that
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7674
|
715.29
|
9.4.1.53
|
It says "The use of these fields is described in 10.7.12.1 (Rx Supported VHT-MCS andNSS Set), 10.7.12.2 (Tx Supported VHT-MCS and NSS Set), and 10.40.8(Extended NSS BW Support Signaling).
For a VHT STA, see Table 9-74(Setting of the Channel Width subfield and Dynamic Extended NSS BWsubfield at a VHT STA transmitting the Operating Mode field). " but the new Rx NSS text has no references to Clauses 9 or 10, but does have a reference to elsewhere
in Clause 8. This seems inconsistent
|
Either refer to Clauses 8 and 9/10 everywhere or nowhere
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7675
|
715.31
|
9.4.1.53
|
"For a VHT STA, see Table 9-74(Setting of the Channel Width subfield and Dynamic Extended NSS BWsubfield at a VHT STA transmitting the Operating Mode field). " -- but this dynamic NSS
stuff is only supported by VHT STAs anyway. And this sentence is too far from the start of the cell
|
Just add T9-74 to the list of things in the previous sentence
|
MAC
|
Frame Formats
|
|
RISON, Mark
|
7678
|
1053.51
|
9.4.2.158.2
|
All the normative stuff in this subclause is in a table
|
Move this para to the row at 1052.6
|
EDITOR
|
Editorials
|
|
RISON, Mark
|
7681
|
1052.48
|
9.4.2.158.2
|
This would be clearer with the Meaning column split into 3, one for 20/40/80, one for 160 and one for 80+80, where the cell can say "not supported", "supported" or "supported at [half/twice]
Max VHT NSS"
|
As it says in the comment
|
EDITOR
|
Editorials
|
|
RISON, Mark
|
7695
|
1461.44
|
10.34.5.2
|
It says "The maximum number of supported spatial streams for receive operation according to thecombination of the corresponding VHT beamformee's Rx VHT-MCS Map subfield in theSupported
VHT-MCS and NSS Set field and VHT Capabilities Information field The maximum number of supported spatial streams according to the Rx NSS subfield value and,when the value of VHT Extended NSS BW Capable subfield received from the VHT Beamformee is1, the Dynamic
Extended NSS BW Support value in the Operating Mode field of the most recentlyreceived Operating Mode Notification frame or Operating Mode Notification element with the RxNSS Type subfield equal to 0 from the corresponding VHT beamformee, as computed according
to10.7.12.1 (Rx Supported VHT-MCS and NSS Set)" -- whose receive operation this is (BFer or BFee?) and whose Rx VHT-MCS, VHT Cap Info and OM this is (BFer or BFee?)
|
Add "beamformee" or "beamformer" everywhere to dispel ambiguity
|
MAC
|
MAC Operation
|
|
RISON, Mark
|
7696
|
1635.44
|
11.4.2
|
It says "corresponds to a VHT-MCS and NSS for which support is indicated by the combination of theTx VHT-MCS Map subfield in the VHT Operation parameter of the MLME-(RE)ASSOCIATE.request
primitive, if present, and the AP's operational VHT-MCS and NSSset, if defined, and the VHT Capabilities Information field, at a bandwidth and guard intervalsupported by the non-AP STA on transmission and permitted in the BSS." -- this is very hard to parse
("the combination of X if present, and Y, if defined, and Z, at A and B and C") and the precedence is unclear
|
Express this clearly. Ditto for rx a few lines down
|
EDITOR
|
Editorials
|
|
RISON, Mark
|
7699
|
393.25
|
6.3.72
|
6.3.72 WNM-Notification response (and maybe others) is missing a "General" or "Introduction" subclause at the start
|
Add such a subclause wherever missing
|
GEN
|
MAC SAP
|
|
RISON, Mark
|
7703
|
|
|
CIDs 6214, 6215, 6216, 6305, 6306 had a broadly agreed direction (see discussion in 15/1155), but were not successfully resolved in the D4.0 BRC
|
Address the issues in the direction suggested in 15/1155
|
GEN
|
Carrier Sense
|
|
RISON, Mark
|
7704
|
|
|
The attempts to resolve CIDs 6214, 6215, 6216, 6305, 6306 in the D4.0 BRC brought to light a number of technical issues
|
Address the issues in the direction suggested in 15/1155
|
GEN
|
Carrier Sense
|
|
RISON, Mark
|
7705
|
|
|
The attempts to resolve CIDs 6214, 6215, 6216, 6305, 6306 in the D4.0 BRC brought to light a number of editorial issues (including inter-PHY wording consistency)
|
Address the issues in the direction suggested in 15/1155
|
EDITOR
|
Editorials
|
|
RISON, Mark
|
7712
|
|
|
CID 6664 addressed "will not"s but how about "will"s?
|
Remove "will"s except in the contexts allowed in the discussion for the resolution of CID 6664
|
EDITOR
|
Editorials
|
|
RISON, Mark
|
7723
|
2032.49
|
12.7.9.4
|
The names of the fields in this and subclauses are not capitalised correctly (e.g. "The group cipher suite shall be set to 00-0F-AC:7.")
|
Capitalise all field names
|
EDITOR
|
Editorials
|
|
RISON, Mark
|
7732
|
|
|
Explicitly mark WEP and TKIP as obsolete and might be removed (not just "deprecated")
|
As it says in the comment
|
GEN
|
Security
|
|
RISON, Mark
|
7735
|
|
|
The stuff on the maximum transmit power is spread around all the place, and it's not immediately clear whether it's duplicated or overlapping or inconsistent.
|
Put it all in one places
|
MAC
|
MAC Management
|
|
RISON, Mark
|
7745
|
3294.13
|
C.3
|
How does dot11APLCITable's index work? How can you have more than one LCI for an AP? Ditto dot11APCivicLocation
|
De-indexify these tables, i.e. make them just a SEQUENCE
|
GEN
|
MIB
|
|
RISON, Mark
|
7746
|
1297.34
|
10.3.7
|
" provided that the CCAsensitivity specification for the attached PHY is met (see 15.4.6.5 (CCA), 16.3.8.5 (CCA), 17.3.10.6 (CCArequirements), 18.4.6 (CCA performance) and 19.3.19.5 (CCA
sensitivity))." -- what about Clauses 20 and 21 and 22?
|
Add references to the CCA bit of these. Or just delete the parenthesis
|
MAC
|
MAC Operation
|
|
RISON, Mark
|
7748
|
1399.5
|
10.24.7.7
|
"An Originator that is a DMG STA shall construct A-MPDUs that contain MPDUs in increasing order of SN.When responding to a BlockAck frame, the Originator shall first retransmit unacknowledged
MPDUs inincreasing order of SN." So a DMG originator could:- first transmit an A-MPDU containing MPDUs with SNs 1, 3, 7 only, in that order- then receive a BA saying 1 and 7 were received- then transmit an A-MPDU containing MPDUs with SNs 3, 2, 4, 5, 6, 8
only, in that order;the first one (only) has the Retry bit setRight? How does the Retry bit help in this case?
|
Change the first sentence to "An Originator that is a DMG STA shall construct A-MPDUs that, apart from retransmissions of unacknowledged MPDUs, contain MPDUs in sequential SN order, starting
from the first MPDU that has never been transmitted."Note that this probably does not allow:first an A-MPDU with Ack Policy "Block Ack" (11)then SIFSthen an A-MPDU with Ack Policy "Implicit Block Ack Request" (00)Is such a sequence allowed in DMG? If so, the
wording will probably have to be more complicated.And if DMG allows partial-state scoreboard operation, the wording will be even trickier, because then you can't even say something like "which was not marked in the most recent Block Ack frame as having been
received" to clarify what is meant by "unacknowledged".Basically what we need to express in standardese is:- If you know you need to retx, you put all the retxes first, in SN order- You put all the non-retxes in consecutive SN order, starting from the first
SN that has not been txed- You are allowed to break things into multiple A-MPDUs, as long as the rules above are honoured, and all A-MPDUs but the last have "Block Ack" ack policyMaybe:An Originator that is a DMG STA shall transmit MPDUs sent under a BA agreement
such that:* MPDUs that need to be retransmitted are sent first, in SN order* MPDUs that are being transmitted for the first time are then sent, in consecutive SN order starting from the MPDU with the first SN that has not been transmitted* MPDUs may be transmitted
in more than one A-MPDU only if all but the last A-MPDU contains MPDUs with ack policy "Block Ack"where SNs are ordered based on modulo-4096 comparisons.
|
MAC
|
MAC Operation
|
|
RISON, Mark
|
7749
|
|
|
According to Solomon TRAININ, "no-ack frames cannot be sent under BA agreement". Presumably this is a DMG restriction as it is not a general restriction. Where is this in the spec, though?
|
Add a statement to that effect (not clear whether this means Action No Ack frames or ack policy No Ack (or Block Ack?))
|
MAC
|
MAC Operation
|
|
RISON, Mark
|
7759
|
|
|
"frame report", "basic report" etc. should have an uppercase for the first word (need to check all the measurement types and the requests too). Also "Measurement report field format"
should have "Report"
|
As it says in the comment
|
EDITOR
|
Editorials
|
|
RISON, Mark
|
7762
|
1449.3
|
10.32.3
|
"The procedures in this subclause apply only to HT and non-HT PPDUs for which the HT Control field, ifpresent, is the HT variant HT Control field." -- is this sufficiently clear that
the subclause is only for non-VHT STAs? VHT STAs can sent HT variant HTCs, after all
|
As it says in the comment
|
MAC
|
MAC Operation
|
|
RISON, Mark
|
7763
|
1453.44
|
10.33.1
|
"The procedures in this subclause apply only to HT and non-HT PPDUs for which the HT Control field, ifpresent, is the HT variant HT Control field." -- is this sufficiently clear that
the subclause is only for non-VHT STAs? VHT STAs can sent HT variant HTCs, after all
|
As it says in the comment
|
MAC
|
MAC Operation
|
|
RISON, Mark
|
7764
|
|
|
Some MLME primitives (e.g. MLME-DSETPC) have no actual behavioural requirements associated with them (in Clause 11)
|
Ensure that all MLME primitives are referred to somewhere other than just Clause 6
|
GEN
|
MAC SAP
|
|
RISON, Mark
|
7766
|
|
|
"idle channel" should be "idle medium"; "busy channel" should be "busy medium" (and ditto when the words are swapped)
|
As it says in the comment
|
EDITOR
|
Editorials
|
|
RISON, Mark
|
7767
|
2875.55
|
C.3
|
The wording after "when object dot11PHYType" in the MIB is inconsistent.
|
Make it consistent
|
EDITOR
|
Editorials
|
|
RISON, Mark
|
7780
|
|
|
"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 9.3.3.14/15)
|
Remove the table rows for vendor-specific information on pp. 1114, 1127, 1183, 1184 of D4.0 (per CID 6341)
|
EDITOR
|
Frame Formats
|
|
RISON, Mark
|
7787
|
|
|
The material related to DMG has a lot of "TXTIME"s without an indication of the PHY parameters (especially the MCS) to be used to determine this. Without this information the "TXTIME"s
are meaningless
|
Add an indication of the PHY parameters (especially the MCS) to be assumed when TXTIME(frame) is mentioned in the context of DMG (and anything else which might suffer from the same problem)
|
MAC
|
MAC Management
|
|
RISON, Mark
|
7791
|
1309.05
|
10.7
|
The multirate rules are an impenetrable mess. It's impossible to determine whether they are complete, let alone whether they are correct
|
Rewrite as a flowchart or table, so that it can be seen that the rules are complete and correct
|
MAC
|
|
|
RISON, Mark
|
7793
|
|
|
10.7.6.1: "Control frames carried in an A-MPDU that does not contain a VHT single MPDU shall be sent at a rate selected from the rules defined in 10.7.5.7"10.7.5.7: is basically about
Data and Management frames, though "The rules in this subclause also apply to A-MPDUs that aggregate MPDUs of type Data or Management with any other types of MPDU."However Table 9-413---A-MPDU contents MPDUs in the control response context shows that you can
have an (non-VHT single MPDU) A-MPDU without a Data or Management frame. In that situation what rate is used?
|
Clarify
|
MAC
|
MAC Operation
|
|
RISON, Mark
|
7794
|
|
|
The HT rules for CCA as they pertain to non-HT transmissions are not clear. The issue is that if you don't know you're dealing with a non-HT transmission (which you don't know unless
you successfully pick up the preamble) you don't know you have to apply the rules ("CCA sensitivity requirements for non-HT PPDUs")
|
Make it clear that the energy detect rules (not the CCA-ED rules, which are something different) from 18 and 19 apply even if you can't work out what type of PPDU/energy you're dealing
with (these are "detect a medium busy condition within 4 us of any signal with areceived energy that is 20 dB above the minimum modulation and coding rate sensitivity" for 2.4 GHz and -- hm, 19.4.6 has no energy detect requirement, that's in 19.3.4 ... but
there's no just energy detect requirement there too. Does this mean HT has no just energy detect requirements (again, not talking of CCA-ED here) in the 5 GHz band?
|
GEN
|
Carrier Sense
|
|
RISON, Mark
|
7795
|
|
|
"A STA shall support the concurrent reception of fragments of at least three MSDUs or MMPDUs." -- frankly, this is not good enough nowadays, even for non-AP STAs (consider QoS, for example)
|
Add "A STA should support the concurrent reception of fragments of at least one MSDU per access category. An AP should support the concurrent reception of at least on MSDU per access
category per associated STA."
|
MAC
|
MAC Operation
|
|
RISON, Mark
|
7796
|
|
|
The distinctions made in the specification w.r.t. TS/TC/TSID/TID are incomprehensible
|
Make the definitions comprehensible. E.g. what does "UP for either TC or TS" mean?
|
MAC
|
Terminology
|
|
RISON, Mark
|
7797
|
|
|
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
|
EDITOR
|
Editorials
|
|
RISON, Mark
|
7798
|
|
|
The material for VHT bandwidth operation etc. needs to be merged in with that for other PHYs
|
As it says in the comment (see also yellow stuff in 14/1104 for CID 3479)
|
GEN
|
Other PHY
|
|
RISON, Mark
|
7799
|
|
|
Various technical issues were raised in yellow stuff in 14/1104
|
Address these technical issues
|
EDITOR
|
Inadequate comment
|
|
Smith, Graham
|
7079
|
624.01
|
9.3.3.3
|
In Tables we have "Order" column, what does this mean? It implies that this is the order that the elements should be transmitted in, or is it simply the order that they were invented?
For example, having looked at beacons from several APs the elements are not transmitted in the order as per Table 9-27. I find that in the beacon, Table 9-27, 1, 2, 3, 4, 5 and 6 are in order in each I measured, but then it varies. What to do? It is clear
that "Order" has not been interpreted as the order in which they are transmitted, so what is it? We could replace "Order" with #, OR specify that the transmitted order is informative only, or fix the order of the first ones? Tables affected: 9-27 to 9-41 inclusive.
Ask for opinions first and then prepare a contribution if positive
|
Several options come to mind and would benefit from discussion however, here is one idea: Add a sentence such as "In Tables 9-27 to 9-41 the Information shall be transmitted in the order
given for Orders 1, 2, 3 and 4. The remaining Information may be transmitted in any order." (I don't like this but it should be enough to get opinions and maybe a solution).
|
MAC
|
Frame Formats
|
|
Smith, Graham
|
7084
|
1297.01
|
10.3.7
|
Figure 10-19 is confusing to say the least: It looks as though SIFS = (D1+M1+Rx/TX), this is not true, (D1+M1+Rx/TX) should have expired before the SIFS boundary. Similarly for PIFS and
DIFS and Slot time.
|
Redraw Fig 10-19 such that the time blocks end before the next boundaries, as it says in comment
|
MAC
|
MAC Operation
|
|
Smith, Graham
|
7086
|
1289.48
|
10.3.4.2
|
"There are conditions, specified in 10.3.4.3 (Backoff procedure for DCF) and 10.3.4.5 (Control of the channel), where the random backoff procedure shall be followed even for the first
attempt to initiate a frame exchange sequence." This appears to indicate that the random back off for the first transmission is an exception rather than the rule. In fact the DCF clauses leave a lot to be desired, are difficult to follow and do not seem to
stress the basic DCF Sequence.
|
The commenter will bring a contribution to 'clean up' and clarify DCF operation.
|
MAC
|
MAC Operation
|
|
Smith, Graham
|
7087
|
1350.12
|
10.22
|
EDCA should be same or very similar to DCF but with AIFS[AC] in place of DIFS. The way it is presented by using the 'EDCA Slot Boundaries' is confusing and very unclear as to what bouindary
applies at what decision point.
|
The commenter will bring a contribution to 'clean up' and clarify EDCF operation. It has too many mistakes to list here.
|
MAC
|
MAC Operation
|
|
Smith, Graham
|
7088
|
1351.39
|
10.22.2.4
|
A BIG PROBLEM exists with the "aRxTxTurnaroundTime" inclusion in every slot boundary. If it is in every slot determination, then each STA may/will have a different wait time. For example
assume the STA is at a randomly selected backoff slot and counting down, then every time the medium becomes busy then it should wait AIFS but if it waits "AIFS aRxTxTurnaroundTime" then a STA with a higher aRxTxTurnaroundTime waits less. In fact no STA will
actually wait AIFS which is the real need. The aRxTxTurnaroundTime is only used at the very end when the STA can switch on its TX early. One does wonder why this obsession with this turnaround, it was not used in DCF, and there is a case as to why it is not
required here. As long as the STA has waited for the prescribed time before it actually transmits, it does not matter if it goes earlier to make up for a turnaround time. It should not need telling. By the way, I recall that a practical value for this is 1-2us
(RIFS for example). However, if considered necessary, it has to be clear that this can only be used only once in the countdown, it cannot be used every time the medium goes busy and the countdown is halted otherwise the wait time is shortened and a STA with
a larger aRxTxTurnaroundTime actually has an advantage. We need to fix this
|
The commenter will bring a contribution to explain and correct this.
|
MAC
|
MAC Operation
|
|
Smith, Graham
|
7089
|
1281.41
|
10.3.2.9
|
"The recognition of a valid Ack frame sent by the recipient of the MPDU requiring acknowledgment,""...valid Ack frame sent by the recipient of the MPDU requiring acknowledgment" is wrong
as the ACK frame does not include the address of the sender hence it is only assumed that the Ack is sent by the recipient of the MPDU. This entire paragraph has problems that were the subject of 15/1274. Due to lack of time, the resolution as provided in
15/1274r0 was not fully discussed and hence was rejected. A revision 15/1274r1 was written as a result of the liited comments that were made.
|
15/1274 r1 to be revised to refer to D5 and presented.
|
MAC
|
MAC Operation
|
|
Smith, Graham
|
7090
|
1374.05
|
10.23.1
|
EDCA TXOPs of a mesh STA that has dot11MCCAActivated true shall not overlap with the time periods of any of its tracked MCCAOP reservations." -- but the section on EDCA doesn't describe
how to do it.
|
This was CID 5144 on D4.0. 15/1250r3 was prepared with proposed resolution. The resolution depends upon other changes which had not been agreed upon. Hence this propasal was pu tto one
side. 15/1250 will be updated to reference D5.0 and re-presented.
|
MAC
|
MAC Operation
|
|
Smith, Graham
|
7137
|
624.54
|
9.3.3.3
|
DSSS Parameter Set clearly indicates the channel number only in 2.4GHz band only, but in practice it is used to indicate 5GHz channels.
|
Remove 2.4GHz only reference where appropriate and change name. Submitter will submit proposal
|
MAC
|
Frame Formats
|
|
Stephens, Adrian
|
7007
|
880.51
|
9.4.2.46
|
"may" in clause 8
|
If intended to define normative behavior, move to Clause 10.Otherwise, reword to avoid "may" here.
|
MAC
|
Frame Formats
|
|
Stephens, Adrian
|
7008
|
895.27
|
9.4.2.56.4
|
Normative "may" in the "condition" column
|
Move behavior to Clause 10, or reword to avoid "may".
|
MAC
|
Frame Formats
|
|
Stephens, Adrian
|
7022
|
973.46
|
9.4.2.93
|
" The Query Response Length Limit may be set to a value larger than the maximum" - normative statement in Clause 9.Ditto issue at line 61.
|
Reword to avoid normative language, or move to Clause 10/11.
|
MAC
|
Frame Formats
|
|
Stephens, Adrian
|
7034
|
1111.23
|
9.6.2.6
|
"It may be present when switching to a20 MHz channel (in which case the Secondary Channel Offset field is set to SCN)." - normative verb in Clause 9.
|
If this is already described in Clause 10/11, change "may" to "can" and add a reference to the behavior here. Otherwise, move this into Clause 10/11 somewhere.
|
MAC
|
Frame Formats
|
|
Stephens, Adrian
|
7046
|
577.19
|
9.2.4.5.2
|
"The requirement to respond to that TID is nonbinding, and a STA may respond with any frame." - normative verb in Clause 9.
|
Either move to Clause 10/11, or change to non-normative and reference clause defining the behavior.
|
MAC
|
Frame Formats
|
|
Stephens, Adrian
|
7049
|
579.28
|
9.2.4.5.6
|
" A queue size value of 255 is used to indicate an unspecified or unknownsize. If a QoS Data frame is fragmented, the queue size value may remain constant in all fragments even ifthe
amount of queued traffic changes assuccessive fragments are transmitted." - normative verb in Clause 9
|
I am unclear whether this is the only instance defining this behavior.If so, move to Clause 10/11. If not, can "may" to "can" and cite subclause defining this behavior.
|
MAC
|
Frame Formats
|
|
Stephens, Adrian
|
7062
|
832.37
|
9.4.2.25.3
|
"a single AKM suite selector may be specified because IBSS STAs use the same AKM suite" - normative verb in clause 9.It is unclear as to whether this is granting permission.
|
If normative behaviour is present elsewhere, cite it here and change "may" to "can" and add reference to subclause defining the behaviour. Otherwise move this to a behavioural clause.
|
MAC
|
Frame Formats
|
|
Stephens, Adrian
|
7066
|
847.31
|
9.4.2.30
|
"A DMG STA that responds with an ADDTSResponse frame and an HC may change the value of parameters that have been set unspecified by the STAto any value that it deems appropriate, including
leaving them unspecified." -- normative verb in clause 9
|
Change "may" to "can". And either cite subclause that permits this behaviour, or add this behavioural description to clause 10/11 and cite it here.
|
MAC
|
Frame Formats
|
|
Stephens, Adrian
|
7069
|
854.62
|
9.4.2.31
|
" An incoming MSDU that is not classified to a particular TS may be classified to another active TS based on the frame classifier for that TS." - normative verb in clause 9
|
Move normative behaviour to clause 10/11.
|
MAC
|
Frame Formats
|
|
Stephens, Adrian
|
7074
|
586.05
|
9.2.4.6.2
|
" all or part of an MSDU or A-MSDU should discard the MSDU or any MSDUs containedwithin the A-MSDU in preference toMSDUs carried in MPDUs whose DEI subfield is equal to 0." - this is
clearly behaviour, and doesn't belong in Clause 9.
|
Move to Clause 10
|
MAC
|
Frame Formats
|
|
Stephens, Adrian
|
7075
|
738.44
|
9.4.2.10
|
"The Requested Element IDs within a Request element transmitted in a Probe Request frame should notinclude an element ID that corresponds to an element that will be included in the Probe
Response frame" - this is behaviour, not frame format, and doesn't belong in Clause 9.
|
Move to Clause 10/11
|
MAC
|
Frame Formats
|
|
Stephens, Adrian
|
7077
|
1004.45
|
9.4.2.121
|
" If there are insufficient resources, a STA should discard theMSDUs or A-MSDUs of a TS with a Drop Eligibilitysubfield equal to 1," - this is not frame format. Should not be in clause
9.
|
Move to Clause 10/11.
|
MAC
|
Frame Formats
|
|
Stephens, Adrian
|
7092
|
1050.1
|
9.4.2.158.2
|
The definition contradicts the encoding for the case of TVHT.Same comment at 1050.18
|
Update the definition to include the meaning for the TVHT STA.
|
MAC
|
Frame Formats
|
|
Stephens, Adrian
|
7093
|
1053.52
|
9.4.2.158.2
|
The insertion here makes a special case out of the Extended NSS BW Support field and Supported Channel Width Set fields. All the other fields are fully defined the table 9-245.
|
Move this text into Table 9-245 against definition of one or more of these fields.
|
MAC
|
Frame Formats
|
|
Stephens, Adrian
|
7095
|
1314.06
|
10.7.6.1
|
"In these cases" follows a list of conditions followed by an otherwise. So the list always applies. So "these cases" equates to always.This is probably not the intent of the note.
|
Clarify in the note exactly which cases are relevant, or delete the note.
|
MAC
|
MAC Operation
|
|
Stephens, Adrian
|
7097
|
1541.3
|
10.38.7
|
"initiator may consider the beam tracking request as failed." - what is the normative effect of "may consider"?
|
Reword to explain effect on observable behaviour of STA
|
MAC
|
MAC Operation
|
|
Stephens, Adrian
|
7106
|
2330.39
|
19.2.5
|
"the MAC shall set the CH_BANDWIDTH" - this is a normative requirement on the MAC buried in the guts of a PHY subclause.Ditto at 2504.27
|
Move this normative requirement to a MAC subclause.
|
GEN
|
MAC Operation
|
|
Stephens, Adrian
|
7107
|
2500.31
|
21.2.4
|
This table references "BSS bandwidth" in multiple places. But the PHY knows nothing about this, as it is a purely MAC concept. The normative statement cited here is therefore impossible
to achieve in the 802.11 architecture.Ditto comment in Table 22-2.
|
Either provide add PHY SAP primitive parameters for the MAC to tell it about the BSS bandwidth, or reword the normative requirements to relate to some other parameter/MIB variable to
which it does have access.
|
GEN
|
MAC Operation
|
|
Stephens, Adrian
|
7111
|
3055.15
|
C.3
|
Regarding dot11LCIAltitude: With the merging of the fraction and integer parts during working group ballot comment resolution, no change was made to the size or range of this variable.
i.e., it no longer necessarily reflect the full range of values possible in the related structures. Also the description citing the "fixed-point" part might be wrong.
|
Adjust at least the range on line 15/16 to reflect the range in Clause 9. Review the other variables in the LCI structure (dot11LCI*) and ensure that the range and description matches
the structure.
|
GEN
|
MAC Operation
|
|
Stephens, Adrian
|
7112
|
|
C
|
There are >50 "shall" statements in the "Description" clauses of the MIB.I believe that the MIB descriptive text is an unsuitable place to lodge normative requirements.
|
Move any "shall" statements on 802.11 components into the text describing the behaviour of that component.For each "shall" statement addressed to the MIB client, reword to describe what
the STA will accept, and what it will do if unacceptable input is provided.
|
GEN
|
MIB
|
|
Stephens, Adrian
|
7113
|
3617.4
|
R.7
|
The equations starting at the cited location do not follow IEEE-SA equation style very closely. There is inconsistency between underscore and subscripting. The showing of units in equations
is not done elsewhere in this standard.
|
Rework equations to bring closer to IEEE-SA style and to others in the Standard. Specifically: remove any units embedded in the equations, use "underscore" versus subscripts consistently,
and certainly when referring to the same variable. Use shorter variable names, and put the explanation of what they represent into the variable list.
|
EDITOR
|
Editorials
|
|
Stephens, Adrian
|
7114
|
3618.45
|
R.7
|
The units of RSSI and P_adjust are not specified.Note, a separate comment has been submitted on the editorial style of these equations.
|
Specify them.
|
MAC
|
MAC Operation
|
|
Stephens, Adrian
|
7131
|
3581.57
|
N.2
|
"A STA can also form an integral part of an AP". I thought an AP always contained a STA, otherwise we would have to change all statements of the form "A STA that receives an RTS shall
sent a CTS" to say "An AP or STA that receives...". I'm sure we don't want to do that work.
|
Replace "ACM_STA" by "AP" throughout Annex N, and delete the para at line 57.
|
MAC
|
MAC Operation
|
|
Stephens, Adrian
|
7146
|
134.1
|
5.1.5.1
|
A role-specific behaviour is not shown for a DMG relay.If security on a DMG relay is established for each leg of the relay, then the data-flow must pass through the controlled port, and
therefore be shown in the role-specific behaviour.
|
Determine whether to show a role-specific behaviour for a DMG relay, which would be similar to a mesh STA.
|
MAC
|
Architecture
|
|
Stephens, Adrian
|
7150
|
3581.01
|
Annex N
|
Annex N contains terminology that is unique to itself, such as WLAN system and ACM_STA. The understanding of what a DS is has developed and change in the ARC standing committee, resulting
in changes to Clause 5. Annex N has been ignored.
|
Review Annex N and change terminology and architecture to conform to the normative portions of the draft.
|
MAC
|
Architecture
|
|
TorabJahromi, Payam
|
7171
|
649.18
|
9.3.4.2
|
DMG Wakeup Schedule element (Order number 16) needs a brief introduction note.
|
Add the following note for the element: "The DMG Wakeup Schedule element is optionally present. If present, the element carries the wakeup schedule of a DMG STA. See 11.2.6 (Power management
in a PBSS and DMG infrastructure BSS)."
|
MAC
|
Frame Formats
|
|
TorabJahromi, Payam
|
7172
|
2448.08
|
20.5
|
The optional DMG OFDM mode has serious design flaws and has not been productized by any of the 60 GHz silicon vendors to the best of my knowledge. Some of the flaws: (1) DMG OFDM PHY
header is transmitted in OFDM, which makes it not decodable to Single Carrier only (SC-only) DMG devices, creating serious co-existence issues. (2) DMG OFDM subcarriers are defined such that when two channels are bonded the subcarriers for the wide channel
will not fall on a uniform frequency grid for FFT. It is anticipated that the 11ay standard will define a 60 GHz OFDM mode that will include a single-channel operation, effectively replacing the 11ad OFDM.
|
Remove the DMG OFDM mode and all parameters and references to DMG OFDM mode.
|
GEN
|
DMG PHY
|
|
TorabJahromi, Payam
|
7173
|
2471.01
|
20.7.2.2
|
DMG LPSC mode PHY header is transmitted using Reed-Solomon coding, which makes it not decodable to Single Carrier only (SC-only) DMG devices, creating serious coexistence issues. DMG
LPSC mode has not been productized to the best of my knowledge and a it is defined to day will interfere with SC-only devices that will ship in very large quantities.
|
Transmit the LPSC PHY header using SC modulation and coding; text will be provided.
|
GEN
|
DMG PHY
|
|
TorabJahromi, Payam
|
7174
|
2474.45
|
20.7.2.3.5
|
A-PPDU aggrergation is not defined for DMG low-power SC mode (how adjacent PPDUs are transmitted is undefined)
|
Text will be provided to define A-PPDU aggregation for low-power SC mode.
|
GEN
|
DMG PHY
|
|
TorabJahromi, Payam
|
7175
|
2471.01
|
20.7.2.2
|
DMG LPSC mode PHY header is transmitted using Reed-Solomon coding, which makes it not decodable to Single Carrier only (SC-only) DMG devices, creating serious coexistence issues. DMG
LPSC mode has not been productized to the best of my knowledge and a it is defined to day will interfere with SC-only devices that will ship in very large quantities.
|
Transmit the LPSC PHY header using SC modulation and coding; text will be provided.
|
GEN
|
DMG PHY
|
|
Trainin, Solomon
|
7148
|
1608.31
|
11.2.6.2.1
|
Figure 11-9--State transition diagram of non-AP and non-PCP STA in active and PS modes is not compliant with definition provided in sub-clauses 11.2.6.2.2 Non-AP and non-PCP STA operation
without a wakeup schedule and 11.2.6.2.3 Non-AP and non-PCP STA operation with a wakeup schedule
|
Replace the figure with drawing provided in 11-16-0158-00-000m-Power-Management-State-Transition-Diagram
|
MAC
|
MAC Management
|
|
Trainin, Solomon
|
7149
|
1612.3
|
11.2.6.3.3
|
Figure 11-10--State transition diagram of PCP power management mode does not fit to definitions provided in 11.2.6.3.3 PCP operation with a wakeup schedule and does not reflect definition
in 11.2.6.3.2 PCP operation without a wakeup schedule
|
Replace the figure with figure provided in 11-16-0158-00-000m-Power-Management-State-Transition-Diagram
|
MAC
|
MAC Management
|
|
Trainin, Solomon
|
7152
|
2075.11
|
13.5.2
|
Authentication frame is not supported in DMG. This frame is broadly used in FT protocol and FT resource request protocol. As result current version of FT is not applicable for DMG. Additional
relevant places are. in 13.5.4 Over-the-air FT protocol authentication in a non-RSN P2078 L58, 13.6.2 Over-the-air fast BSS transition with resource request P2080 L36, P2082L34
|
Use another frame - FT Request frame that is applicable for DMG to deliver FT information in the over-the-air FT protocol and in the Over-the-air FT resource request protocol
|
GEN
|
Security
|
|
Trainin, Solomon
|
7153
|
1010.44
|
9.4.2.128.1
|
Negotiation of Max Number Of MSDUs In AMSDU as part of STA capabilities makes a lot of sense to DMG STA. In the current definition the Max Number Of MSDUs In AMSDU capability is not applicable
for DMG STA's
|
Extend DMG Capabilities element to convey DMG Max Number Of MSDUs In AMSDU capability subfield with four values encoded 32, 16, 8, and 4
|
MAC
|
Frame Formats
|
|
Trainin, Solomon
|
7165
|
1576.33
|
11.2.2.5.1
|
U-APSD mechanism provides fine granularity of power management for non-AP STA that is not provided by any power management mechanism in DMG network.
|
Provide changes to the U-APSD definitions that makes it applicable for DMG networks
|
MAC
|
MAC Management
|
|
Wang, Lei
|
7166
|
1050.49
|
9.4.2.158.2
|
The meaning of the "Beamformee STS Capability" field was changed during the comment resolution of 11mc/D4.0 sponsor ballot based on comment CID 5879, regarding decoupling MU Beamformee
Sounding capability from MU PPDU reception capability. During the discussions in the 11mc group, concerns have bee raised about the AP side processing issue for the beamforming matrix for the data with more streams (say 8 streams) than the training streams
done with the STA (say 4 streams), when using NDP frame with less number streams than MU PPDU.In addition, the original description is technically correct, nothing needs to be fixed. That is, the changes proposed by CID 5879 resolution do not belong to technical
corrections, as for 11mc project.
|
Change the definition box for " "Beamformee STS Capability" field back to 11mc/D4.0, i.e., to the following:The maximum number of space-time streams that the STA can receive in a VHT
NDP, themaximum value for NSTS,total that can be sent to the STA in a VHT MU PPDU if the STA isMU beamformee capable, and the maximum value of Nr that the STA transmits in a VHTCompressed Beamforming frame.
|
MAC
|
Frame Formats
|
|
Wang, Lei
|
7167
|
1054.01
|
9.4.2.158.3
|
The 3-bit field (Bit 29 to Bit 31) was changed from Reserved to "Maximum NSTS,total" during the comment resolution of 11mc/D4.0 sponsor ballot based on comment CID 5879, regarding decoupling
MU Beamformee Sounding capability from MU PPDU reception capability. During the discussions in the 11mc group, concerns have bee raised about the AP side processing issue for the beamforming matrix for the data with more streams (say 8 streams) than the training
streams done with the STA (say 4 streams), when using NDP frame with less number streams than MU PPDU.In addition, the original description is technically correct, nothing needs to be fixed. That is, the changes proposed by CID 5879 resolution do not belong
to technical corrections, as for 11mc project.
|
Make the following chnages:1. line 1 on page 1054, Change Bit 29 to Bit 31 back to Reserved in Figure 9-559--Supported VHT-MCS and NSS Set field2. line 33 on page 1055, delete the row
"Maximum NSTS,total" in Table 9-247--Supported VHT-MCS and NSS Set subfields
|
MAC
|
Frame Formats
|
|
Wang, Lei
|
7168
|
1462.09
|
10.34.5.2
|
The paragraph in line 9 to 13 on page 1462 was changed during the comment resolution of 11mc/D4.0 sponsor ballot based on comment CID 5879, regarding decoupling MU Beamformee Sounding
capability from MU PPDU reception capability. During the discussions in the 11mc group, concerns have bee raised about the AP side processing issue for the beamforming matrix for the data with more streams (say 8 streams) than the training streams done with
the STA (say 4 streams), when using NDP frame with less number streams than MU PPDU.In addition, the original description is technically correct, nothing needs to be fixed. That is, the changes proposed by CID 5879 resolution do not belong to technical corrections,
as for 11mc project.
|
Change the parapgraph in line 9 to 13 on page 1462 back to 11mc/D4.0 version, i.e., to the following:A VHT beamformee shall indicate the maximum number of space-time streams it can receive
in a VHT NDP in the Beamformee STS Capability field. If the beamformee is a non-AP STA, this shall also be the maximum total number of space-time streams that the STA can receive in a VHT MU PPDU.
|
MAC
|
MAC Operation
|
|
Wang, Lei
|
7169
|
2574.47
|
21.3.11.3
|
The paragraph in line 47 to 50 on page 2574 was changed during the comment resolution of 11mc/D4.0 sponsor ballot based on comment CID 5879, regarding decoupling MU Beamformee Sounding
capability from MU PPDU reception capability. During the discussions in the 11mc group, concerns have bee raised about the AP side processing issue for the beamforming matrix for the data with more streams (say 8 streams) than the training streams done with
the STA (say 4 streams), when using NDP frame with less number streams than MU PPDU.In addition, the original description is technically correct, nothing needs to be fixed. That is, the changes proposed by CID 5879 resolution do not belong to technical corrections,
as for 11mc project.
|
Change the parapgraph in line 47 to 50 on page 2574 back to 11mc/D4.0 version, i.e., to the following:An MU-capable STA shall support reception of VHT MU PPDUs with the total number of
space-time streams across the N_user users being less than or equal to its Beamformee STS Capability in the VHT Capabilities Info field.
|
GEN
|
VHT PHY
|
|
Wentink, Menzo
|
7141
|
1057.01
|
9.4.2.159
|
Many 80 MHz capable VHT devices in the field do not correctly parse 160 or 80+80 MHz BSS channel widths. The issues vary from no association, repeated reassociation, association at 20
or 40 MHz, etc. More details are available in document 11-16-xxxx-00-000m-160-and-80+80-mhz-channel-width-signaling.
|
Adopt the text changes as proposed in 11-15-1530-03-000m-vht160-operation-signaling-through-non-0-ccfs1.
|
MAC
|
Frame Formats
|