|
Adrian Stephens
|
7062
|
1001
|
Stephens, Adrian
|
G
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Adrian Stephens
|
7074
|
1001
|
Stephens, Adrian
|
G
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Adrian Stephens
|
7075
|
1001
|
Stephens, Adrian
|
G
|
Y
|
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
|
Submission Required
|
MAC: 2016-02-23 19:19:39Z - Adrian will work on this, to turn it into a NOTE, per Straw Poll results at F2F, Feb 23.
Starting suggestion: For CID 7075 how about:
NOTE---Although this is not useful, some implementations might include an element ID that corresponds to an element that will be included in the Probe Response frame even in the absence of the Request element, or will be excluded from the Probe Response frame
even in the presence of the Request element as described by the notes in Table 9-34 (Probe Response frame body).
(I am not sure why there isn't a comma before "as described")
Clarity/consistency (Med scope)
|
Assigned
|
|
Adrian Stephens
|
7077
|
1001
|
Stephens, Adrian
|
G
|
Y
|
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
|
Submission Required
|
EDITOR: 2016-02-04 15:50:44Z - I agree the text should not be here. I reviewed uses of "Drop Eligibility" and there does not appear to be any statement about how to use this field, except
in certain conditions (e.g. EDCAF collision), to choose to drop an MSDU. Needs an expert. Suggest Ganesh. Transferring to MAC.
|
Assigned
|
|
Adrian Stephens
|
7099
|
1001
|
Stephens, Adrian
|
T
|
Y
|
1704.14
|
11.11.10.1
|
"shall not transmit a FTM Range Request" -- there is no such thing as an FTM Range Request
|
Replace with something that does exist, or delete cited sentence.
|
MAC
|
|
Bugfix
|
Assigned
|
|
Adrian Stephens
|
7103
|
1001
|
Stephens, Adrian
|
T
|
Y
|
1883.25
|
11.43
|
"B0-B1 (BW) in TVHT-SIG-A1"- the MAC has no knowledge of the contents of particular signal fields in the PHY (rightly so).
|
Reword so that this refers only to TXVECTOR/RXVECTOR parameters.
|
EDITOR
|
|
Editorial
|
Assigned
|
|
Adrian Stephens
|
7106
|
1001
|
Stephens, Adrian
|
T
|
Y
|
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
|
Submission Required
|
GEN: 2016-02-23 19:49:41Z
Proposed Resolution: REVISED (GEN: 2016-02-23 19:43:24Z) Insert the following new subclause at 1344.23:
"10.19a Transmission of NON_HT formats by an HT STA that is not a VHT STA
In order to transmit a non-HT PPDU, an HT STA that is not a VHT STA sets the CH_BANDWIDTH and CH_OFFSET in the TXVECTOR to achieve the required non-HT PPDU format (see Table 19-2 (PPDU format as a function of CH_BANDWIDTH and CH_OFFSET parameters)).
For 20 MHz bandwidth transmissions in a 40 MHz channel the STA shall set the CH_OFFSET parameter to CH_OFF_20U if the SECONDARY_CHANNEL_OFFSET parameter of the PHYCONFIG_VECTOR was SECONDARY_CHANNEL_ABOVE, or CH_OFF_20L otherwise."
Delete the Para at 2330.39
There may be two more locations – what about 2506.9, 2504.27? – Check for related comments –
There are also CIDs 7135, 7404, 7405, and 7408 that should include in discussion. When it comes up tomorrow.
- Clarity/consistency (Med scope)
|
Assigned
|
|
Adrian Stephens
|
7107
|
1001
|
Stephens, Adrian
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Adrian Stephens
|
7119
|
1001
|
Stephens, Adrian
|
T
|
Y
|
1071.19
|
9.4.2.172
|
Either the "N x 3" is wrong, or the field doesn't contain the structure as described.
|
Either change "N x 3" to "3", or change in the name of the field e.g. to "ESP Information List" and add a new para at line 26 "The ESP Information list contains one or more ESP Information
fields."
|
MAC
|
|
Bugfix
|
Assigned
|
|
Adrian Stephens
|
7121
|
1001
|
Stephens, Adrian
|
T
|
Y
|
1346.53
|
10.21.4
|
"When communicating with a STA that supports global operating classes" - this is an informal condition in a normative statement.
|
Replace informal condition with condition based on observables.
|
MAC
|
Submission Required
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Adrian Stephens
|
7398
|
1001
|
RISON, Mark
|
T
|
Y
|
1335.31
|
10.11
|
"A STA that participates in a successful ADDTS exchange that included a U-PID element with the No-LLC field equal to 1 shall strip the LLC header from an MSDU corresponding to the TID
indicated in the ADDTS exchange before transmission of the MSDU" -- how, exactly? Specifically, does the STA check that the expected LLC header is present, or blindly strip the first n octets from the MSDU?
|
Add a statement that the STA just strips the first n octets from the MSDU without any checking
|
MAC
|
|
Bugfix
|
Assigned
|
|
Adrian Stephens
|
7411
|
1001
|
RISON, Mark
|
T
|
Y
|
2504.51
|
21.2.5.2
|
"PHY-TXSTART.request(TXVECTOR) primitive is issued" -- to what? There is no OFDM PHY
|
Use "as if" wording, as above
|
EDITOR
|
|
EDITOR: 2016-02-25 14:25:24Z - Check against 7412 for consistency.
EDITOR: 2016-02-25 14:24:42Z - Previous resolution: "REVISED (EDITOR: 2016-02-25 09:50:20Z) - At 2504.51 insert “PHY operates as if a” before “Clause 17”. At 2504.52 change “is” to “was”."
|
Assigned
|
|
Adrian Stephens
|
7481
|
1001
|
RISON, Mark
|
T
|
Y
|
1253.54
|
9.7.3
|
There is also a restriction on A-MSDUs sent in a pre-HT PPDU
|
Change the first sentence of the NOTE 3 to "If a STA supports A-MSDUs of 7935 octets (indicated by the Maximum A-MSDU Length field in the HT Capabilities element), A-MSDUs transmitted
by that STA within an A-MPDU carried in a PPDU with FORMAT HT_MF or HT_GF or within an MPDU carried in a non-HT PPDU are constrained so that the length of the QoS Data frame carrying the A-MSDU is no more than 4095 octets. "
|
MAC
|
|
Bugfix
|
Assigned
|
|
Adrian Stephens
|
7494
|
1001
|
RISON, Mark
|
T
|
Y
|
1076.07
|
9.4.4.2.2
|
The DII field can only contain one TLV ("Single value TLV comprising fields in related table in E.2"). But what if you need to pass more than one TLV (e.g. both an FCC ID and a Device
Serial Number in the USA, per Table E-8 Device Identification Information Value fields)?
|
Delete "Single value"
|
MAC
|
|
Bugfix
|
Assigned
|
|
Adrian Stephens
|
7511
|
1001
|
RISON, Mark
|
T
|
Y
|
836.1
|
9.4.2.25.4
|
It says "A STA sets the GTKSA Replay Counter subfield of the RSN Capabilities field to the value contained in dot11RSNAConfigNumberOfPTKSAReplayCounters."
|
Change "PTKSA" to "GTKSA"
|
MAC
|
|
Bugfix
|
Assigned
|
|
Adrian Stephens
|
7533
|
1001
|
RISON, Mark
|
T
|
Y
|
1002.07
|
9.4.2.118
|
"the bit string of {GTK || Key RSC ||GTKExpirationTime}" -- what is the format of the GTK as an octet string?
|
Define the format (as is done for the other two)
|
MAC
|
|
Bugfix
|
Assigned
|
|
Adrian Stephens
|
7539
|
1001
|
RISON, Mark
|
T
|
Y
|
1285.01
|
10.3.2.12.3
|
RR1 and RR3 in Table 10-4---Receiver Caches restrict the rules to non-DMG STAs, but there is otherwise no mention of this in the actual RC rows
|
Add non-DMG to the corresponding rows
|
MAC
|
|
Bugfix
|
Assigned
|
|
Adrian Stephens
|
7543
|
1001
|
RISON, Mark
|
T
|
Y
|
3615.18
|
R.5.3
|
" an AP Advertisement location capability does not return an "incapable" response if the non-AP STA requests the "remote" location." makes no sense?
|
Change to something like "an AP avertising location capability does not return an "incapable" response if the non-AP STA requests the "remote" location."
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Adrian Stephens
|
7560
|
1001
|
RISON, Mark
|
T
|
Y
|
1261.58
|
10.2.4.2
|
This NOTE should be promoted to normative, since it is not otherwise obvious that the Retry bit is not to be set. Also need to be clear it is set, though, if had been previously transmitted
(except if this was done under BA (except if in a DMG BSS))
|
As it says in the comment
|
MAC
|
|
Bugfix
|
Assigned
|
|
Adrian Stephens
|
7648
|
1001
|
RISON, Mark
|
T
|
Y
|
838.31
|
9.4.2.27
|
Re CID 6476: why is the bit set to 0 when sent in a non-AP STA's beacon, even if it it supports PSMP (and indicates so when it sends a probe response)? This seems very odd (and would
leave a device which does passive scanning with the wrong understanding)
|
Change the rightmost cell to just the last two of the current lines
|
MAC
|
|
Bugfix
|
Assigned
|
|
Adrian Stephens
|
7672
|
1001
|
RISON, Mark
|
T
|
Y
|
715.42
|
9.4.1.53
|
"If the Rx NSS Type subfield is 1, the value of this field, combined with other information described in 9.4.2.158.3 (Supported VHT-MCS and NSS Set field), indicates the maximum number
of spatial streams that the STA can receive as a beamformee in an SU PPDU" -- I see nothing in there that deals with BF
|
Delete ", combined with other information described in 9.4.2.158.3 (Supported VHT-MCS and NSS Set field), "
|
MAC
|
|
Bugfix
|
Assigned
|
|
Adrian Stephens
|
7685
|
1001
|
RISON, Mark
|
E
|
Y
|
1055.12
|
9.4.2.159
|
It says "The maximum value of theRXVECTOR parameter MCSof a PPDU"
|
Change to "This parameter"
|
EDITOR
|
|
EDITOR: 2016-02-22 19:21:51Z - Make similar to the change to the TXVECTOR changes.
EDITOR: 2016-02-05 11:11:37Z - Changed to "Frame Formats" and request review. See also CID 7686.
|
Assigned
|
|
Adrian Stephens
|
7687
|
1001
|
RISON, Mark
|
T
|
Y
|
1053.3
|
9.4.2.158
|
"The value of Max VHT NSS is equal to the smaller of:" -- but this value is MCS-dependent
|
Change to "The value of Max VHT NSS for a given MCS is equal to the smaller of:"
|
MAC
|
|
Bugfix
|
Assigned
|
|
Adrian Stephens
|
7691
|
1001
|
RISON, Mark
|
T
|
Y
|
1328.16
|
10.7.12.1
|
It says "except that if thevalue of dot11VHTExtendedNSSBWCapable of the second STA is false, the supported bandwidthvalues and NSS values of each tuple are updated according to Table
10-8(Interpretation of the Supported Channel Width Set and Extended NSS BW Support subfield of theVHT Capabilities Information field and the Channel Width field of the Operating Mode field at areceiving STA with a value of false for dot11VHTExtendedNSSBWCapable)
and" -- but if extended NSS capable is false, then you don't need to update anything
|
Change to "except that". Ditto next bullet
|
MAC
|
|
Bugfix
|
Assigned
|
|
Adrian Stephens
|
7694
|
1001
|
RISON, Mark
|
T
|
Y
|
1330.44
|
10.7.12.2
|
It says "except that if thevalue of dot11VHTExtendedNSSBWCapable of the second STA is false, the supported bandwidthvalues and NSS values of each tuple are updated according to Table
10-8(Interpretation of the Supported Channel Width Set and Extended NSS BW Support subfield of theVHT Capabilities Information field and the Channel Width field of the Operating Mode field at areceiving STA with a value of false for dot11VHTExtendedNSSBWCapable)
and" -- but if extended NSS capable is false, then you don't need to update anything
|
Change to "except that". Ditto next bullet
|
MAC
|
|
Bugfix
|
Assigned
|
|
Adrian Stephens
|
7742
|
1001
|
RISON, Mark
|
T
|
Y
|
1767.06
|
11.24.6.3
|
"The responding STA's selection of the Number of Bursts Exponent value shall be 0 when the initiating STA requests it to be 0." should be a "should". An AP is required to support non-ASAP
since a STA is not required to be ASAP-capable. ASAP=1 can be problematic for scheduling.
|
I think this came in the context of a discussion with Carlos ALDANA, so I hope he can work out what this was about!
|
MAC
|
|
Bugfix
|
Assigned
|
|
Adrian Stephens
|
7743
|
1001
|
RISON, Mark
|
T
|
Y
|
1074.27
|
9.4.3
|
"A subelement that is not defined as extensible will not be extended in future revisions or amendments of thisstandard." -- what if it's marked a Yes, could it become Subelements? Or
vice-versa?
|
Add "A subelement that is defined as extensible might become subelement-extended in future revisions or amendments of thisstandard. A subelement that is defined as subelement-extensible
will remain so in future revisions or amendments of thisstandard."
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Adrian Stephens
|
7750
|
1001
|
RISON, Mark
|
E
|
Y
|
880.1
|
9.4.2.45
|
There are 4 instances of "capability enabled"
|
Change at least the first 3 to "Capability Enabled". I'm not sure what " STAs that have the Beacon request capability enabled" in 11.28.1 is referring to
|
MAC
|
|
The following instruction fixes the capitalization: 'Intial cap this term at 880.10, 880.08, 1761.53.'.
However, it doesn't address the text at 1829.57, which appears to be technically inadequate. Needs MAC input.
|
Assigned
|
|
Adrian Stephens
|
7755
|
1001
|
RISON, Mark
|
T
|
Y
|
1355.53
|
10.22.2.7
|
"A frame exchange may be one of the following:" -- but a frame exchange, or at least a frame exchange sequence, is more than the things indicated (see Annex G)
|
Add ", in the context of multiple frame transmission in an EDCA TXOP"
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Adrian Stephens
|
7770
|
1001
|
RISON, Mark
|
T
|
Y
|
615.36
|
9.3.1.20
|
It says "If the VHT NDP Announcement frame contains only one STA Info field, then the RA field is set to the address of the STA identified by the AID in the STA Info field.", but the
AID in the STA Info field cannot identify a STA, if that STA is in fact an AP or a mesh STA or an IBSS STA. Also, there's no AID in the STA Info field
|
Change to "If the VHT NDP Announcement frame contains only one STA Info field and the frame is directed to a non-AP STA in an infrastructure BSS, then the RA field is set to the address
of the STA identified by the AID12 subfield in the STA Info field."
|
MAC
|
|
Bugfix
|
Assigned
|
|
Adrian Stephens
|
7774
|
1001
|
RISON, Mark
|
T
|
Y
|
1240.19
|
9.6.21.2
|
"One or more elements are present in this frame" -- these are already covered above
|
Delete this row
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Adrian Stephens
|
7775
|
1001
|
RISON, Mark
|
T
|
Y
|
649.22
|
9.3.4.2
|
"One or more elements can appear in this frame" -- these are already covered above
|
Delete this row
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Adrian Stephens
|
7776
|
1001
|
RISON, Mark
|
T
|
Y
|
1241.24
|
9.6.21.3
|
"One or more elements can appear in this frame" -- these are already covered above
|
Delete this row
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Adrian Stephens
|
7777
|
1001
|
RISON, Mark
|
T
|
Y
|
1226.34
|
9.6.20.4
|
"Each provided element is an element as specified in 8.4.2 (Elements), that the transmitter of this frame is providing to the destination of the frame." is vacuous and fails to specify
their nature and order
|
Delete this para and row 6 in the table above
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Adrian Stephens
|
7778
|
1001
|
RISON, Mark
|
T
|
Y
|
1227.24
|
9.6.20.5
|
"The provided elements are elements, as described in 8.4.2 (Elements), that the transmitter of this frame is providing to the destination of the frame." is vacuous and fails to specify
their nature and order
|
Delete this para and row 6 in the table above
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Adrian Stephens
|
7783
|
1001
|
RISON, Mark
|
T
|
Y
|
1720.01
|
11.14
|
Since SA Query frames are robust, and receipt of any protected frame will do for SA Query, SA Query frames don't need a transaction identifier
|
Delete " and with a matching TransactionIdentifier" at 1625.6 and 1629.16Delete " with a TransactionIdentifier matching aTransactionIdentifier in an MLME-SA-QUERY.request issued in this
SA Query procedure" at 1625.12 and 1629.22Delete " that has a matching transaction identifier" at 1720.1
|
MAC
|
|
Bugfix
|
Assigned
|
|
Adrian Stephens
|
7828
|
1001
|
Hamilton, Mark
|
T
|
Y
|
649.22
|
9.3.4.2
|
In Table 9-41--DMG Beacon frame body, the "last - 1" entry is underspecified. What elements are allowed/supported/expected in a DMG Beacon? Anything?
|
List explicitly, or at least describe, the elements that are expected to be included at this point in the order.
|
MAC
|
|
Bugfix
|
Assigned
|
|
Assaf KASHER
|
7142
|
1001
|
Kasher, Assaf
|
T
|
N
|
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
|
Submission Required
|
New feature
|
Assigned
|
|
Brian Hart
|
7444
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Brian Hart
|
7523
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Brian Hart
|
7563
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Carlos Aldana
|
7276
|
1001
|
RISON, Mark
|
T
|
Y
|
1772.29
|
11.24.6.4
|
An RTT is the time between a signal going out and coming back. It includes any processing time at the other side. The spec uses "RTT" to mean the total time of flight, not the RTT
|
Delete the RTT definition from 3.4 and instead add "TOF time of flight"At 83.58 change "round trip time (RTT)" to "distance"At 1771.20 change "an RTT" to "a two-way TOF"At 1772.28 change
"The round trip time (RTT)" to "The two-way TOF" and change "RTT" to "TOF" in the equationAt 3598.21 change "RTT" to "two-way TOF"
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Carlos Aldana
|
7277
|
1001
|
RISON, Mark
|
T
|
Y
|
1771.2
|
11.24.6.4
|
What does "or clock estimate" mean?
|
Delete NOTE 2
|
MAC
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Carlos Aldana
|
7442
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Carlos Aldana
|
7504
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Carlos Cordeiro
|
7209
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Carlos Cordeiro
|
7626
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Carlos Cordeiro
|
7787
|
1001
|
RISON, Mark
|
T
|
Y
|
1488.31
|
10.36
|
The material related to DMG has a lot of "TXTIME"s without an indication of the PHY parameters (especially the MCS) to be used to determine this. Without this information the "TXTIME"s
are meaningless
|
Add an indication of the PHY parameters (especially the MCS) to be assumed when TXTIME(frame) is mentioned in the context of DMG (and anything else which might suffer from the same problem)
|
MAC
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Dan Harkins
|
7350
|
1001
|
RISON, Mark
|
E
|
Y
|
|
|
Misuse of "sequence number" in the context of PNs/TSCs (rather than the MPDU SN)
|
At 1002.10 and 2018.45 change "[The] Key RSCdenotes the last frame sequence number sent using the GTK" to "[The] Key RSC denotes the last TSC or PN sent using the GTK"At 2011.52 change
"Key RSC = For PTK generation, starting sequence number" to "Key RSC = For PTK generation, starting TSC or PN"At 2019.32 change "Key RSC = last transmit sequence number for the GTK" to "Key RSC = last TSC or PN for the GTK"Ar 2021.29 change " the last sequence
number used with the GTK (RSC)" to " the last TSC or PN used with the GTK (RSC)"1930.42, 1931.47 are also suspect
|
GEN
|
|
EDITOR: 2016-02-09 14:44:48Z - Misuse of a term is not an editorial error. Changed to GEN/Security.
|
Assigned
|
|
Dan Harkins
|
7510
|
1001
|
RISON, Mark
|
T
|
Y
|
2875.55
|
C.3
|
dot11RSNAConfigNumberOfSTKSAReplayCountersImplemented is not used outside the MIB (unlike the PTKSA/GTKSA ones)
|
Mark this variable as deprecated
|
GEN
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Dan Harkins
|
7573
|
1001
|
RISON, Mark
|
E
|
Y
|
|
|
3.4 claims that GCMP is "Galois/Counter Mode with GMAC Protocol", where GMAC is "Galois Message Authentication Code", but 38.57, 39.13, 43.13, 68.11 think it's "Galois Counter Mode protocol"
and 12.5.5 thinks it's "GCM with Galois Message Authentication Code (GMAC) protocol"
|
Work out what GCMP really stands for, and make sure it's expanded thusly everywhere
|
GEN
|
|
EDITOR: 2016-01-29 11:20:48Z - Having seen how keenly changes to security terminology was debated previously, I don't believe the editors should attempt to make this decision. Transferring
to GEN/Security.
|
Assigned
|
|
Dorothy Stanley
|
7105
|
1001
|
Stephens, Adrian
|
G
|
Y
|
1972.65
|
12.6.7
|
"Because a VHT STA is also an HT STA ... elimination of TKIP ..."- this note is stunningly irrelevant because this subclause has nothing to be with TKIP.
|
Remove cited note.
|
MAC
|
|
|
Assigned
|
|
Dorothy Stanley
|
7346
|
1001
|
RISON, Mark
|
T
|
Y
|
828.4
|
9.4.2.25.1
|
It says "The RSNE contains authentication and pairwise cipher suite selectors, a single group data cipher suite selector, an RSN Capabilities field, the PMK identifier (PMKID) count,
a PMKID list, and a single group management cipher suite selector." but it doesn't necessarily contain all of these, and the PMKID count is not of particular significance compared to the other counts. And "authentication" is vague
|
Change to "The RSNE potentially contains AKM and pairwise cipher suite selector lists, single group data and management cipher suite selectors, an RSN Capabilities field, and a PMKID
list." Or replace the first para with "The RSNE contains the information necessary to establisn an RSNA. The format of the RSNE is shown in Figure 9-254."
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Dorothy Stanley
|
7530
|
1001
|
RISON, Mark
|
T
|
Y
|
2130.04
|
14.5.1
|
The term "mesh PMK" is used nowhere else
|
Change to "mesh PMKSA"
|
GEN
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Dorothy Stanley
|
7536
|
1001
|
RISON, Mark
|
T
|
Y
|
2138.01
|
14.5.7
|
Selected AKM Suite || min(localMAC, peerMAC) || max(localMAC, peerMAC)). -- what's the format of the Selected AKM Suite as an octet string?
|
Define the format
|
GEN
|
|
Bugfix
|
Assigned
|
|
Dorothy Stanley
|
7537
|
1001
|
RISON, Mark
|
T
|
Y
|
2138.15
|
14.5.7
|
Selected AKM Suite || min(localMAC, peerMAC) || max(localMAC, peerMAC)). -- what's the format of the Selected AKM Suite as an octet string?
|
Define the format
|
GEN
|
|
Bugfix
|
Assigned
|
|
Dorothy Stanley
|
7649
|
1001
|
RISON, Mark
|
T
|
Y
|
2925.61
|
C.3
|
The description of dot11RSNAActivated suggests it's only for APs
|
Delete "The entity advertises the RSNE in its Beacon and Probe Response frames."
|
GEN
|
|
Bugfix
|
Assigned
|
|
Edward Au
|
7134
|
1001
|
Stephens, Adrian
|
G
|
N
|
2504.27
|
21.2.5.2
|
The approved comment resolution that inserted the new first para in this subclause called for it to be inserted later in the subclause.
|
Determine if the new first para needs to be moved to a better location in this subclause.
|
GEN
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Edward Au
|
7135
|
1001
|
Stephens, Adrian
|
T
|
Y
|
2504.31
|
21.2.5.2
|
I believe the inequality is the wrong way round.
|
change "less than" to "greater than" in the inequality on this line.Make matching change at 2506.13And change the text at 2330.43 to match.
|
GEN
|
|
Bugfix
|
Assigned
|
|
Edward Au
|
7355
|
1001
|
RISON, Mark
|
T
|
Y
|
2925.16
|
C.3
|
"When this attribute is false, the STA may accept MSDUs that have the Protected Frame subfield of the Frame Control field equal to 0." -- so it might not? What does "accept" mean here,
exactly?
|
Delete this sentence
|
GEN
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Edward Au
|
7437
|
1001
|
RISON, Mark
|
T
|
Y
|
2875.55
|
C.3
|
There are 5 instances of "fixed-point Part". However, the whole thing is fixed-point; what is being referred to is actually the integer part
|
Change "fixed-point Part" to "integer part" in all 5 instances
|
GEN
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Edward Au
|
7438
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Edward Au
|
7556
|
1001
|
RISON, Mark
|
T
|
Y
|
2681.01
|
B.4
|
CFDMG and CFDMGSTA are the same thing
|
Change all CFDMGSTAs to CFDMGs and delete the CFDMGSTA row
|
GEN
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Edward Au
|
7633
|
1001
|
RISON, Mark
|
T
|
Y
|
|
|
There are half a dozen instances of "with a valid FCS". These should be removed, as it is implicit that if a frame has an invalid FCS you haven't received anything (otherwise you'd have
to pepper every second line of the spec with "with a valid FCS"!)
|
Delete all 5 instances of "with a valid FCS"
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Edward Au
|
7698
|
1001
|
RISON, Mark
|
E
|
Y
|
2919
|
C.3
|
Both dot11VHTExtendedNSSBWSignaling and dot11VHTExtendedNSSBWCapable claim to indicate "that the IEEE Std 802.11 VHT Extended NSS BW Support Signaling option is implemented"
|
Make one be "Implemented" and the other "Enabled"
|
GEN
|
|
EDITOR: 2016-02-04 10:35:59Z - This is not an editorial change. Transferring to GEN/MIB.
|
Assigned
|
|
Emily Qi
|
7101
|
1001
|
Stephens, Adrian
|
G
|
Y
|
1706.09
|
11.11.10.3
|
"the reporting AP has dot11LciCivicInNeighborReport and the neighbor AP has LCI MeasurementCapability (RM Enabled Capabilities element with the LCI Measurement Capability Enabled fieldset
to 1) dot11RMLCIMeasurementActivated equal to true"-- this has at least two errors "has dot11LciCivicInNeighborReport" and"Measurement Capability (...) dot11RMLCIMeasurementActivated equal to true"Note that " (RM Enabled Capabilities element with the LCI Measurement
Capability Enabled field set to 1)" is also a informal way of anonymously referencing a transmission by the AP)." this can also be improved. This informality occurs in a number of places in this subclause. The proposed changes addresses two of these.
|
Change cited text to:"the reporting AP has dot11LciCivicInNeighborReport equal to true and the neighbor AP indicates support for LCI measurement(the neighbor AP has transmitted an RM
Enabled Capabilities element with the LCI Measurement Capability Enabled field equal to true)"Make matching changes at 1706.32.
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Emily Qi
|
7104
|
1001
|
Stephens, Adrian
|
G
|
Y
|
1897.37
|
11.46
|
"the STA may assume any value for the average MSDU size" - No normative effect can be attributed to "may assume"?
|
Reword in terms of observable behaviour.
|
EDITOR
|
|
Editorial
|
Assigned
|
|
Emily Qi
|
7267
|
1001
|
RISON, Mark
|
T
|
Y
|
1272.58
|
10.3.2.3.5
|
""A correctly received frame is one where the PHY-RXEND.indication primitive does not indicate an error and the FCS indicates the frame is error free." is the very definition of frame
reception
|
Delete the cited sentence
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Emily Qi
|
7281
|
1001
|
RISON, Mark
|
T
|
Y
|
150.51
|
6.3.3.3.2
|
126 and 127 are not valid "rate"s (they're BSS membership selectors)
|
Change "1-127" to "1-125" here and at the top of the next page
|
EDITOR
|
|
Editorial
|
Assigned
|
|
Emily Qi
|
7282
|
1001
|
RISON, Mark
|
T
|
Y
|
159.3
|
6.3.4.2.2
|
126 and 127 are not valid "rate"s (they're BSS membership selectors)
|
Change "1-127" to "1-125"
|
EDITOR
|
|
Editorial
|
Assigned
|
|
Emily Qi
|
7283
|
1001
|
RISON, Mark
|
T
|
Y
|
173.47
|
6.3.7.3.2
|
126 and 127 are not valid "rate"s (they're BSS membership selectors)
|
Change "1-127" to "1-125" and add a row for BSSMembershipSelectorSet
|
EDITOR
|
|
Editorial
|
Assigned
|
|
Emily Qi
|
7284
|
1001
|
RISON, Mark
|
T
|
Y
|
177.36
|
6.3.7.4.2
|
126 and 127 are not valid "rate"s (they're BSS membership selectors)
|
Change "1-127" to "1-125"
|
EDITOR
|
|
Editorial
|
Assigned
|
|
Emily Qi
|
7285
|
1001
|
RISON, Mark
|
T
|
Y
|
187.29
|
6.3.8.3.2
|
126 and 127 are not valid "rate"s (they're BSS membership selectors)
|
Change "1-127" to "1-125" and add a row for BSSMembershipSelectorSet
|
EDITOR
|
|
Editorial
|
Assigned
|
|
Emily Qi
|
7286
|
1001
|
RISON, Mark
|
T
|
Y
|
190.5
|
6.3.8.4.2
|
126 and 127 are not valid "rate"s (they're BSS membership selectors)
|
Change "1-127" to "1-125"
|
EDITOR
|
|
Editorial
|
Assigned
|
|
Emily Qi
|
7287
|
1001
|
RISON, Mark
|
T
|
Y
|
201.52
|
6.3.11.2.2
|
126 and 127 are not valid "rate"s (they're BSS membership selectors)
|
Change "1-127" to "1-125"
|
EDITOR
|
|
Editorial
|
Assigned
|
|
Emily Qi
|
7288
|
1001
|
RISON, Mark
|
T
|
Y
|
246.6
|
6.3.27.3.2
|
126 and 127 are not valid "rate"s (they're BSS membership selectors)
|
Change "1-127" to "1-125"
|
EDITOR
|
|
Editorial
|
Assigned
|
|
Emily Qi
|
7289
|
1001
|
RISON, Mark
|
T
|
Y
|
247.58
|
6.3.27.4.2
|
126 and 127 are not valid "rate"s (they're BSS membership selectors)
|
Change "1-127" to "1-125"
|
EDITOR
|
|
Editorial
|
Assigned
|
|
Emily Qi
|
7290
|
1001
|
RISON, Mark
|
T
|
Y
|
249.03
|
6.3.27.5.2
|
126 and 127 are not valid "rate"s (they're BSS membership selectors)
|
Change "1-127" to "1-125"
|
EDITOR
|
|
Editorial
|
Assigned
|
|
Emily Qi
|
7310
|
1001
|
RISON, Mark
|
E
|
Y
|
1346.56
|
10.21.4
|
"When dot11OperatingClassesImplemented is true, the following statements apply:" -- the first statement is already made in the previous subclause
|
Delete the first bullet
|
MAC
|
|
EDITOR: 2016-02-02 12:17:12Z - I agree this is aparent duplication. However that is not an editorial function. Transferring to MAC/Operation.
EDITOR_Q: 2016-02-01 23:47:06Z- Personally, I think the first bullet is needed. A group discussion is needed.
|
Assigned
|
|
Emily Qi
|
7316
|
1001
|
RISON, Mark
|
T
|
Y
|
873.41
|
9.4.2.40
|
"When included in a Beacon, Probe Response, or Location Track Notification frame, the Antenna ID identifies the antenna(s) used to transmit the Beacon, Probe Response, or Location Track
Notification frame. When included in a measurement report, or Location Track Notification frame, the Antenna ID identifies the antenna(s) used for the reported measurement or transmission of the Location Track Notification frame. The valid range for the Antenna
ID is 1 to 254. The value 0 indicates that the antenna identifier is unknown. The value 255 indicates that this measurement was made with multiple antennas, i.e., antennas were switched during the measurement duration. In a Beacon Report or Frame Report, the
Antenna ID always identifies the antenna used to receive the reported beacon or frame." but it's not clear to me that the antenna element can be included in anything except a beacon or probe response (from grepping for "Antenna element")
|
Change to "The Antenna ID identifies the antenna(s) used to transmit the frame the Antenna element is contained in. The valid range for the Antenna ID is 1 to 254. The value 0 indicates
that the antenna identifier is unknown. The value 255 indicates that this transmission was made with multiple antennas, i.e., antennas were switched during the transmission."
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Emily Qi
|
7501
|
1001
|
RISON, Mark
|
T
|
Y
|
1361.04
|
10.22.2.10.1
|
"All retransmission attempts by a non-DMG STA for an MPDU that is not sent under a block ack agreement and that has failed the acknowledgment procedure one or more times shall be made
with the Retry subfield set to 1 in the Data or Management frame. " -- what is the purpose of the words from "in the" onwards? Maybe better to move the "Data or Management" to the "MPDU" and delete from "in the" onwards. Ditto next sentence. Ditto in the DCF:
"All retransmission attempts for an MPDU the Type subfield equal to Data or Management that has failed the Ack procedure one or more times shall be made with the Retry field set to 1 in the Data or Management frame." - delete from "in the onwards").
|
As it says in the comment
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Emily Qi
|
7590
|
1001
|
RISON, Mark
|
T
|
Y
|
1063.21
|
9.4.2.167
|
Status Indication and Value need to be specified as being reserved for the initiating STA
|
As it says in the comment
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Gabor Bajko
|
7147
|
1001
|
Bajko, Gabor
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Ganesh Venkatesan
|
7207
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Ganesh Venkatesan
|
7818
|
1001
|
Hamilton, Mark
|
T
|
Y
|
1402.01
|
10.24.10
|
GCR must actually do Block Ack reordering, because Replay Detection will blow up otherwise. It would be good to have text that made this clear. (It might be implied because GCR is just
a special case BA, but that's a bit weak.)
|
Add text clarifying that GCR does Block Ack reordering to 10.24.10, similar to 10.24.7.
|
MAC
|
|
|
Assigned
|
|
Graham Smith
|
7038
|
1001
|
Stephens, Adrian
|
G
|
Y
|
1133.11
|
9.6.8.3
|
The structure for the Measurement Pilot frame cannot be parsed. It is not possible to distinguish between an optional subelement and an element of the same ID. For example, a vendor specific
subelement cannot be distinguished from the vendor specific element which is permitted to follow the action field.This confusion is completely unnecessary because the "subelements" can be declared as optional fields carrying the elements in the subelement
table.
|
Remove the optional sublement IDs field, and replace with optional Multiple BSSID and Wide Bandwidth Channel Switch fields.
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Graham Smith
|
7039
|
1001
|
Stephens, Adrian
|
T
|
Y
|
1140.52
|
9.6.8.11
|
"The Vendor Specific Content contains the vendor-specific fields and may include elements defined in thestandard." -- normative verb in Clause 9.But as the vendor specific content is
defined by the vendor, and might, for example, also include a compressed version of 'War and Peace' by Tolstoy, or the current price of Rubber Ducks in outer Mongolia, it is not appropriate (and certainly not necessary) for the Standard to speculate as to
its content.
|
Replace cited sentence with "The Vendor Specific Content is not defined in this Standard." or "The Vendor Specific Content is outside the scope of this Standard."
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Graham Smith
|
7043
|
1001
|
Stephens, Adrian
|
G
|
Y
|
1189.54
|
9.6.14.9
|
"The Preferred Candidate List Included bit set to 0 indicates that the receiving STA may ignore theBSS Transition Candidate List Entries field." - normative verb in Clause 9
|
Move cited text to Clause 10/11, or change to "can" here and cite subclause that defines this behavior.
|
MAC
|
|
EDITOR: 2016-02-09 14:18:43Z - I can't find a normative statement in Clause 11.24.7.* that describes this behavior. To resolve this comment will require adding a normative statement in
Clause 11. Not trivial. Transferring to MAC.
|
Assigned
|
|
Graham Smith
|
7079
|
1001
|
Smith, Graham
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Graham Smith
|
7080
|
1001
|
Smith, Graham
|
T
|
Y
|
1410.46
|
10.26.2
|
1410.7 "The NonERP_Present bit shall be set to 1 when a NonERP STA is associated with the BSS" 1410.46 "The Use_Protection bit may be set to 1 when the NonERP_Present bit is 1." 1410.48
"If one or more NonERP STAs are associated in the BSS, the Use_Protection bit shall be set to 1 in transmitted ERP elements." This last criteria seems to be in contrast to the previous statement on line 46. If a NonERP STA is associated then then the Non_ERO
Present bit is set AND Use_Protection bit is set. Is the condition "The NonERP_Present bit may be set to 1 at any time because the AP feels like it?" Then the L46 is OK. BUT we read that there are some conditions when the NonERP_Present bit can be set, for
example, in IBSS it is optional, and if there is an overlapping NonERP STA, i.e. not associated. So, strictly speaking the sentence is correct but it is saying nothing. If nothing else make it a 'should'
|
1410.46 to read "The Use_Protection bit should be set to 1 when the NonERP_Present bit is 1."
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Graham Smith
|
7081
|
1001
|
Smith, Graham
|
T
|
Y
|
1271.14
|
10.3.2.3.3
|
"The SIFS shall be used prior to transmission of an (#1198)Ack frame, a CTS frame, a PPDU containing a BlockAck frame that is an immediate response to either a BlockAckReq frame or an
A-MPDU, a DMG CTS frame, a DMG DTS frame,(#5112) a Grant (#1198)Ack frame, a response frame transmitted in the ATI,(11ad)(Ed) the second or subsequent MPDU of a fragment burst, and by a STA responding to any polling by the PCF. The SIFS may also be used by
a PC for any types of frames during the CFP (see 10.4 (PCF))." No mention of SIFS between data packets in a TXOP. Needs to be added to list.
|
At 1271.12. After "The SIFS may also be used by a PC for any types of frames during the CFP (see 10.4 (PCF))" add ", or within a TXOP."
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Graham Smith
|
7082
|
1001
|
Smith, Graham
|
T
|
Y
|
1271.14
|
10.2.3.2.2.
|
"The SIFS timing shall be achieved when the transmission of the subsequent frame is started at the TxSIFS slot boundary as specified in 10.3.7 (DCF timing relations)." "Shall be achieved"?
I don't know what that means. Reading the rest of the para does not help either as it is concerned with the accuracy. I think it is trying to say that if teh TXSIFS slot boundary us used then this is SIFS Timing.
|
Replace cited sentence with "The SIFS timing is when the transmission of the subsequent frame is started at the TxSIFS slot boundary as specified in 10.3.7 (DCF timing relations)."
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Graham Smith
|
7084
|
1001
|
Smith, Graham
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Graham Smith
|
7085
|
1001
|
Smith, Graham
|
T
|
Y
|
1297.39
|
10.3.7
|
Equation 10-2 aSIFS Time should be >=, as all the times in the equation must be completed before the boundary. Similarly Equation 10-3 aSlot Time should be >=
|
Change "=" to ">=" for equations 10-2 and 10-3.
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Graham Smith
|
7087
|
1001
|
Smith, Graham
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Graham Smith
|
7088
|
1001
|
Smith, Graham
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Graham Smith
|
7089
|
1001
|
Smith, Graham
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Graham Smith
|
7090
|
1001
|
Smith, Graham
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Graham Smith
|
7137
|
1001
|
Smith, Graham
|
T
|
Y
|
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
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Graham Smith
|
7178
|
1001
|
RISON, Mark
|
T
|
Y
|
1273.58
|
10.3.2.3.7
|
"EIFS shall not be invoked if the NAV is updated by the frame that would have caused an EIFS, such as when the FCS fails and the L-SIG TXOP function employs L-SIG information to update
the NAV" -- what is the L-SIG TXOP function, and how does this update the NAV?
|
Either reword to talk of L-SIG TXOP protection, or delete
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Graham Smith
|
7179
|
1001
|
RISON, Mark
|
T
|
Y
|
1602.16
|
11.2.3.5
|
"The following rules describe operation of the ATIM frame and frame transmission to STAs in PS mode in a non-DMG IBSS and in a DMG BSS" -- so the rules apply to a DMG non-IBSS? This doesn't
make sense, especially since this is a subclause of "Power management in an IBSS"
|
Change "in a non-DMG IBSS and in a DMG BSS" to "in an IBSS"
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Graham Smith
|
7212
|
1001
|
RISON, Mark
|
T
|
Y
|
1062.2
|
9.4.2.165
|
Discussions on D4.0 suggested the Quiet Channel element might be used for IBSSes, but it's not clear how this works, and also the field should then not be called "AP Quiet Mode"
|
Either add a statement to say that the Quiet Channel element can only be used in an infrastructure BSS, or delete "AP" from the name of the field
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Graham Smith
|
7278
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
MAC: 2016-02-19 16:11:57Z - Reviewed 11-16/0237. Consensus is to make the changes (REVISED), but the details of the correct resolution changes needs to be worked off-line.
Clarity/consistency (Med scope)
|
Assigned
|
|
Graham Smith
|
7280
|
1001
|
RISON, Mark
|
T
|
Y
|
201.52
|
6.3.11.2.2
|
The BSSBasicRateSet can't include rates not in both dot11SupportedDataRatesRxTable and dot11SupportedDataRatesTxTable
|
Add this caveat to the "Valid range" cell (where it currently says 1-127). Make a similar statement about HT-MCS and VHT-MCSes
|
MAC
|
|
MAC: 2016-02-19 16:11:57Z - Reviewed 11-16/0237. Consensus is to make the changes (REVISED), but the details of the correct resolution changes needs to be worked off-line.
Bugfix
|
Assigned
|
|
Graham Smith
|
7425
|
1001
|
RISON, Mark
|
T
|
Y
|
1772.36
|
11.24.6.4
|
"NOTE---The mechanism by which t1' and t4' are derived from the TOD and TOA fields, and the mechanism by which t2 and t3 are determined, are implementation dependent." -- also the mechanism
by which the TOD and TOA fields are determined for transmission. Also the primes around here seem to have variable italicness and indeed sex (sexless or not)
|
Change to "At the responding STA, the mechanism by which t1' and t4' are derived from the TOD and TOA fields, and the mechanism by which t2 and t3 are determined, are implementation dependent.
At the initiating STA, the mechanism by which the TOD and TOA fields are determined is implementation dependent."Make sure all the primes are the same throughout this subclause
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Graham Smith
|
7434
|
1001
|
RISON, Mark
|
T
|
Y
|
657.22
|
9.4.1.4
|
"A STA sets the Short Slot Time subfield to 1 in transmitted Association Request, Reassociation Request, DLS Request, and DLS Response frames when dot11ShortSlotTimeOptionImplemented
and dot11ShortSlotTimeOptionActivated are true. Otherwise, the STA sets the Short Slot Time subfield to 0 in transmitted Association Request and Reassociation Request frames." -- and otherwise in DLS frames
|
Change the second sentence to "Otherwise, the STA sets the Short Slot Time subfield to 0."
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Graham Smith
|
7435
|
1001
|
RISON, Mark
|
T
|
Y
|
655.31
|
9.4.1.4
|
"An AP sets the ESS subfield to 1 and the IBSS subfield to 0 within transmitted Beacon or Probe Response frames. An IBSS STA sets the ESS subfield to 0 and the IBSS subfield to 1 in transmitted
Beacon or Probe Response frames. A mesh STA sets the ESS and IBSS subfields to 0 in transmitted Beacon or Probe Response frames." -- what about a non-AP STA in an infraBSS (e.g. in (re)assoc req), or (re)assoc rsp, or a PCP?
|
Change to "An AP or PCP sets the ESS subfield to 1 and the IBSS subfield to 0. An IBSS STA sets the ESS subfield to 0 and the IBSS subfield to 1. Otherwise, the ESS and IBSS subfields
are reserved."
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Graham Smith
|
7465
|
1001
|
RISON, Mark
|
E
|
Y
|
2231.22
|
16.1.1
|
"The basic HR/DSSS PHY" -- Is there an advanced HR/DSSS PHY? Is there a fortran HR/DSSS PHY?
|
Delete "basic", and perhaps refer to the HR/DSSS/long flavour
|
GEN
|
|
EDITOR: 2016-02-02 13:17:46Z - I have no idea what the basic HR/DSSS PHY is supposed to be. Perhaps "non-short"? Transferring to GEN/Terminology.
|
Assigned
|
|
Graham Smith
|
7496
|
1001
|
RISON, Mark
|
T
|
Y
|
533.59
|
6.5.4.2
|
"The Slot Time (in microseconds) that the MAC uses for defining the PIFS and DIFSs." -- it does more than those two IFSes
|
Change to "... defining the IFSs"
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Graham Smith
|
7541
|
1001
|
RISON, Mark
|
T
|
Y
|
1351.21
|
10.22.2.4
|
What exactly is "the backoff procedure" for EDCA? Is it the thing which starts with waiting for AIFS of idleness, or the thing which starts with throwing a random number and then waiting
for that number of slots of idleness, or what? The term is used in many places, but this is hard if it's not defined!
|
At the end of the second para of 9.22.2.4 insert "The backoff procedure starts with this step."
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Graham Smith
|
7550
|
1001
|
RISON, Mark
|
T
|
Y
|
1764.23
|
11.24.6
|
When may an FTM session be implicitly terminated (i.e. no FTM with DT 0)?
|
Add a statement that the responding STA may terminate an FTM session at any point (not just after the last FTM frame of the last burst instance)
|
MAC
|
|
Bugfix
|
Assigned
|
|
Graham Smith
|
7580
|
1001
|
RISON, Mark
|
T
|
Y
|
872.18
|
9.4.2.39
|
This subclause is written as if there were only one EDCAF, but there are 4
|
Change "EDCAF" to "the EDCAFs considered together" or something
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Graham Smith
|
7581
|
1001
|
RISON, Mark
|
T
|
Y
|
877.15
|
9.4.2.44
|
It says " EDCA services" -- what's that?
|
Change to " EDCAF"
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Graham Smith
|
7586
|
1001
|
RISON, Mark
|
T
|
Y
|
|
|
What exactly does "mandatory" mean in the context of rates(/MCSs/preambles/etc.) in PHYs? If a rate is "mandatory", does that mean it has to be included in the operational and/or basic
rate set? Can a device refuse to associate with another device that does not include all mandatory rates, or conversely can a device assume that other devices will include all mandatory rates? The direction the D4.0 BRC was going in when it ran out of time
was that no, it need not be in either set (see 15/1207)
|
Add a "NOTE---A STA is not required to include all mandatory rates in its operational rate set, and a STA starting a BSS is not required to include all mandatory rates in the basic rate
set."
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Graham Smith
|
7640
|
1001
|
RISON, Mark
|
T
|
Y
|
1567.15
|
11.1.4.3.4
|
Re CID 5208: The assertion "multi-band capable non-AP STAs can respond to Probe Requests" needs some backing evidence (i.e. a specificspec location where this is required/allowed, other
than the location which was the subject of that comment)
|
Delete this criterion
|
MAC
|
|
MAC: 2016-02-24 15:33:11Z - Reviewed 11-16/278r1 for CID 7640. This concept appears to have been inserted by 11ad, intentionally. But, the re-write of this text into multiple subclauses
and bullet lists has complicated tracking the history. This will need more research. See also CID 2129, and 11-14/0057r5.
Clarity/consistency (Med scope)
|
Assigned
|
|
Graham Smith
|
7654
|
1001
|
RISON, Mark
|
T
|
Y
|
1574.61
|
11.2.2.2
|
"To change power management modes a STA shall inform the AP by completing a successful frameexchange (as described in Annex G) that is initiated by the STA and that includes a Management
frame,Extension frame or Data frame, and also an Ack or a BlockAck frame from the AP." does not make it clear that the frame exchange is required to include an Ack/BA (the NOTE 1 below does make this clear, but it's not normative)
|
Change to "To change power management modes a STA shall inform the AP by completing a successful frameexchange (as described in Annex G) that is initiated by the STA and that is required
to include a Management frame,Extension frame or Data frame, and also an Ack or a BlockAck frame from the AP."
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Graham Smith
|
7700
|
1001
|
RISON, Mark
|
T
|
Y
|
555.12
|
8.3.5.10.4
|
"The effect of receipt of this primitive by the PHY entity is to reset the PHY CS/CCA timers to the stateappropriate for the end of a received frame and to initiate a new CCA evaluation
cycle." -- what PHY CS/CCA timers?
|
Change to "The effect of receipt of this primitive by the PHY entity is to reset the PHY to the stateappropriate for the end of a received frame and to initiate a new CCA evaluation cycle."
|
MAC
|
Submission Required
|
MAC: 2016-02-25 15:36:46Z - Note: Discussed on last ballot round also (see CID 6304, and document 11-15/1400). Assign to Graham Smith, submission required.
Clarity/consistency (Med scope)
|
Assigned
|
|
Graham Smith
|
7769
|
1001
|
RISON, Mark
|
T
|
Y
|
1744.52
|
11.23.6
|
"any" v. "all" in"Switching to a 40 MHz off-channel direct link is achieved by including the following information in the TDLS Channel Switch Request frame:--- Operating Class field indicating
40 MHz Channel Spacing--- Secondary Channel Offset field indicating SCA or SCB" implies all need to be present"v."Switching to a wideband off-channel direct link is achieved by including any of the following information in the TDLS Channel Switch Request frame:---
An Operating Class element indicating 40 MHz Channel Spacing--- A Secondary Channel Offset element indicating SCA or SCB--- A Wide Bandwidth Channel Switch element indicating 80 MHz, 160 MHz, or 80+80 MHz channel width"
|
State that 11.23.6.3 only applies to non-VHT HT STAs and 11.23.6.5 only applies to VHT STAs
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Graham Smith
|
7771
|
1001
|
RISON, Mark
|
T
|
Y
|
1298.26
|
10.3.7
|
Table 10-5 does not have any rows for VHT or DMG modulations. Ipso facto, dynamic EIFS cannot be used with these
|
Change 1298.13 to say "When dot11DynamicEIFSActivated is true, the PPDU that causes the EIFS does not contain a singleMPDU with a length equal to 14 or 32 octets, and this PPDU is covered
by one of the rows in Table 10-5, EIFS is determined as shown in Equation 10-7."
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Graham Smith
|
7772
|
1001
|
RISON, Mark
|
T
|
Y
|
1628.33
|
11.3.5.5
|
Where is the AP/PCP definition of the reassociation initiation procedures on the current AP (which might as a special case be the same as the new AP), and in particular all the stuff
which is deleted or reset (such as BA agreements)?
|
Add a:p) If the ResultCode in the MLME-REASSOCIATE.response primitive is SUCCESSand the CurrentAPAddress parameter in the MLME-REASSOCIATION.indication primitive had the new AP's MAC
address in theCurrentAPAddress parameter (reassociation to the same AP), the following states, agreements andallocations shall be deleted or reset to initial values:1) All EDCAF state2) Any block ack agreements3) Sequence number4) Packet number5) Duplicate
detection caches6) Anything queued for transmission7) Fragmentation and reassembly buffers8) Power management mode9) WNM sleep mode.The following states, agreements and allocations are not affected by the reassociation procedure:1) PSMP sessions2) Enablement/Deenablement3)
GDD enablement4) STSL, DLS and TDLS agreements5) SMKSAs, STKSAs and TPKSAs established with any peers6) MMSLs7) GCR agreements8) DMS agreements9) TFS agreements10) FMS agreements11) Triggered autonomous reporting agreements12) FTM sessions13) DMG SP and CBAP
allocations.
|
MAC
|
|
|
Assigned
|
|
Graham Smith
|
7773
|
1001
|
RISON, Mark
|
T
|
Y
|
1730.39
|
11.16.9
|
"the STA may transmit a pending 40 MHz mask PPDU only if the secondary channel has also been idle during the times the primary channel CCA is performed (defined in 9.3.7 (DCF timing relations))
during an interval of a PIFS for the 5 GHz band and DIFS for the 2.4 GHz band immediately preceding the expiration of the backoff counter." -- why the difference?
|
Change to "the STA may transmit a pending 40 MHz mask PPDU only if the secondary channel has also been idle during the times the primary channel CCA is performed (defined in 9.3.7 (DCF
timing relations)) during an interval of a PIFS immediately preceding the expiration of the backoff counter."
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Graham Smith
|
7786
|
1001
|
RISON, Mark
|
T
|
Y
|
1689.26
|
11.11.9.1
|
In a Beacon report, how is the bandwidth indicated? I don't think it's the Operating Class field, because an OC only gives the maximum BSS bandwidth, not necessarily the actual BSS bandwidth
(e.g. you can operate a 20 MHz bandwidth in an OC which specifies a BSS bandwidth of "up to 40 MHz")
|
Add at the end of the subclause "NOTE---An operating class indicating 40 MHz (or up to 40 MHz) is used to indicate a 40 MHz PPDU only."
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Graham Smith
|
7788
|
1001
|
RISON, Mark
|
T
|
Y
|
1290.51
|
10.3.4.3
|
What does "CWindow" indicate in Figure 10-15, exactly? It seems to be some kind of fixed period after DIFS for any station that just transmitted a frame, but no such period exists
|
Delete "CWindow" from Figure 9-15, including the key
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Graham Smith
|
7789
|
1001
|
RISON, Mark
|
T
|
Y
|
1270.28
|
10.3.2.3.1
|
Figures 10-4, 10-10, 10-14 say or at least suggest there is immediate access when the medium is idle for DIFS or AIFS. This is only the case if the CW is zero. We do not want people thinking
they can just transmit after DIFS/AIFS, except in very specific circumstances
|
Add "and CW is zero" in the identified figures
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Graham Smith
|
7822
|
1001
|
Hamilton, Mark
|
T
|
Y
|
1123.6
|
9.6.5.2
|
ADDBA (9.6.5.2) points to 9.3.1.8 for the definition of the Starting Sequence Control field. But, 9.3.1.8 only makes sense in the context of a BAR, not an ADDBA.
|
Duplicate the text for Starting Sequence Control field (copy from 9.3.1.8) in 9.6.5.2.
|
MAC
|
|
|
Assigned
|
|
Graham Smith/Mark Rison
|
7292
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
MAC: 2016-02-22 14:53:20Z - Agree, for frames that are from a non-AP STA. Need to have specific locations cited.
Clarity/consistency (Med scope)
|
Assigned
|
|
Guido Hertz
|
7219
|
1001
|
RISON, Mark
|
T
|
Y
|
1678.02
|
11.9.8.4.3
|
"Transitioning to a new channel does not tear down mesh peerings and, as long as themesh peers move to the new operating channel, their peerings may be maintained in the new channel."
-- they should always be maintained, at least from the side which commanded the channel switch
|
Change "may be" to "are"
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Guido Hertz
|
7372
|
1001
|
RISON, Mark
|
T
|
Y
|
2152.14
|
14.10.8.3
|
"HWMP SNs are strictly increasing unsigned integers." contradicts "Comparing HWMP SNs is done using a circular modulo 2**32 comparison."
|
Delete lines 12 and 14 and make line 15 a plain para
|
GEN
|
|
Bugfix
|
Assigned
|
|
Guido Hertz
|
7611
|
1001
|
RISON, Mark
|
T
|
Y
|
2124.01
|
14.4.3
|
Cf CID 5746, not all the parameters of the actions in this subclause are described. More specifically none except the peerMAC argument is described (unlike the events above)
|
Add descriptions of the non-peerMAC parameter to the actions, based on the events (or otherwise)
|
GEN
|
Submission Required
|
Bugfix
|
Assigned
|
|
Jon Rosdahl
|
7509
|
1001
|
RISON, Mark
|
E
|
Y
|
|
|
The term "Vendor OUI or CID" is used in 3 places, but what's the precedence
|
If it's "Vendor OUI or Vendor CID" then need to define a Vendor CID? If it's "Vendor OUI, or CID" then change to that, i.e. add a comma
|
GEN
|
|
Changed to "Terminology" and transferred to GEN. We previously had a bunch of changes resulting from RAC comments, so this probably needs careful consideration.
|
Assigned
|
|
Jouni M.
|
7420
|
1001
|
RISON, Mark
|
T
|
Y
|
1949.37
|
12.5.3.3.6
|
It says "A CCMP protected individually addressed robust Management frame shall be protected with the TK." -- what about other CCMP-protected frames? Note for the recipient this is clearer:
"A CCMP protected individually addressed robust Management frame shall use the same TK as a Data frame."
|
Change to "A CCMP protected frame shall be protected with the appropriate TK, where a CCMP protected individually addressed robust Management frame shall use the same TK as a Data frame."
|
GEN
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Jouni M.
|
7421
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Jouni M.
|
7462
|
1001
|
RISON, Mark
|
T
|
Y
|
1967.23
|
12.6.1.3.2
|
", or if the PMK in the cached PMKSA is no longer valid," -- how can this be determined? How is this even possible -- doesn't invalidation of a PMK also invalidate the whole PMKSA?
|
Delete the cited text. Also at 1975.45
|
GEN
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Jouni Malinen
|
7347
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Mark Hamilton
|
7069
|
1001
|
Stephens, Adrian
|
G
|
Y
|
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
|
Submission Required
|
MAC: 2016-02-25 03:27:31Z - See minutes from Feb F2F.
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Hamilton
|
7146
|
1001
|
Stephens, Adrian
|
G
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Hamilton
|
7150
|
1001
|
Stephens, Adrian
|
G
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Mark Hamilton
|
7317
|
1001
|
RISON, Mark
|
T
|
Y
|
1554.34
|
11.1.2.1
|
"A STA contained in the AP or PCP shall initialize its TSF timer independently of any simultaneously started APs or PCPs" -- this cannot in general be acheved, unless the APs/PCPs are
coordinated. Needs to be restricted to managed ("enterprise/corporate") contexts, but this is arguably out of scope of the standard anyway
|
Change to "A STA contained in the AP or PCP shall initialize its TSF timer independently of any simultaneously started APs or PCPs it is aware of", or delete
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Hamilton
|
7324
|
1001
|
RISON, Mark
|
T
|
Y
|
48.3
|
9.4.2.2
|
"When the UTF-8 SSID subfield of the Extended Capabilities element is equal to 1 in the frame that includes the SSID element, the SSID is interpreted using UTF-8 encoding." -- but the
extended caps are static so it doesn't have to be in the same frame
|
Delete the sentence
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Mark Hamilton
|
7378
|
1001
|
RISON, Mark
|
T
|
Y
|
126.47
|
4.10.7
|
It says "PMK or PSK key identifier" -- what's a pairwise shared key key identifier? Also at line 49
|
Change both to "PMK identifier"
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Mark Hamilton
|
7553
|
1001
|
RISON, Mark
|
T
|
Y
|
104.5
|
4.5.4.3
|
Does "PMKSA caching" include "mesh PMKSA caching", given that a "mesh PMKSA" is not a type of "PMKSA"? Is mesh PMKSA caching even defined?
|
Delete "or mesh PMKSA" at the end of the sentence
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Mark Hamilton
|
7658
|
1001
|
RISON, Mark
|
T
|
Y
|
79.32
|
4.3.13
|
What about dot11VHTExtendedNSSBWCapable?
|
Add a line "--- "dot11TVHTExtendedNSSBWCapable" replaces "dot11VHTExtendedNSSBWCapable".
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Mark Hamilton
|
7790
|
1001
|
RISON, Mark
|
T
|
Y
|
1289.4
|
10.3.4.2
|
It says "pending MPDU". What's one of those?
|
See CID 6440 resolution
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Mark Hamilton
|
7792
|
1001
|
RISON, Mark
|
T
|
Y
|
1294.18
|
10.3.4.4
|
"The AP shall attempt todeliver one MSDU or MMPDU to the STA that transmitted the PS-Poll frame, using any frame exchangesequence valid for an individually addressed MSDU or MMPDU." --
can also deliver an A-MSDU
|
Add, ", A-MSDU" after each "MSDU"
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
7807
|
1001
|
Hamilton, Mark
|
T
|
Y
|
96.06
|
4.4.1
|
Why is the first paragraph of 4.4.1 here? It (and the first sentence of the second paragraph) should be the first paragraph of 4.4.4.
|
Move the first paragraph, and first sentence of the second paragraph, of 4.4.1 to be the start of subclause 4.4.4 instead. Replace the first sentence of the second paragraph with, "IEEE
Std 802.11 explicilty does not specify the details of implementation of the architectural components."
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Mark Hamilton
|
7808
|
1001
|
Hamilton, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Mark Hamilton
|
7814
|
1001
|
Hamilton, Mark
|
T
|
Y
|
1357.29
|
10.22.2.7
|
There is a problem with this NOTE, in that it describes normative exception behavior that does not seem to be clearly stated in normative text (from three and two paragraphs up, for example).
|
Change this NOTE to normative text, and mention the exclusion ("except following a PS-Poll" or something similar) in the previous paragraphs two, and three, before this one.
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
7816
|
1001
|
Hamilton, Mark
|
T
|
Y
|
64.19
|
4.2.5
|
4.2.5 says 802.11 has to act like a _wired_ network. No, it has to act like an 802 network (including 802.1 MAC Service requirements).
|
Delete "wired"
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Mark Hamilton
|
7817
|
1001
|
Hamilton, Mark
|
T
|
Y
|
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
|
Submission Required
|
|
Assigned
|
|
Mark Hamilton
|
7819
|
1001
|
Hamilton, Mark
|
E
|
N
|
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
|
Submission Required
|
I noted in attempting to provide a solution to this that the diagram is at least misleading. The issue is that MSDU integrity appears like it should occur on the receive side after A-MSDU
deaggregation. But the positions are correct. I believe the "MSDU Integrity" should be called "MSDU/A-MSDU Integrity". But I suspect the description of this process doesn't talk at all about A-MSDUs, so a bigger change is needed than at first appears.
|
Assigned
|
|
Mark Hamilton
|
7825
|
1001
|
Hamilton, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Hamilton
|
7826
|
1001
|
Hamilton, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Rison
|
7133
|
1001
|
Stephens, Adrian
|
T
|
Y
|
2221.54
|
15.4.4.3
|
The para at this line was introduced in response to an approved comment resolution thus: " Incorporate the changes in 11-15/762r15 for CID 6676/6677 which clarifies the issue."However,
the resolution should have called out R16, which was discussed, and which does not contain the editing instruction "", which was the cause of the insertion.
|
Delete cited paragraph.Likewise delete the paragraph at 2249.50
|
GEN
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Rison
|
7208
|
1001
|
RISON, Mark
|
T
|
Y
|
339.01
|
6.3.58
|
For MLME-FINETIMINGMSMT.request, "Set to the value of t1 (see Figure 6-17)" is misleading because it is not set to the t1 in the figure but to the time for the previous request. Ditto
t4. And for the .indication it's the time in the FTM frame, which is again not the t1 and t4 in the figure
|
Change the text as indicated in the comment
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Mark Rison
|
7210
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Mark Rison
|
7213
|
1001
|
RISON, Mark
|
T
|
Y
|
2574.45
|
12.3.11.3
|
The term "MU-capable STA" is not defined. It should be defined as an AP that supports MU-MIMO tx or a non-AP STA that is MU beamformee capable. Alternatively, since the term is hardly
used (3 instances, pp. 78, 1058, 2574), and where it is used it is only used for non-AP STAs, replace it with "MU beamformee capable"
|
As it says in the comment
|
GEN
|
Submission Required
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Mark Rison
|
7225
|
1001
|
RISON, Mark
|
T
|
Y
|
|
|
The description of the PHYCONFIG_VECTOR is missing for DSSS, HR/DSSS, ERP, DMG and TVHT
|
Add such a description
|
GEN
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Mark Rison
|
7240
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Rison
|
7244
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark RISON
|
7255
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
EDITOR: 2016-02-04 13:58:17Z - As this reflects "non-transmitted" information, I am not sure that the proposed change is correct. There's also a difficulty describing "which BSS", because
the element iself does not include this information. Transferring to MAC.
|
Assigned
|
|
Mark Rison
|
7273
|
1001
|
RISON, Mark
|
T
|
Y
|
|
|
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
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Mark Rison
|
7311
|
1001
|
RISON, Mark
|
E
|
Y
|
2330.39
|
19.2.5
|
"the MAC shall" in a PHY clause
|
Move to a MAC clause
|
GEN
|
Submission Required
|
EDITOR: 2016-02-02 13:22:15Z - Similar to comment CID 7106. Transferred to GEN/MAC Operation to be with comment 7106.
|
Assigned
|
|
Mark Rison
|
7312
|
1001
|
RISON, Mark
|
E
|
Y
|
2504.27
|
21.2.5.2
|
"the MAC shall" in a PHY clause
|
Move to a MAC clause
|
GEN
|
Submission Required
|
Submission required. Note similar comments on other PHY subclauses (e.g. CID 7106).
|
Assigned
|
|
Mark Rison
|
7320
|
1001
|
RISON, Mark
|
T
|
Y
|
564.01
|
9.2.2
|
Like ASCII strings, UTF-8 strings should not be terminated
|
Add "or UTF-8" after "ASCII"
|
MAC
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Mark Rison
|
7349
|
1001
|
RISON, Mark
|
T
|
Y
|
1258.01
|
10
|
It was stated during D4.0 comment resolution (*cough*Adrian*cough*) that "transmission of the Beacon at TBTT is a famously individual and unnamed channel access function"
|
Add a subclause on this CAF
|
MAC
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Mark Rison
|
7368
|
1001
|
RISON, Mark
|
E
|
Y
|
549.06
|
8.3.4.4
|
"Parameters in the vectors that are management rather than MAC may be specific to the PHY" -- what on Earth does that mean?
|
Delete the whole sentence
|
GEN
|
|
EDITOR: 2016-01-29 15:43:44Z - Agree this is nonsense. But deleting nonsense is not an editorial function. Transferring to GEN/PHY SAP.
|
Assigned
|
|
Mark Rison
|
7376
|
1001
|
RISON, Mark
|
T
|
Y
|
1949.26
|
12.5.3.3.6
|
"A transmitter shall not use IEEE Std 802.11 MSDU or A-MSDU priorities without ensuring that the receiver supports the required number of replay counters." is not clear. It mixes indices
(priorities) with a count (#rc)
|
Reword as something like "A transmitter shall not use an IEEE Std 802.11 MSDU or A-MSDU priority if this would cause the total number of priorities used during the lifetime of the SA
to exceed the number of replay counters supported by the receiver for that SA."
|
GEN
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Mark Rison
|
7384
|
1001
|
RISON, Mark
|
E
|
Y
|
1719.55
|
11.14
|
This last para belongs to the subclauses in subclause 11.3 on receipt of Deauthentication/Disassociation frames
|
Move the material to subclause 11.3
|
EDITOR
|
Submission Required
|
EDITOR: 2016-02-02 12:19:44Z - In the past we've spent a lot of time writing and rewriting 11.3. The disadvantage of moving into 11.3 is that this probably gets duplicated. Discussion
needed.
EDITOR_Q: 2016-02-02 02:46:53Z - a group discussion is needed.
|
Assigned
|
|
Mark Rison
|
7393
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Rison
|
7396
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
MAC: 2016-02-22 16:36:28Z - Consider some more, to not "close the holes in the existing text" and potentially create non-conformance for existing implementations.
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Rison
|
7399
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
MAC: 2016-02-22 16:49:09Z - Disagreement in the BRC about what No-LLC means. Mark R will attempt to sort this out with Carlos C, and bring back.
Enhance or change existing feature
|
Assigned
|
|
Mark Rison
|
7400
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Mark Rison
|
7419
|
1001
|
RISON, Mark
|
T
|
Y
|
128.53
|
5.1.1.4
|
10.8 says "For MSDUs or A-MSDUs belonging to the service class of QoSAck when the receiver is a QoS STA, the QoS Data frames that are used to send these MSDUs or A-MSDUs shall have the
Ack Policy subfield in the QoS Control field set to Normal Ack, Block Ack, Implicit Block Ack Request, or PSMP Ack." But 5.1.1.4 says "When an MSDU is received from the MAC SAP with [QoSAck] and the recipient STA is a QoS STA [...] the MSDU is transmitted
using a QoS Data frame with the Ack Policy subfield in the QoS Control field set to either Normal Ack (normal acknowledgment) or Block Ack."
|
Work out which is right and make the other one say the same. Even better, avoid the duplication
|
MAC
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Rison
|
7427
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Mark Rison
|
7429
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Rison
|
7446
|
1001
|
RISON, Mark
|
T
|
Y
|
|
|
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
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Mark Rison
|
7448
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Mark Rison
|
7468
|
1001
|
RISON, Mark
|
T
|
Y
|
1066.3
|
9.4.2.167
|
"The FTM Format And Bandwidth field indicates the requested or allocated packet format and bandwidth used by all Fine Timing Measurement frames in an FTM session" -- this is not true,
since FTM frames can use a simpler or narrower format than indicated.
|
Change to "The FTM Format And Bandwidth field indicates the requested or allocated PPDU format and bandwidth that can be used by Fine Timing Measurement frames in an FTM session"
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Rison
|
7471
|
1001
|
RISON, Mark
|
T
|
Y
|
2404.55
|
19.3.20
|
In the PHYs, there are statements that "PHY-TXSTART shall be disabled. What does this mean? How can the name of a (class of) primitive be disabled?
|
Change to say that the PPDU transmission initiated by a PHY-TXSTART shall be terminated
|
GEN
|
Submission Required
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Mark Rison
|
7474
|
1001
|
RISON, Mark
|
T
|
Y
|
562.08
|
8.3.5.17.2
|
When is PHY-TXBUSY.indication(IDLE) issued? The spec only discusses PHY-TXBUSY.indication(BUSY)
|
Add a statement that it is issued when the conditions for the BUSY are no longer met
|
GEN
|
Submission Required
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Mark Rison
|
7478
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark RISON
|
7484
|
1001
|
RISON, Mark
|
E
|
Y
|
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
|
Submission Required
|
This needs technical discussion. Transferring to MAC/Operation.
EDITOR_Q: 2016-02-02 00:24:44Z - A group discussion is needed, or a submission is needed. Perhaps, it should be assigned to MAC.
|
Assigned
|
|
Mark Rison
|
7499
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Mark Rison
|
7500
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
MAC: 2016-02-23 15:21:25Z - After discussion of 11-16/0278r2, there was little/no support in the room for the change. Mark R will check with Brian Hart, and reconsider.
Enhance or change existing feature
|
Assigned
|
|
Mark Rison
|
7503
|
1001
|
RISON, Mark
|
T
|
Y
|
1413.26
|
10.26.3.1
|
In Table 9-12, what is the difference between "Transmit an initial frame within a non-HT PPDU that requires a response frame. The remaining TXOP following the first PPDU exchange may
contain PPDUs using HT-greenfield format and/or separated by RIFS." and "Using a PPDU with the TXVECTOR FORMAT parameter set to HT_MF, transmit first a PPDU that requires a response that is sent using a non-HT PPDU. The remaining TXOP following the first PPDU
exchange may contain HT-greenfield format and/or RIFS sequences."? The second seems to be a subset of the first.
|
Replace the two rows with one saying "Transmit first a PPDU that requires a response that is sent using a non-HT PPDU. The remaining TXOP following the first PPDU exchange may contain
PPDUs using HT-greenfield format and/or separated by RIFS."
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Rison
|
7527
|
1001
|
RISON, Mark
|
E
|
Y
|
|
|
"GTK key", "PSK key identifier", "IGTK key", "TPK key", "PTK Key Holder", "PTK key", "PMK key", "SMK key", "SKCK key", "STK Key" all suffer from RAS syndrome.
|
Delete "key" (case-insensitively) in all such instances
|
GEN
|
Submission Required
|
EDITOR: 2016-01-29 12:15:51Z - There are about 18 instances. Bearing in mind the lively past debates on terminology related to security, I will ask the group to decide.
|
Assigned
|
|
Mark Rison
|
7529
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Mark Rison
|
7532
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Mark Rison
|
7540
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Rison
|
7542
|
1001
|
RISON, Mark
|
T
|
Y
|
1622.07
|
11.3.5
|
The changes made for CID 6375 need to be makde for reassociation too
|
As it says in the comment
|
MAC
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Rison
|
7544
|
1001
|
RISON, Mark
|
T
|
Y
|
222.31
|
6.3.19.1
|
The Direction parameter of MLME-SETKEYS.request is never used in the spec. As far as I can determine, the actual behaviour assumed by the spec is that SETKEYS enables the key for both
directions, and MLME-SETPROTECTION.request allows finer control. Also, what's a "Direction element"?
|
Delete the Direction row at 223.25. Change from 223.41 to: "Receipt of this primitive causes the MAC to apply the keys as follows, subject to the MLME-SETPROTECTION.request primitive:---
The MAC uses thekey information for the transmission of all subsequent frames to which the key applies.--- The MAC installsthe key with the associated Key ID such that received frames of the appropriate type and containingthe matching Key ID are processed
using that key and its associated state information."
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Rison
|
7549
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Mark Rison
|
7555
|
1001
|
RISON, Mark
|
T
|
Y
|
228.3
|
6.3.24.1.4
|
What about the other direction?
|
Change the two bullets to "--- Rx: Specifies that Data frames from the MAC address are protected (i.e., any Data frames without protection received from the MAC address are discarded)
but data frames to the MAC address are not protected.--- Tx: Specifies that Data frames to the MAC address are protected but data frames from the MAC address are not protected."
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Rison
|
7572
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Rison
|
7589
|
1001
|
RISON, Mark
|
T
|
Y
|
1719.55
|
11.14
|
"If a non-AP STA that has an SA with its AP for an association that negotiated management frame protection receives an unprotected Deauthentication or Disassociation frame with reason
code INVALID_CLASS2_FRAME or INVALID_CLASS3_FRAME from the AP" -- this should be in the clauses dealing with receipt of deauth/disassoc
|
Move the behavioural description to subclauses 11.3.4.5 and 11.3.5.9, splitting it into the form "if get this frame then invoke SA as defined in x.x"
|
MAC
|
Submission Required
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Mark Rison
|
7603
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
MAC: 2016-02-23 15:09:23Z - Considered 11-16/0276r2. Mark R will consider the direct STA-STA communication being limited to the BSS capabilities, and bring back.
Enhance or change existing feature
|
Assigned
|
|
Mark Rison
|
7604
|
1001
|
RISON, Mark
|
T
|
Y
|
224.15
|
6.3.20.1.2
|
Why is "Valid range" N/A for the Key ID in MLME-DELETEKEYS.request?
|
Copy the corresponding cell in MLME-SETKEYS.request
|
GEN
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Mark Rison
|
7608
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Rison
|
7655
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Mark Rison
|
7656
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Mark Rison
|
7657
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Mark Rison
|
7674
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Mark RISON
|
7675
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Rison
|
7695
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Rison
|
7699
|
1001
|
RISON, Mark
|
E
|
Y
|
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
|
Submission Required
|
EDITOR: 2016-01-29 15:32:34Z - Creating content is not an editorial task. Transferring to GEN/MAC SAP.
|
Assigned
|
|
Mark Rison
|
7704
|
1001
|
RISON, Mark
|
T
|
Y
|
|
|
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
|
Submission Required
|
Will need specific updated submission to address proposal.
Clarity/consistency (Large scope)
|
Assigned
|
|
Mark Rison
|
7735
|
1001
|
RISON, Mark
|
T
|
Y
|
|
|
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
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Mark Rison
|
7746
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Mark Rison
|
7747
|
1001
|
RISON, Mark
|
T
|
Y
|
1399.5
|
10.24.7.7
|
"An Originator that is a DMG STA shall construct A-MPDUs that contain MPDUs in increasing order of SN.When responding to a BlockAck frame, the Originator shall first retransmit unacknowledged
MPDUs inincreasing order of SN." -- what about wrap-around?
|
Add some words about "modulo 4096"
|
MAC
|
Submission Required
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Mark RISON
|
7748
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Mark Rison
|
7764
|
1001
|
RISON, Mark
|
T
|
Y
|
280.53
|
6.3.38
|
Some MLME primitives (e.g. MLME-DSETPC) have no actual behavioural requirements associated with them (in Clause 11)
|
Ensure that all MLME primitives are referred to somewhere other than just Clause 6
|
GEN
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Mark Rison
|
7791
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Mark Rison
|
7793
|
1001
|
RISON, Mark
|
T
|
Y
|
1313.28
|
10.7.6.1
|
10.7.6.1: "Control frames carried in an A-MPDU that does not contain a VHT single MPDU shall be sent at a rate selected from the rules defined in 10.7.5.7"10.7.5.7: is basically about
Data and Management frames, though "The rules in this subclause also apply to A-MPDUs that aggregate MPDUs of type Data or Management with any other types of MPDU."However Table 9-413---A-MPDU contents MPDUs in the control response context shows that you can
have an (non-VHT single MPDU) A-MPDU without a Data or Management frame. In that situation what rate is used?
|
Clarify
|
MAC
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Mark Rison
|
7795
|
1001
|
RISON, Mark
|
T
|
Y
|
1308.44
|
10.6
|
"A STA shall support the concurrent reception of fragments of at least three MSDUs or MMPDUs." -- frankly, this is not good enough nowadays, even for non-AP STAs (consider QoS, for example)
|
Add "A STA should support the concurrent reception of fragments of at least one MSDU per access category. An AP should support the concurrent reception of at least on MSDU per access
category per associated STA."
|
MAC
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Mark Rison
|
7796
|
1001
|
RISON, Mark
|
T
|
Y
|
|
|
The distinctions made in the specification w.r.t. TS/TC/TSID/TID are incomprehensible
|
Make the definitions comprehensible. E.g. what does "UP for either TC or TS" mean?
|
MAC
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Mark Rison
|
7804
|
1001
|
RISON, Mark
|
E
|
Y
|
|
|
"FST" is an action (fast session transfer), so what's an "FST session"?
|
Change all instances of "FST session" to "FST-capable association"
|
EDITOR
|
Submission Required
|
EDITOR: 2016-01-29 11:44:54Z - The proposed change is clear enough. There are 64 instances, including those in compound nouns such as "FST session setup protocol" and "FST session setup".
The question is whether the group wants to make the change.
I'd be tempted to say "no" with the rationale:
'Rejected. The "FST session" is a session that permits/supports/enables the action of "fast session transfer". The name is appropriate.'
|
Assigned
|
|
Mark Rison
|
7812
|
1001
|
Hamilton, Mark
|
T
|
Y
|
730.62
|
9.4.2.3
|
Why is a Basic Rate anything (rounded), but a non-Basic Rate has to be from the selection list (table 6.5.52)? (9.4.2.3 Supported Rates and BSS Membership Selectors element, third paragraph)
|
Change "Rates not contained in the BSSBasicRateSet parameter are" to "Each Supported Rate in the OperationalRateSet parameter is". Replace the text referencing in table in 6.5.5.2 with
text similar to that above for the BSSBasicRateSet parameter values ("set to the data rate, if necessary rounded..."). Make matching changes in 9.4.2.13.
|
MAC
|
|
|
Assigned
|
|
Mathew Fischer
|
7193
|
1001
|
RISON, Mark
|
T
|
Y
|
3618.2
|
R.7
|
"MPDU_pPPDU" is not defined
|
Change to "MPDU_pA_MPDU"?
|
GEN
|
|
EDITOR: 2016-02-10 11:00:33Z - This should be considered with comment 7113. Transferring to GEN
|
Assigned
|
|
Mathew Fischer
|
7197
|
1001
|
RISON, Mark
|
T
|
Y
|
3617.4
|
R.7
|
"AMSDUB" is not defined
|
Change to "A_MSDU_B"
|
GEN
|
|
EDITOR: 2016-02-10 11:00:33Z - This should be considered with comment 7113. Transferring to GEN.
|
Assigned
|
|
Mathew Fischer
|
7198
|
1001
|
RISON, Mark
|
T
|
Y
|
3617.6
|
R.7
|
What do the vertical bars indicate? Absolute value? None of the quantities can be negative
|
Delete the vertical bars
|
GEN
|
|
EDITOR: 2016-02-10 11:00:33Z - This should be considered with comment 7113. Transferring to GEN
|
Assigned
|
|
Matthew Fischer
|
7093
|
1001
|
Stephens, Adrian
|
G
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Matthew Fischer
|
7114
|
1001
|
Stephens, Adrian
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Matthew Fischer
|
7187
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Matthew Fischer
|
7190
|
1001
|
RISON, Mark
|
T
|
Y
|
3617.47
|
R.7
|
It says "is in units of s/s"
|
Change to "is unitless"
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Matthew Fischer
|
7192
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Matthew Fischer
|
7195
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Matthew Fischer
|
7199
|
1001
|
RISON, Mark
|
T
|
Y
|
3618.1
|
R.7
|
I have no idea what this example means. The size of the MAC header is variable
|
Delete ", e.g. 50"
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Matthew Fischer
|
7222
|
1001
|
RISON, Mark
|
T
|
Y
|
1453.04
|
10.32.3
|
What does "An HT beamformer may use the following worst-case parameters to estimate the duration of the expected frame that contains the feedback response: Basic HT-MCS, HT-Mixed Format,
Supported Grouping." mean? Also the cases are wrong
|
Change to "An HT beamformer may use the following worst-case parameters to estimate the duration of the expected frame that contains the feedback response: lowest rate in basic HT-MCS
set, HT-mixed format, no grouping."
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Matthew Fischer
|
7223
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Matthew Fischer
|
7665
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Matthew Fischer
|
7671
|
1001
|
RISON, Mark
|
T
|
Y
|
1050.29
|
9.4.2.158
|
How does the new extended NSS BW support stuff interact with STBC? ? E.g. what happens if Max VHT NSS for some MCSes ends up being less than implied by Rx STBC?
|
Add "subject to any extended NSS BW support constraint" to the rightmost cell
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Matthew Fischer
|
7679
|
1001
|
RISON, Mark
|
T
|
Y
|
1049.47
|
9.4.2.158.2
|
"Together with the ExtendedNSS BW Support subfield andSupported VHT-MCS and NSSSet field," -- not if it's a TVHT STA
|
Add "(for non-TVHT STAs)"
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Matthew Fischer
|
7680
|
1001
|
RISON, Mark
|
T
|
Y
|
1049.5
|
9.4.2.158.2
|
It says " indicates the channelwidths"
|
Change to " indicates the channelwidths and maximum NSSvalues per width"
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Matthew Fischer
|
7682
|
1001
|
RISON, Mark
|
T
|
Y
|
716.37
|
9.4.1.53
|
If Max VHT NSS is 5, is this combination allowed? If so, does it mean 8?
|
Add a "NOTE 5---Twice Max NSS is equal to equal to double Max VHT NSS, limited to 8." at the end of the table
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Matthew Fischer
|
7683
|
1001
|
RISON, Mark
|
T
|
Y
|
1053.24
|
9.4.2.158.2
|
If Max VHT NSS is 5, is this combination allowed? If so, does it mean 8?
|
Add a "NOTE 5---Twice Max NSS is equal to equal to double Max VHT NSS, limited to 8." at the end of the table
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Matthew Fischer
|
7684
|
1001
|
RISON, Mark
|
T
|
Y
|
1332.17
|
10.7.12.2
|
If Max VHT NSS is 5, is this combination allowed? If so, does it mean 8?
|
Add a "NOTE 5---Twice Max NSS is equal to equal to double Max VHT NSS, limited to 8." at the end of the table
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Matthew Fischer
|
7762
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Matthew Fischer
|
7763
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Menzo Wentink
|
7141
|
1001
|
Wentink, Menzo
|
T
|
Y
|
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
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Michael Fischer
|
7157
|
1001
|
Fischer, Michael
|
G
|
N
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Michael Fischer
|
7158
|
1001
|
Fischer, Michael
|
G
|
N
|
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
|
Submission Required
|
Clarity/consistency (Large scope)
|
Assigned
|
|
Payam Torab Jahroni
|
7171
|
1001
|
TorabJahromi, Payam
|
T
|
N
|
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
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Payam Torab Jahroni
|
7176
|
1001
|
TorabJahromi, Payam
|
T
|
Y
|
1105.24
|
9.5.4
|
Definition of the Chan-FBCK-CAP subfield can suggest that returning channel measurement information (including but not limited to SNR list) -in general- is an option or capability. Since
this is not the case (for example, during a BRP following a TXSS, the responding STA can be asked to return an SNR list for all received sectors from the preceding TXSS, and the responding STA is required to respond with the information in this case), I propose
to add a NOTE to clarify that the Chan-FBCK-CAP capability applies to returning channel measurement during beam refinemnet only.
|
Add the following NOTE after the Chan-FBCK-CAP subfield definition in line 24,NOTE--Regardless of the value of the Chan-FBCK-CAP subfield, a DMG STA is required to return the SNR values
from the last TXSS if it receives a BRP frame with the TXSS-FBCK-REQ field and the SNR Requested subfield within the FBCK-REQ field set to 1 (see 10.38.6.4 (BRP phase execution)).
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Peter Eccelsine
|
7676
|
1001
|
RISON, Mark
|
T
|
Y
|
716.05
|
9.4.1.53
|
Because of 4.3.13, this table applies to TVHT STAs too unless stated otherwise
|
Add "non-TVHT" after "VHT"
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Peter Ecclesine
|
7102
|
1001
|
Stephens, Adrian
|
T
|
Y
|
1876.39
|
11.40.4
|
"NOTE 1--Other means to switch the BSS bandwidth are described in 11.42 (Notification of operating mode changes)." -- this note is incorrect. Operating mode changes are not the same as
BSS bandwidth changes.
|
Delete cited note.
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Peter Ecclesine
|
7123
|
1001
|
Stephens, Adrian
|
G
|
Y
|
1675.12
|
11.9.8.3
|
"each STA in an IBSS is required to detect radar" - it needs to be clear that 802.11 does not create these requirements
|
Change "is required" to "is required by regulation"
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Peter Ecclesine
|
7170
|
1001
|
Ecclesine, Peter
|
T
|
Y
|
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
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Sean Coffey
|
7139
|
1001
|
Fischer, Michael
|
T
|
N
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Sigurd Schelstraete
|
7166
|
1001
|
Wang, Lei
|
T
|
Y
|
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
|
Submission Required
|
MAC: 2016-02-25 15:41:45Z - CIDs 7166, 7167, 7168, 7169 all related. Reference CID 5879, and document 11-15/1509.
For now, default resolution:
CID 5879 was duly discussed and agreed during comment resolution. The issue was shared and discussed with the group in at least four different submissions:
• MU Beamformee capabilities indication in VHT, IEEE document 802.11-15/0057
• Text proposal for Beamformee STS Capabilities , IEEE document 802.11-15/0058
• Discussion of CID 5879, IEEE document 802.11-15/0668
• CID 5879, IEEE document 802.11-15/1509
The proposed modification is purely a capability indication and no change in functionality is required. Moreover, it was shown explicitly that the change is fully backwards compatible with current devices.
In the second part of the comment, the commenter appears to argue that the 11mc project can only deal with technical corrections and that the implementation of CID 5879 goes beyond that (“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.”). This is not correct. TGmc has made substantial changes and additions to the base document in addition to the incorporation
of approved amendments and fixing errors. As such, this is insufficient motivation for reverting CID 5879.
The first part of the argument revolves around the processing of the beamforming matrix at AP side. The changes made in CID 5879 have no bearing on this and the exact determination of the beamforming matrix by the AP has always been outside the scope of the
standard. Moreover, the AP controls the number of streams that a STA will feed back. As such, it can continue to operate as it did before and no extra processing or complexity results from the changes made with the resolution of CID 5879, contrary to what
is suggested in the comment.
Enhance or change existing feature
|
Assigned
|
|
Sigurd Schelstraete
|
7167
|
1001
|
Wang, Lei
|
T
|
Y
|
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
|
Submission Required
|
MAC: 2016-02-25 15:41:45Z - CIDs 7166, 7167, 7168, 7169 all related. Reference CID 5879, and document 11-15/1509.
For now, default resolution:
CID 5879 was duly discussed and agreed during comment resolution. The issue was shared and discussed with the group in at least four different submissions:
• MU Beamformee capabilities indication in VHT, IEEE document 802.11-15/0057
• Text proposal for Beamformee STS Capabilities , IEEE document 802.11-15/0058
• Discussion of CID 5879, IEEE document 802.11-15/0668
• CID 5879, IEEE document 802.11-15/1509
The proposed modification is purely a capability indication and no change in functionality is required. Moreover, it was shown explicitly that the change is fully backwards compatible with current devices.
In the second part of the comment, the commenter appears to argue that the 11mc project can only deal with technical corrections and that the implementation of CID 5879 goes beyond that (“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.”). This is not correct. TGmc has made substantial changes and additions to the base document in addition to the incorporation
of approved amendments and fixing errors. As such, this is insufficient motivation for reverting CID 5879.
The first part of the argument revolves around the processing of the beamforming matrix at AP side. The changes made in CID 5879 have no bearing on this and the exact determination of the beamforming matrix by the AP has always been outside the scope of the
standard. Moreover, the AP controls the number of streams that a STA will feed back. As such, it can continue to operate as it did before and no extra processing or complexity results from the changes made with the resolution of CID 5879, contrary to what
is suggested in the comment.
Enhance or change existing feature
|
Assigned
|
|
Sigurd Schelstraete
|
7168
|
1001
|
Wang, Lei
|
T
|
Y
|
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
|
Submission Required
|
MAC: 2016-02-25 15:41:45Z - CIDs 7166, 7167, 7168, 7169 all related. Reference CID 5879, and document 11-15/1509.
For now, default resolution:
CID 5879 was duly discussed and agreed during comment resolution. The issue was shared and discussed with the group in at least four different submissions:
• MU Beamformee capabilities indication in VHT, IEEE document 802.11-15/0057
• Text proposal for Beamformee STS Capabilities , IEEE document 802.11-15/0058
• Discussion of CID 5879, IEEE document 802.11-15/0668
• CID 5879, IEEE document 802.11-15/1509
The proposed modification is purely a capability indication and no change in functionality is required. Moreover, it was shown explicitly that the change is fully backwards compatible with current devices.
In the second part of the comment, the commenter appears to argue that the 11mc project can only deal with technical corrections and that the implementation of CID 5879 goes beyond that (“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.”). This is not correct. TGmc has made substantial changes and additions to the base document in addition to the incorporation
of approved amendments and fixing errors. As such, this is insufficient motivation for reverting CID 5879.
The first part of the argument revolves around the processing of the beamforming matrix at AP side. The changes made in CID 5879 have no bearing on this and the exact determination of the beamforming matrix by the AP has always been outside the scope of the
standard. Moreover, the AP controls the number of streams that a STA will feed back. As such, it can continue to operate as it did before and no extra processing or complexity results from the changes made with the resolution of CID 5879, contrary to what
is suggested in the comment.
Enhance or change existing feature
|
Assigned
|
|
Sigurd Schelstraete
|
7169
|
1001
|
Wang, Lei
|
T
|
Y
|
2574.47
|
21.3.11.3
|
The paragraph in line 47 to 50 on page 2574 was changed during the comment resolution of 11mc/D4.0 sponsor ballot based on comment CID 5879, regarding decoupling MU Beamformee Sounding
capability from MU PPDU reception capability. During the discussions in the 11mc group, concerns have bee raised about the AP side processing issue for the beamforming matrix for the data with more streams (say 8 streams) than the training streams done with
the STA (say 4 streams), when using NDP frame with less number streams than MU PPDU.In addition, the original description is technically correct, nothing needs to be fixed. That is, the changes proposed by CID 5879 resolution do not belong to technical corrections,
as for 11mc project.
|
Change the parapgraph in line 47 to 50 on page 2574 back to 11mc/D4.0 version, i.e., to the following:An MU-capable STA shall support reception of VHT MU PPDUs with the total number of
space-time streams across the N_user users being less than or equal to its Beamformee STS Capability in the VHT Capabilities Info field.
|
MAC
|
Submission Required
|
MAC: 2016-02-25 15:41:45Z - CIDs 7166, 7167, 7168, 7169 all related. Reference CID 5879, and document 11-15/1509.
For now, default resolution:
CID 5879 was duly discussed and agreed during comment resolution. The issue was shared and discussed with the group in at least four different submissions:
• MU Beamformee capabilities indication in VHT, IEEE document 802.11-15/0057
• Text proposal for Beamformee STS Capabilities , IEEE document 802.11-15/0058
• Discussion of CID 5879, IEEE document 802.11-15/0668
• CID 5879, IEEE document 802.11-15/1509
The proposed modification is purely a capability indication and no change in functionality is required. Moreover, it was shown explicitly that the change is fully backwards compatible with current devices.
In the second part of the comment, the commenter appears to argue that the 11mc project can only deal with technical corrections and that the implementation of CID 5879 goes beyond that (“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.”). This is not correct. TGmc has made substantial changes and additions to the base document in addition to the incorporation
of approved amendments and fixing errors. As such, this is insufficient motivation for reverting CID 5879.
The first part of the argument revolves around the processing of the beamforming matrix at AP side. The changes made in CID 5879 have no bearing on this and the exact determination of the beamforming matrix by the AP has always been outside the scope of the
standard. Moreover, the AP controls the number of streams that a STA will feed back. As such, it can continue to operate as it did before and no extra processing or complexity results from the changes made with the resolution of CID 5879, contrary to what
is suggested in the comment.
Enhance or change existing feature
|
Assigned
|
|
Sigurd Schelstraete
|
7405
|
1001
|
RISON, Mark
|
T
|
Y
|
2506.13
|
21.2.5.3
|
You need to use 20U if the prim is above the sec
|
Change < to >
|
GEN
|
|
Bugfix - similar to CID 7402
|
Assigned
|
|
Sigurd Schelstraete
|
7577
|
1001
|
RISON, Mark
|
T
|
Y
|
1051.08
|
9.4.2.158.2
|
It says "Set to 1 if supported and SU BeamformeeCapable is set to 1."
|
Change to "Set to 1 if supported, SU BeamformeeCapable is set to 1 and not sent by an AP."
|
MAC
|
|
Clarity/consistency (Small scope)
|
Assigned
|
|
Sigurd Schelstraete
|
7584
|
1001
|
RISON, Mark
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Sigurd Schelstraete
|
7805
|
1001
|
Seok, Yongho
|
T
|
Y
|
1168.61
|
9.6.12.1
|
The CSI, Noncompressed Beamforming, Compressed Beamforming and ASEL Indices Feedback frames are an Action or an Action No Ack frame of category HT.And, the Time Priorities of those frames
(Table 9-328) are Yes.Since TGah received a comment asking a clarification of a time priority field of some TGah action frame, TG discussed it.And TG concluded that only Action No Ack frame is eligible for the Time Priority frame.So, TGah has agreed to add
the following condition."Time Priority""Yes when transmitted as an Action no Ack frame"But, if this resolution is correct, the same modification is needed for Table 9-328.
|
In Table 9-328,Add the following condition for the CSI, Noncompressed Beamforming, Compressed Beamforming and ASEL Indices Feedback frames- Yes when transmitted as an Action no Ack frame
|
MAC
|
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Solomon Trainin
|
7148
|
1001
|
Trainin, Solomon
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Solomon Trainin
|
7149
|
1001
|
Trainin, Solomon
|
T
|
Y
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|
|
Solomon Trainin
|
7153
|
1001
|
Trainin, Solomon
|
T
|
Y
|
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
|
Submission Required
|
New feature
|
Assigned
|
|
Solomon Trainin
|
7165
|
1001
|
Trainin, Solomon
|
T
|
Y
|
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
|
Submission Required
|
Enhance or change existing feature
|
Assigned
|
|
Solomon Trainin
|
7749
|
1001
|
RISON, Mark
|
T
|
Y
|
|
|
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
|
Submission Required
|
Clarity/consistency (Med scope)
|
Assigned
|