|
Adrian Stephens
|
5149
|
1000
|
Stephens, Adrian
|
G
|
N
|
1366.17
|
9.24.7
|
HT-immediate block ack is used by DMG (which is not an HT STA), as well as TVHT, which is sometimes an HT STA and sometimes not.
The naming is therefore misleading.
|
Change the "HT-immediate" name to something that is not dependent on HT, such a RC-immediate (for "reduced context").
Ditto with "HT-delayed".
|
MAC
|
Submission Required
|
|
Assigned
|
|
Adrian Stephens
|
5154
|
1000
|
Stephens, Adrian
|
G
|
Y
|
1391.06
|
9.26.5.1
|
L-SIG TXOP protection has not, to my knowledge, been implemented.
It is not a useful mode, witness that VHT decided not to support it.
|
Mark this section as deprecated or obsolete/subject to removal in a later revision.
|
MAC
|
Discuss
|
|
Assigned
|
|
Adrian Stephens
|
5159
|
1000
|
Stephens, Adrian
|
G
|
Y
|
|
General
|
The use of "binary" encoding is to be treated with suspicion because:
1. Bitstrings and binary representations are often confused - and their representations are very different
2. Quoting magic numbers in the body text should be minimized
|
Review all use of "binary". When used to define the encoding of an integer field, replace with decimal.
When used to either insert or test a value in an integer field, replace with either the decimal value, or (where possible) the name of the value, and introduce names for enumeration values if none exist.
|
EDITOR
|
Submission Required
|
|
Assigned
|
|
Adrian Stephens
|
6707
|
1000
|
RISON, Mark
|
G
|
Y
|
|
|
Stop constantly repeating the stuff about "Extendable" "Yes" and "Subelements"!
|
As it says in the comment
|
EDITOR
|
Submission Required
|
EDITOR: 2015-05-28 10:52:04Z - I agree with the sentiment of the comment.
|
Assigned
|
|
Adrian Stephens
|
6713
|
1000
|
RISON, Mark
|
E
|
Y
|
|
|
There are instances of "Probe Response" without a following "frame"
|
Append "frame" or make all-lowercase, throughout
|
EDITOR
|
Submission Required
|
|
Assigned
|
|
Assaf KASHER
|
5996
|
1000
|
Kasher, Assaf
|
T
|
Y
|
1501.33
|
9.38.5.3
|
"... In the Dynamic Allocation Info field of the Grant frame, the AllocationType field shall be set to indicate SP, ..."
Allocation of type SP is irrelevant within BI with CBAP only subfield of DMG Parameters filed set to 1. Current definition does no distinguish between scheduled DTI and entire DTI of CBAP access. The definition may be seeing as applicable for BI with CBAP only
subfield of DMG Parameters filed set to 0, still relevant reference is needed. There is no solution defined to support BI with CBAP only subfield of DMG Parameters filed set to 1.
|
Will be provided in a separate document
|
MAC
|
Submission Required
|
|
Assigned
|
|
Brian Hart
|
5049
|
1000
|
Stephens, Adrian
|
T
|
Y
|
1740.31
|
10.24.5
|
"initiating STA shall transmit using a single RF chain." -- there is no definition of what comprises an RF chain. Likewise at 1733.45.
|
Add a definition of an RF chain.
|
MAC
|
|
|
Assigned
|
|
Brian Hart
|
5177
|
1000
|
Aldana, Carlos
|
T
|
N
|
1737.39
|
10.24.6.4
|
In the ASAP=0 case, we should place an upper bound on the Partial TSF Timer (relative to the last initial FTM Request (iFTMR) frame) so as to prevent the initiating STA from sending the
FTM Trigger frame too early or too late due to clock drift. The worst case clock drift is 13ms (200 ppm * 67 seconds). This limits the scope of the small burst durations.
|
Force the responding STA to send a Partial TSF Timer value that is <=min(BD(ms)*1.625,67) seconds from the most recently successfully transmitted iFTMR. This results in 33% clock drift
from the burst duration. For example, if BD = 16ms, the upper bound becomes 26 seconds. The clock drift in this case would be 5.2 ms (32.5 %).
|
MAC
|
|
|
Assigned
|
|
Brian Hart
|
5179
|
1000
|
Aldana, Carlos
|
T
|
N
|
1741.41
|
10.24.6.4
|
There is no shall statement regarding the Dialog Token of the last FTM frame in an FTM session. Please add " The Dialog Token of the last FTM frame and its retransmissions in a session
shall be set to 0."
|
As in comment
|
MAC
|
|
|
Assigned
|
|
Brian Hart
|
5182
|
1000
|
Aldana, Carlos
|
T
|
N
|
1737.03
|
10.24.6.3
|
If the Ack to FTM_1 is lost and the responding STA does an FTM retransmission of FTM_1, the initiating STA might not be be there.
|
Please clarify what the behavior should be in this case.
|
MAC
|
|
|
Assigned
|
|
Brian Hart
|
5188
|
1000
|
Aldana, Carlos
|
T
|
N
|
1148.29
|
8.6.11
|
In order to allow for Fine Timing Measurement frames to be robust, we should consider adding Fine Timing Measurement frames to this table. I don't think Fine Timing Measurement Request
frames need to be robust, so it's probably not necessary to add them here.
|
As in comment
|
MAC
|
|
|
Assigned
|
|
Brian Hart
|
5223
|
1000
|
Hach, Rainer
|
G
|
Y
|
1735
|
10.24.6
|
FTM seems to be patent pending technology ( WO2015041708 (A1) ). No LoA is visble in IEEE database.
|
Assure that no protected technology is standarized without LoA.
|
MAC
|
|
|
Assigned
|
|
Brian Hart
|
5339
|
1000
|
Hunter, David
|
E
|
Y
|
759.11
|
8.4.2.20.14
|
The reference given in Clause 2 is "IETF RFC 4776", not "-2006" (which is redundant anyway, as that is the ony version of RFC 4776 listed in Clause 2).
|
Replace "RFC 4776-2006" with "RFC 4776" throughout the draft.
|
MAC
|
|
EDITOR: 2015-04-28 09:55:41Z - I don't know what technical impact this might have. Transferring to MAC.
|
Assigned
|
|
Brian Hart
|
6049
|
1000
|
Qi, Emily
|
T
|
N
|
1737.25
|
10.24.6.4
|
The local clocks of the STAs participating in FTM may drift by up to +/-100ppm.
According to L25 the ISTA must transmit within the burst instance. Since the burst instance is set by the RSTA it is not clear which STA is responsible on making sure the FTM Request frames used as a trigger falls within the burst instance.
|
Recommendation:it is the ISTA responsibility to verify the FTM Request used as trigger frame transmitted within the burst period and recommend that the spec, defines a maximum allowed
timing ambiguity between the ISTA and RSTA.
|
MAC
|
|
|
Assigned
|
|
Brian Hart
|
6244
|
1000
|
RISON, Mark
|
T
|
Y
|
1740.33
|
10.24.6.4
|
Should MCS 32 be allowed for FTM
|
Add "MCS 32 format," before "or HT-greenfield format" at 1740.35
|
MAC
|
|
|
Assigned
|
|
Brian Hart
|
6283
|
1000
|
RISON, Mark
|
T
|
Y
|
1741
|
10.24.6.4
|
The setting of the Dialog Token in the last FTM frame is not clear
|
Add "or in the last Fine Timing Measurement frame in an FTM session" after "Dialog Tokens field values of consecutive Fine Timing Measurement frames shall be consecutive, except when
the value wraps around to 1" at 1740.62 and add "The Dialog Token in the final Fine Timing measurement frame shall be set to 0." after "The Follow Up Dialog Token in the initial Fine Timing Measurement frame shall be set to 0." at 1741.14
|
MAC
|
|
|
Assigned
|
|
Brian Hart
|
6316
|
1000
|
RISON, Mark
|
T
|
Y
|
1741.08
|
10.24.6.4
|
What does "(i.e., without correcting the clock offset)" mean?
|
Delete the cited text
|
MAC
|
|
|
Assigned
|
|
Brian Hart
|
6330
|
1000
|
RISON, Mark
|
T
|
Y
|
1740.31
|
10.24.6.4
|
"both the responding STA and initiating STA shall transmit using a single RF chain." seems rather restrictive
|
Add "Fine Timing Measurement frames and the corresponding Ack frames" after "transmit" in the cited text
|
MAC
|
|
|
Assigned
|
|
Brian Hart
|
6354
|
1000
|
RISON, Mark
|
T
|
Y
|
1740.38
|
10.24.6.4
|
"The initiating STA may request the Fine Timing Measurement to have a certain format and bandwidth using the FTM Format And Bandwidth field of the Fine Timing Measurement Parameters element
in the initial Fine Timing Measurement Request frame. The responding STA should transmit Fine Timing Measurement frames with the requested format and bandwidth. In the case of contiguous 160 MHz requests, the initiating STA can indicate whether it uses a single
or two separate RF LOs. In the cases when the responding STA advertises transmission of Fine Timing Measurement frames with contiguous 160 MHz transmissions, the responding STA chooses the appropriate entry in the FTM Format and Bandwidth field depending on
the number of RF LOs used by the responding STA. The responding STA shall not use a bandwidth wider than requested. The responding STA shall not use a VHT format if HT-mixed or non-HT format was requested. The responding STA shall not use an HT format if non-HT
format was requested." is not clear. Is it referring to the "negotiation" phase or the actual FTM frame transmission
|
Make it clear that (1) the rSTA can choose what it wants in the iFTM as long as both STAs are capable of it and (2) the rSTA shall not transmit wider or more complicated than what it
indicated in the iFTM
|
MAC
|
|
|
Assigned
|
|
Brian Hart
|
6356
|
1000
|
RISON, Mark
|
T
|
Y
|
1736.49
|
10.24.6.3
|
If an iSTA does not request ASAP it should not be forced to do it
|
Add "The responding STA's selection of the ASAP value shall be 0 when the initiating STA requests it to be 0." to the list of rules
|
MAC
|
|
|
Assigned
|
|
Brian Hart
|
6417
|
1000
|
RISON, Mark
|
T
|
Y
|
1737.07
|
10.24.6.4
|
"Fine Timing Measurements frames are sent during time windows called burst instances" is too vague. May FTM frames be sent outside burst instances?
|
Clarify that any frames sent outside burst instances might not be acknowledged
|
MAC
|
|
|
Assigned
|
|
Brian Hart
|
6419
|
1000
|
RISON, Mark
|
T
|
Y
|
1737.24
|
10.24.6.4
|
"The initiating STA shall transmit an FTM trigger frame as soon as it is available on channel at the beginning of the burst." -- what if it sends one before that? What if it sends one
before that, and again during the burst instance
|
Clarify whether the rSTA waits until the burst instance before starting, or whether the rSTA ignores trigger frames sent before the burst instance
|
MAC
|
|
|
Assigned
|
|
Carlos Aldana
|
5174
|
1000
|
Aldana, Carlos
|
T
|
N
|
856.3
|
8.4.2.36
|
To reduce the number of probe requests sent and not have to send the lengthy VHT Operations or HT Operations elements, we should allow for the transmission of the short (5 bytes) Wide
Bandwidth Channel Switch Element in Neigbhor Report.
|
Include a row in Table 8-148 that contains this.
|
MAC
|
Submission Required
|
|
Assigned
|
|
Carlos Aldana
|
5183
|
1000
|
Aldana, Carlos
|
E
|
N
|
1738.22
|
10.24.6.4
|
Replace "Burst Timeout" with "Burst Duration" in the Figure, as Burst Period is no longer defined. Do this for Figures 10-35 and 10-36 as well.
|
As in comment
|
EDITOR
|
Submission Required
|
EDITOR_A: 2015-05-03 02:50:56Z
|
Assigned
|
|
Carlos Aldana
|
5184
|
1000
|
Aldana, Carlos
|
T
|
N
|
1045.12
|
8.4.2.159
|
Since we would like to reduce the number of probe requests and use the Wide Bandwidth Channel Switch element in Neighbor Report without having to resort to transmission of either HT or
VHT Operations element, we should remove the 20 or 40 MHz ambiguity for the Channel Width=0 value.
|
Resolve this ambiguity in the Neighbor Report frame Wide Bandwidth Channel Switch subelement.
|
MAC
|
Submission Required
|
|
Assigned
|
|
Carlos Aldana
|
6778
|
1000
|
RISON, Mark
|
E
|
Y
|
1734
|
10.24.6
|
Fix the FTM figures to follow normal style (no colours, nice fonts, etc.)
|
As it says in the comment
|
EDITOR
|
Submission Required
|
EDITOR_A: 2015-05-03 02:52:10Z
|
Assigned
|
|
Carlos Cordeiro
|
5010
|
1000
|
Trainin, Solomon
|
T
|
Y
|
1515.46
|
9.38.7
|
Current definition does not address specifically a BRP response sent by separate link access. This case is different from the BRP response inside sequence that time of the BRP response
is unpredictable due to separate link access. Late BRP response may be inadequate to link conditions thus leading to wrong antenna configuration and performance losses.
|
Propose to define time control that an initiator may distinguish response arrived in time from late response.
|
MAC
|
Submission Required
|
|
Assigned
|
|
Carlos Cordeiro
|
5036
|
1000
|
Stephens, Adrian
|
T
|
Y
|
1209.42
|
8.6.20.11
|
"Zero or more Relay Capable STA Info fields". The structure is not unambiguously parseable because nothing indicates the length of this sequence of fields.
|
Either: 1) Remove the REDS feature entirely (because nobody will ever build it), or 2) make the structure parseable, such as by adding a count, or by including each Info field into a
new element.
|
MAC
|
|
|
Assigned
|
|
Carlos Cordeiro
|
5037
|
1000
|
Stephens, Adrian
|
T
|
Y
|
1210.45
|
8.6.20.13
|
"One or more Channel Measurement Info fields" -- The structure is not unambiguously parseable because nothing indicates the length of this sequence of fields.
|
Either: 1) Remove the REDS feature entirely (because nobody will ever build it), or 2) make the structure parseable, such as by adding a count, or by including each Info field into a
new element.
|
MAC
|
|
|
Assigned
|
|
Carlos Cordeiro
|
5040
|
1000
|
Stephens, Adrian
|
T
|
Y
|
1221.18
|
8.6.21.4
|
"The FSTS ID field contains" -- no size, structure or encoding is given for this field.
Ditto at 1221.53 and 1222.25.
|
Identify its size, structure and encoding.
|
MAC
|
|
|
Assigned
|
|
Carlos Cordeiro
|
5109
|
1000
|
Stephens, Adrian
|
T
|
Y
|
1264.1
|
9.3.2.12.3
|
In the case of transmission of a broadcast QoS frame by a DMG on different sectors, a STA may receive multiple copies of the same frame.
The duplicate detection logic does not attempt to detect these frames.
|
Allow also in RC1 QoS Data frames sent to a group address. Might also want to make this conditional on DMG, as the problem should not occur in the non-DMG case.
|
MAC
|
Discuss
|
MAC: 2015-05-08 23:21:23Z: MAH - Agree, assuming the commenter meant "the duplication logic should attempt to detect these frames, but it does not currently." So, the table needs an adjustment,
as suggested.
It does not seem this needs to be limited to DMG STAs, as it should never happen in any other scenario (and filtering it out if it does is not a bad side effect, anyway).
Also, this should apply to group addressed QoS frames, as well.
See also CID 5987, for the same resolution of a similar comment.
Propose: Revise. Change "A STA receiving frames that are not QoS Data," to "A STA receiving frames that are not QoS Data (individually or group addressed)," in RC1. Change "A QoS STA receiving an individually addressed QoSData frame," to "A QoS STA receiving
an (individually or group addressed) QoS Data frame," in RC2.
|
Assigned
|
|
Carlos Cordeiro
|
5164
|
1000
|
Stephens, Adrian
|
G
|
Y
|
1449.54
|
9.36.2
|
The "BHI" period is not explained in this subclause.
|
Add an explantion of the BHI terminology and what it comprises to the text.
|
MAC
|
|
|
Assigned
|
|
Carlos Cordeiro
|
5983
|
1000
|
TorabJahromi, Payam
|
T
|
Y
|
1512.58
|
9.38.6.4.1
|
Beam refinement after sector sweep requires channel access.
|
(1) Delete the word "immediately" in the following sentence: Beam refinement can start immediately following SLS (9.38.6.4.3 (Beam refinement transaction after SLS)).
(2) Specify channel access specifics, if any - e.g., if a certain AC need so be followed.
|
GEN
|
Submission Required
|
|
Assigned
|
|
Carlos Cordeiro
|
5987
|
1000
|
TorabJahromi, Payam
|
T
|
Y
|
1262.01
|
9.3.2.12
|
DMG groupcast frames may be physically transmitted in multiple directions and therefore can be received multiple times by a DMG STA. A duplicate detection mechanism needs to be defined
for DMG groupcast
|
Text will be provided, along the lines of defining a receive cache per group address.
|
MAC
|
Discuss
|
MAC: 2015-05-09 23:13:37Z - MAH - Agree. This is similar to CID 5109, which suggested resolving this with an adjustment to the receive cache table. The same resolution is proposed here.
It does not seem this needs to be limited to DMG STAs, as it should never happen in any other scenario (and filtering it out if it does is not a bad side effect, anyway).
Also, this should apply to group addressed QoS frames, as well.
Propose: Revise. Change "A STA receiving frames that are not QoS Data," to "A STA receiving frames that are not QoS Data (individually or group addressed)," in RC1. Change "A QoS STA receiving an individually addressed QoSData frame," to "A QoS STA receiving
an (individually or group addressed) QoS Data frame," in RC2.
|
Assigned
|
|
Carlos Cordeiro
|
6271
|
1000
|
RISON, Mark
|
T
|
Y
|
1457.6
|
9.36.6.5
|
It says "the time elapsed since a synchronizing reference event, in us, and is not greater than the beacon interval. The synchronizing event is the reception of the Timestamp field from
the AP or PCP" -- so what happens when two beacons are, due to contention, transmitted (a little) more than a beacon interval apart?
|
Delete ", and is not greater than the beacon interval" from the cited fragment
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
5062
|
1000
|
Stephens, Adrian
|
T
|
Y
|
3489.06
|
M.4.2
|
The invocation of hmac_sha1 at lines 4-5 includes a superfluous "digest," (the 2nd occurrence).
|
Change lines 4-5 to read: "hmac_sha1(digest, ssidlength+4, (unsigned char*) password, (int) strlen(password), digest1)"
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
5068
|
1000
|
Stephens, Adrian
|
G
|
N
|
104.16
|
4.5.4.4
|
"STA configured for mandatory data confidentialit" -- generally we reserve "mandatory" for things that the standard mandates. The cited text relates to configuration of the STA, which
is a local matter.
|
Reword to avoid "mandatory" and cite any necessary specific parameters of the STA that determine this condition.
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
5728
|
1000
|
Hunter, David
|
T
|
Y
|
1899.05
|
11.4.2.2
|
"Bit 5 indicates that an extended IV is present." How can a bit of unknown value (which is it, 0 or 1?) indicate anything?
|
Replace "Bit 5 indicates" with "The value of 1 in Bit 5 indicates".
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6106
|
1000
|
Hamilton, Mark
|
T
|
Y
|
1961.19
|
11.6.1.7.5
|
"PTKLen" should be "Length"
|
Change "PTKLen" to "Length"
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6183
|
1000
|
RISON, Mark
|
T
|
Y
|
2077
|
13
|
In "AEK <- KDF-256(PMK, "AEK Derivation", Selected AKM Suite ||" (2103.1) and "MTK <- KDF-Length(PMK, "Temporal Key Derivation", min(localNonce, peerNonce) ||" (2103.10) what is the hash
used?
|
Clarify (was PRF intended instead of KDF, perhaps?)
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6184
|
1000
|
RISON, Mark
|
T
|
Y
|
1865
|
11
|
In "KCK || PMK = KDF-512(keyseed, "SAE KCK and PMK"," (1884.56) and "TPK = KDF-Length(TPK-Key-Input, "TDLS PMK", min (MAC_I, MAC_R)" (1997.21) and "PMK = KDF-256(keyseed, "AP Peerkey
Protocol"," (2030.54) and "KDF-Length(pwd-seed, "SAE Hunting and Pecking", p)" (1880.48 and 1883.9) what is the hash used?
|
Clarify (was PRF intended instead of KDF, perhaps?)
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6190
|
1000
|
RISON, Mark
|
T
|
Y
|
1973.41
|
11.6.6.1
|
It says "FT Security Association" -- what's that?
|
Clarify (including adding the term to subclause 3.1 etc.); also make sure the words are lowercase
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6275
|
1000
|
RISON, Mark
|
T
|
Y
|
1960.07
|
11.6.1.7.3
|
It says "KDF-Hash-Length is the KDF as defined in 11.6.1.7.2 (Key derivation function (KDF)) used to generate a key of length 384 bits." but it's not being used to generate a key of length
384 bits, and it's not always 384 bits anwyay (see "Length" in the next para)
|
Delete "used to generate a key of length 384 bits" in the cited text
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6276
|
1000
|
RISON, Mark
|
T
|
Y
|
1959.6
|
11.6.1.7.3
|
It says "The PMK-R0 is the first level 256-bit keying material" but it's not always 256 bits (see "Q" on the next page)
|
Delete "256-bit" in the cited text
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6277
|
1000
|
RISON, Mark
|
T
|
Y
|
1960.33
|
11.6.1.7.3
|
It says "PMK-R0 shall be computed as the first 256 bits (bits 0--255) of the R0-Key-Data. The latter 128 bits of R0-Key-Data shall be used as the PMK-R0Name-Salt to generate the PMKR0Name."
but it's not always the first 256 bits (see "Q" above), and "latter 128 bits" is not grammatically correct
|
Delete the cited text (the correct formulation is the two equations at the top of the page)
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6278
|
1000
|
RISON, Mark
|
T
|
Y
|
1960.49
|
11.6.1.7.4
|
It says "PMK-R1, is a 256-bit key used to derive the PTK" but it's not always 256 bits (see "Length" below)
|
Delete "256-bit" in the cited text
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6280
|
1000
|
RISON, Mark
|
T
|
Y
|
1871.17
|
11.2.2.4.1
|
It says ""The WEP ICV shall be computed using the CRC-32, as defined in 8.2.4.7 (Frame Body field)" -- there is no definition of CRC-32 there or elsewhere
|
Since WEP is on death row, just replace "the" with "ITU-T" and delete from the comma onwards in the cited text
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6285
|
1000
|
RISON, Mark
|
T
|
Y
|
1895.5
|
11.4
|
It says "A DMG RSNA STA shall support GCMP." in the RSN overview (11.4.1) The CCMP equivalent, "A non-DMG RSNA STA shall support CCMP-128." is in the CCMP overview (11.4.3.1) and gives
the strength
|
Delete "A DMG RSNA STA shall support GCMP." at the referenced location and add "A DMG RSNA STA shall support GCMP-128." at the end of the first para of 11.4.5.1
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6293
|
1000
|
RISON, Mark
|
T
|
Y
|
1931.46
|
11.5.1.3.2
|
It says "A STA performing secure password-based, or PSK, authentication uses SAE authentication." -- SAE is not required
|
Change the cited text to "A STA performing secure password-based authentication uses PSK or SAE authentication."
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6345
|
1000
|
RISON, Mark
|
T
|
Y
|
1881.39
|
11.3.4.2.2
|
"r = (random() modulo (p -- 1) + 1" has a paren imbalance
|
Either delete the correct opening paren or add a closing paren in the correct location
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6349
|
1000
|
RISON, Mark
|
T
|
Y
|
103.13
|
4.5.4.3
|
It says "When the deauthentication service is terminating SAE authentication any PTKSA, GTKSA, mesh TKSA, or mesh GTKSA related to this SAE authentication is destroyed. If PMK caching
is not enabled, deauthentication also destroys any PMKSA created as a result of this successful SAE authentication." 1) What about deleting any IGTKSA? 2) Is this not duplicated at "In an RSNA, deauthentication also destroys any related..." a few lines below?
|
Delete the cited paragraph
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6358
|
1000
|
RISON, Mark
|
T
|
Y
|
1954.39
|
11.6.1.3
|
"A PMK identifier is defined as [...]" -- well no, not if the AKM is 00-0F-AC:5/6/11/12
|
Move to the end and say "Otherwise, the", or explicitly say "When the negotiated AKM is , the"
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6359
|
1000
|
RISON, Mark
|
T
|
Y
|
1957.33
|
11.6.1.6
|
"A SMK identifier is defined as [...]" -- well no, not if the AKM is 00-0F-AC:5/6. Also wrong article
|
Move to the end and say "Otherwise, the", or explicitly say "When the negotiated AKM is , the"
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6367
|
1000
|
RISON, Mark
|
T
|
Y
|
1880.57
|
11.3.4.2.2
|
In "base = new-random-number" what is new-random-number and why is it not italic?
|
Define the term and make it italic
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6393
|
1000
|
RISON, Mark
|
T
|
Y
|
1924.6
|
11.4.5.4.4
|
"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." appears for CCMP but not for GCMP. More generally, CCMP and GCMP do not seem quite aligned
|
Align GCMP and CCMP
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6394
|
1000
|
RISON, Mark
|
T
|
Y
|
1917.02
|
11.4.3.4.4
|
"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." -- what does this mean?
|
Add words to explain that the total number of TIDs sent under a given SA shall not exceed the number of replay counters identified by the recipient
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6398
|
1000
|
RISON, Mark
|
T
|
Y
|
1870.07
|
11.2.2.2
|
Figure 11-1 refers to a Note but it is not clear what note is intended (the one in the next subclause?)
|
Identify the note in question
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6412
|
1000
|
RISON, Mark
|
T
|
Y
|
1955.01
|
11.6.1.3
|
"NOTE 5---When the PMKID is calculated for the PMKSA as part of RSN preauthentication, the AKM has not yet been negotiated. In this case, the HMAC-SHA-1-128 based derivation is used for
the PMKID calculation." This does not sound like a NOTE, it sounds like something normative. Also, the term "RSN preauthentication" appears nowhere else
|
Delete the "NOTE 5---" and the "RSN"
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6421
|
1000
|
RISON, Mark
|
T
|
Y
|
2014
|
11.7
|
There are subclauses about mapping GTK to TKIP and CCMP keys, but what about to GCMP keys?
|
Add a subclause "Mapping GTK to GCMP keys"
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6455
|
1000
|
RISON, Mark
|
T
|
Y
|
1916.54
|
11.4.3.4.4
|
"The PN shall be implemented as a 48-bit monotonically incrementing non-negative integer," -- what does "monotonically incrementing" mean? I think 1, 1, 1, 1 is a monotonically increasing
(and monotonically decreasing, in fact), sequence
|
According to Wiki, if it never stays the same, it's "stricty increasing", so use that term instead
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6459
|
1000
|
RISON, Mark
|
T
|
Y
|
1865
|
11
|
What is the difference between an STSL and a TDLS link? The must be different because there's an STKSA and also a TPKSA
|
Clarify
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6507
|
1000
|
RISON, Mark
|
T
|
Y
|
2.58
|
1.4
|
"The construction of descriptions for uses of hash functions is: [HMAC-]SHA-[-n] where" -- this does not account for HMAC-MD5
|
Change the cited text to "The construction of descriptions for uses of hash functions is: [HMAC-]hash[-n] where hash is the name of the hash function," and make both "hash"es italic
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6509
|
1000
|
RISON, Mark
|
T
|
Y
|
1881.08
|
11.3.4.2.2
|
It says "KDF-z"; z is undefined
|
Change to "KDF-Length"
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6510
|
1000
|
RISON, Mark
|
T
|
Y
|
1883.24
|
11.3.4.3.2
|
It says "KDF-z"; z is undefined
|
Change to "KDF-Length"
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6511
|
1000
|
RISON, Mark
|
T
|
Y
|
2103.16
|
13.5.7
|
It says "KDF-X"; X is undefined
|
Change to "KDF-Length"
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6512
|
1000
|
RISON, Mark
|
T
|
Y
|
1954.41
|
11.6.1.3
|
"PMKID = HMAC-SHA-1-128(PMK, "PMK Name" || AA || SPA)" does not ensure the irretrievable deletion of the other bits
|
Change to "PMKID = Truncate-128(HMAC-SHA-1(PMK, "PMK Name" || AA || SPA))" and delete the "-128" in NOTE 5 below
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6513
|
1000
|
RISON, Mark
|
T
|
Y
|
1957.35
|
11.6.1.6
|
"SMKID = HMAC-SHA-1-128(SMK, "SMK Name" || PNonce || MAC_P || INonce || MAC_I)" does not ensure the irretrievable deletion of the other bits
|
Change to "SMKID = Truncate-128(HMAC-SHA-1(SMK, "SMK Name" || PNonce || MAC_P || INonce || MAC_I))"
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6521
|
1000
|
RISON, Mark
|
T
|
Y
|
1961.19
|
11.6.1.7.5
|
It says "KDF-Hash-PTKLen"; PTKLen is undefined (and the font is too big)
|
Change to "KDF-Hash-Length" and make the font size consistent
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6576
|
1000
|
RISON, Mark
|
T
|
Y
|
1930.12
|
11.5.1.1.10
|
It says "Since the Key ID 0 is reserved for individually addressed frame transmission, there are only three available Key IDs" -- this is not true when "Extended Key ID for Individually
Addressed Frames" is in effect
|
Amend the wording accordingly
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6625
|
1000
|
RISON, Mark
|
T
|
Y
|
1865
|
11
|
The security flowcharts use "!", which is not defined
|
Either change to NOT, or add the terminology to Subclause 1.5
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6680
|
1000
|
RISON, Mark
|
E
|
Y
|
1865
|
11
|
"An MPDU of type Data with the Protected Frame subfield of the Frame Control field equal to 1 is called a WEP MPDU." -- even if the standard is consistent when using this term, it's a
very confusing one now that other forms of protection are defined and indeed preferred.
|
Remove the term "WEP MPDU" or at least restrict it to MPDUs where WEP has indeed been used as the cipher
|
MAC
|
|
|
Assigned
|
|
Dan Harkins
|
6824
|
1000
|
RISON, Mark
|
T
|
Y
|
1865
|
11
|
There are about 30 references to "temporal keys" but the derivations only show a single temporal key. If the idea is that you can have one per key ID, then fine, but (a) make this clear
and (b) only use the plural in the contexts where you have more than one (e.g. talking about deleting any temporal keys).
|
As it says in the comment
|
MAC
|
|
|
Assigned
|
|
Edward Au
|
5249
|
1000
|
Hunter, David
|
E
|
Y
|
80.37
|
4.3.16.1
|
WNM-Notification is a capability, not a frame, field, element, etc., so its name does not require initial caps. In addition, similarly to "U-APSD coexistence", this name does not need
a hyphen.
|
When "WNM-Notification" is part of the name of a frame, field, element, etc. replace it with "WNM Notification" throughout the draft. Otherwise (such as line 37), replace it with "WNM
notification" throughout the draft.
|
EDITOR
|
Submission Required
|
EDITOR: 2015-04-28 07:14:04Z - "etc." is not sufficient instruction to the editor. Needs submission. I agree the name does not need a hyphen.
|
Assigned
|
|
Edward Au
|
5310
|
1000
|
Hunter, David
|
E
|
Y
|
738.35
|
8.4.2.20.6
|
"A Yes in the Extensible column": but what is in the column is "Yes" (in quotes because that is the symbol that is actually in the column).
|
Replace 'A Yes in the Extensible' with 'A "Yes" in the Extensible'.
|
EDITOR
|
Submission Required
|
EDITOR: 2015-05-01 15:23:09Z - TGmc telecon. No objection to making change to all 37.
EDITOR: 2015-04-28 08:58:50Z - There are 37 instances of "Yes in the Extensible" column, of which the commenter cites two in comments. Either change them all or change none.
|
Assigned
|
|
Edward Au
|
5311
|
1000
|
Hunter, David
|
E
|
Y
|
738.37
|
8.4.2.20.6
|
What could it possibly mean to say: "When the Extensible column of an element is equal to Subelements, then the subelement might be extended ..."? What element has a column in it? When
is a column equal to one or more subelements? One might guess that the reference is to a column that has a "Subelement" entry in it; however, a search doesn't turn up any "Subelement" entry in a cell in a column named "Extensible" of any table in clause 7.
|
If the intent is to say that the subelement whose name is in the row that contains "Yes" in the column headed "Extensible" is itself extensible, then say that more clearly. Otherwise
delete this sentence.
|
EDITOR
|
Submission Required
|
EDITOR: 2015-05-01 15:32:41Z - No objection to:
Globally Replace text that is similar to this "A Yes in the Extensible column of a subelement listed in Table 8- indicates that the subelement might be extended infuture revisions or amendments of this standard. When the Extensible column of an element is equal
to Subelements, then the subelement might be extended in future revisions or amendments of this standard by defining additional subelements within the subelement. See 9.27.9 (Extensible subelement parsing)."
TODO: make precise & find other comments related.
with
"The interpretation of the "Extensible" column is defined in 9.27.9."
EDITOR: 2015-05-01 15:32:31Z - Another comment says we shouldn't be repeating this thing over and over. There are ~37 instances of this text, and the commenter cites a couple.
For discussion: move the definition of "extensibility" to a subclause where the structure of a subelement is described. We can then put some effort into cleaning the text up.
|
Assigned
|
|
Edward Au
|
5318
|
1000
|
Hunter, David
|
E
|
Y
|
741.39
|
8.4.2.20.7
|
"A Yes in the Extensible column": but what is in the column is "Yes" (in quotes because that is the symbol that is actually in the column).
|
Replace 'A Yes in the Extensible' with 'A "Yes" in the Extensible'.
|
EDITOR
|
Submission Required
|
Resolve with CID 5311.
|
Assigned
|
|
Edward Au
|
5319
|
1000
|
Hunter, David
|
E
|
Y
|
741.41
|
8.4.2.20.7
|
What could it possibly mean to say: "When the Extensible column of an element is equal to Subelements, then the subelement might be extended ..."? What element has a column in it? When
is a column equal to one or more subelements? One might guess that the reference is to a column that has a "Subelement" entry in it; however, a search doesn't turn up any "Subelement" entry in a cell in a column named "Extensible" of any table in clause 7.
|
If the intent is to say that the subelement whose name is in the row that contains "Yes" in the column headed "Extensible" is itself extensible, then say that more clearly. Otherwise
delete this sentence.
|
EDITOR
|
Submission Required
|
EDITOR: 2015-05-28 11:43:46Z - Resolve with CID 5311.
|
Assigned
|
|
Edward Au
|
5693
|
1000
|
Hunter, David
|
E
|
Y
|
1767.51
|
10.24.17
|
What is the difference between "WNM-Notification and WNM notification? If there is no difference in function, then replace the name "WNM-Notification" with "WNM notification".
|
Replace: "WNM-Notification" with "WNM notification" throughout the text, except when it is part of the name of a frame, field, etc. and it uses initial caps: "WNM Notification".
|
EDITOR
|
Submission Required
|
The hyphen can be removed without issue. There are about 15 instances of WNM-Notification that should become WNM notification. And some capitalization that needs to be adjusted after
WNM-Notification. There is at least one other editorial comment on this topic.
|
Assigned
|
|
Edward Au
|
5694
|
1000
|
Hunter, David
|
E
|
Y
|
1767.57
|
10.24.17
|
"A STA that has a value of true for dot11WNMNotificationActivated is defined as a STA that supports WNM-Notification. A STA for which dot11WNMNotificationActivated is true shall set the
WNM-Notification Enabled field of the Extended Capabilities element to 1.": see the comments on 1536.37; the same problems dominate here (including using initial caps on the capability's name).
|
Replace:
"A STA that has a value of true for dot11WNMNotificationActivated is defined as a STA that supports WNM-Notification. A STA for which dot11WNMNotificationActivated is true shall set the WNM-Notification Enabled field of the Extended Capabilities element to
1."
With:
"A STA whose dot11WNMNotificationActivated value is true shall support WNM notification and shall set to 1 the WNM-Notification field of the Extended Capabilities elements that it transmits."
|
EDITOR
|
Submission Required
|
EDITOR: 2015-06-08 13:21:28Z - Making Assignee Edward, to handle with global changes to the terminology.
|
Assigned
|
|
Edward Au
|
5695
|
1000
|
Hunter, David
|
E
|
Y
|
1768.08
|
10.24.17
|
"WNM-Notification capability": this is not the name of a frame, field, element, etc., so it does not need initial caps.
|
On line 8 replace "WNM-Notification" with "WNM notification".
|
EDITOR
|
Submission Required
|
EDITOR: 2015-06-08 13:21:28Z - Making Assignee Edward, to handle with global changes to the terminology.
|
Assigned
|
|
Edward Au
|
5773
|
1000
|
Hunter, David
|
E
|
Y
|
2212.14
|
17.3.1
|
"PHY_CCA", "PHY_RXEND", "PHY_DATA" and "PHY_RXSTART": there are no such primitives.
|
Throughout the draft, including all of the related figures, replace "PHY_CCA" with "PHY-CCA", replace "PHY_RXEND" with "PHY-RXEND", replace "PHY_DATA" with "PHY-DATA", and replace "PHY_RXSTART"
with "PHY-RXSTART". It might be possible to search and replace "PHY_" with "PHY-" univarsally (but that still requires manual labor with the figures).
|
EDITOR
|
Submission Required
|
EDITOR: 2015-04-29 13:20:16Z
The following are instances of the misspelled primitives not in figures:
A.indication PHY_RXEND.indication (No_Error) PHY_CCA.indication (IDLE) Decremen
ble Receive the SIGNAL RX IDLE State CS/CCA or PHY_CCA Parity Fail PHY_CCA and PHY-CCA.indication(IDL
or supported mode Setup PSDU RX Set Length Set PHY_RXSTART .indication (RXVECTOR) RX Symbol Decode Symbo
for Signal Extension RX IDLE state CS/CCA Set PHY_CCA.indication(BUSY) HT_SIG (GF preamble) L-SIG (MF or non-HT pream
-SIG: Refer to 17.3.12 or 19.3.6 CRC Fail: Set PHY_RXEND .indication (FormatViolation) CRC OK Carrier
nal Length >0 Length=0 Time=0 End of Wait Set PHY_CCA. indication(IDLE) when receive level drops belo
ow threshold (missed preamble) End of Wait Set PHY_CCA .indication(IDLE) when receive level drops bel
e type Supported Preamble Unsupported mode: Set PHY_RXSTART .indication (RXVECTOR) then set PHY_RXEND .i
et PHY_RXEND .indication(Unsuppor tedRate) Set PHY_RXEND .indication(CarrierLost) Carrier Lost Set PHY_
RXEND .indication(CarrierLost) Carrier Lost Set PHY_RXEND .indication (CarrierLost) For unsupported mod
End of Wait For Reserved HT-SIG Indication: set PHY_CCA .indication(IDLE) when receive level drops bel
XEND .indication (RxEndStatus) End of Wait Set PHY_CCA .indication(IDLE). Set PHY_RXEND .indication
58 59 61 Figure 21-19—PHY transmit procedure PHY_TXSTART.request(TXVECTOR) MPDU Scrambling + encoding PHY_TXSTART.confirm
ted mode Setup PSDU RX Set N_symbols = NSYM Set PHY_RXSTART.indication (RXVECTOR) RX Symbol Decode Symbol Decode and
CCA.indication (IDLE) RX IDLE state CS/CCA Set PHY_CCA.indication(BUSY,primary) HT_SIG (HT GF preamble): Refer to 20.3.23 L-SI
Not VHT-SIG-A: Refer to 18.3.12 CRC Fail: Set PHY_RXEND.indication (FormatViolation) CRC OK Carrier lost Valid Si
d VHT-SIG-A Indication and Invalid L-LENGTH: Set PHY_RXEND.indication (FormatViolation) NOTE—This state machine does
as LDPC, STBC or partial AID. Carrier Lost: Set PHY_RXEND.indication (CarrierLost) Carrier Lost: Set PHY_RXEND.indi
XEND.indication (CarrierLost) Carrier Lost: Set PHY_RXEND.indication (CarrierLost) For unsupported modes, Reserved
TIME has elapsed. End of Wait Parity Fail: Set PHY_RXEND.indication (FormatViolation) RX VHT-SIG-B RX Supported m
fer to 20.3.23 Not HT-SIG Unsupported mode: Set PHY_RXSTART.indication (RXVECTOR) then set PHY_RXEND.indication (Unsu
Set PHY_RXSTART.indication (RXVECTOR) then set PHY_RXEND.indication (UnsupportedRate) Determine if PPDU is filtere
|
Assigned
|
|
Edward Au
|
6728
|
1000
|
RISON, Mark
|
E
|
Y
|
|
|
"the Sleep Mode element" needs "WNM-" added (and s lowercased). Sometimes "elements", which is suspect. Also follow-ons, e.g. references to "Sleep Mode Request" frames.
|
As it says in the comment
|
EDITOR
|
Submission Required
|
|
Assigned
|
|
Ganesh Venkatesan
|
6072
|
1000
|
Hamilton, Mark
|
T
|
Y
|
1312.24
|
9.13.4
|
Under GCR, an A-MPDU will contain an MPDU with group addressed RA. There are notes explaining that an HT (and VHT) AP can transmit an A-MPDU containing an MPDU with a group addressed
RA, but there is no note saying this is true for GCR APs (non-HT, included), also.
|
Add a "NOTE 3--An AP providing GCR service can transmit an A-MPDU containing MPDUs with a group addressed RA.
|
MAC
|
|
|
Assigned
|
|
Jouni Malinen
|
6024
|
1000
|
Malinen, Jouni
|
T
|
Y
|
1925.01
|
11.4.5.4.4
|
################
|
Add "The receiver shall discard MSDUs and MMPDUs whose constituent MPDU PN values are not sequential." to 11.4.5.4.4.
|
MAC
|
|
Submitted comment should say:
The PN and replay detection rules for GCMP have been specified in a way that is significantly different from the style used for CCMP. This is unfortunate since number of the rules are actually supposed to be identical due to the shared AAD design. It looks
like one of the important steps for the security of the design has been lost, i.e., GCMP does not protect against an attack related to fragmented frames while CCMP does. The key missing requirement for GCMP is this step from 11.4.3.4.4 (same subclause for
CCMP): "h) The receiver shall discard MSDUs and MMPDUs whose constituent MPDU PN values are not sequential."
It should be noted that the specific use of "sequential" here requires the PN to be incremented exactly by one (i.e., not skipping any PN). Without that interpretation, this would not protect against the attack where an attacker picks MPDUs from two different
fragmented MSDU/MMPDU and replaces the sequence number (not protected by AAD) to get the recipient accept these as an MSDU/MMPDU even though the data is from two different MSDU/MMPDU. Unfortunately, the other occurrences of "sequential" in both of these "PN
and replay detection" subclauses need to have different interpretation.. It would be good to reword these subclauses to address this small, but important, difference.
For background history on this special requirement for fragmented frames:
- text added for CCMP: https://mentor.ieee.org/802.11/dcn/03/11-03-0118-02-000i-alternate-text-for-tgi-8-3-4.doc
- motion on Slide 13 of https://mentor.ieee.org/802.11/dcn/03/11-03-0092-04-000i-ccmp-reorganization.ppt
- minutes: pages 30-32 of http://grouper.ieee.org/groups/802/11/Minutes/Cons_Minutes_Jan-2003.pdf
The specific attack:
Say, there are two MSDUs, each with two MPDUs:
MSDU_a(MPDU_a1, MPDU_a2), MSDU_b(MPDU_b1,MPDU_b2). An attacker prevents a STA from seeing MPDU_a2 and MPDU_b1 and MPDU_b2… and replays MPDU_b2 with SeqNum changed to be that of MPDU_a1. Without this "no-skipping-PNs-within-MSDU" rule, the recipient would have
accepted the invalid MSDU.
Since GCMP has the same AAD design (which does not protect seq#) as CCMP, it needs the same protection step for this case.
|
Assigned
|
|
Jouni Malinen
|
6239
|
1000
|
RISON, Mark
|
T
|
Y
|
1924.6
|
11.4.5.4.4
|
11.4.3.4.4 re CCMP PN and replay detection says that "The receiver shall discard MSDUs and MMPDUs whose constituent MPDU PN values are not sequential.", but no such statement appears
here for GCMP
|
Add such a statement here
|
MAC
|
|
|
Assigned
|
|
Jouni Malinen
|
6240
|
1000
|
RISON, Mark
|
T
|
Y
|
1924.6
|
11.4.5.4.4
|
The CCMP version of this subclause seems markedly different
|
Align the two subclauses, since they should be essentially the same
|
MAC
|
|
|
Assigned
|
|
Jouni Malinen
|
6564
|
1000
|
RISON, Mark
|
T
|
Y
|
|
|
What exactly does "sequential" mean? It seems to be intended to mean "increasing in steps of 1" but might be interpreted as just "increasing"
|
Clarify this, especially for 11.4.3.4.4.g
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5032
|
1000
|
Stephens, Adrian
|
T
|
Y
|
1219.22
|
8.6.21.2
|
"and precede all other elements that are vendor-specific elements that are part of the Last field in the Action frame."
The structure being described is the Action field. The vendor specific elements are not part of the action field, and so this reference is misleading.
|
Delete the entire sentence.
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5033
|
1000
|
Stephens, Adrian
|
T
|
Y
|
1220.27
|
8.6.21.3
|
"and precede all other elements that are vendor-specific elements that are part of the Last field in the Action frame."
The structure being described is the Action field. The vendor specific elements are not part of the action field, and so this reference is misleading.
|
Delete the entire sentence.
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5034
|
1000
|
Stephens, Adrian
|
T
|
Y
|
1205.38
|
8.6.20.4
|
The Vendor Specific element is not part of the Action field, but follows it.
Ditto at 1206.29.
|
Delete the Vendor specific row and the descriptive text.
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5035
|
1000
|
Stephens, Adrian
|
T
|
Y
|
1209.19
|
8.6.20.10
|
"The Destination REDS AID field is set to the AID of the target destination REDS" -- no size is given for this field.
|
Define the structure & size of this field.
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5039
|
1000
|
Stephens, Adrian
|
T
|
Y
|
1215.6
|
8.6.20.20
|
"The Sampling Frequency Offset field is reserved when set to 0" -- is internally self-contradictory, i.e. you need to test its value to determine whether its value should have been ignored.
|
Replace it with something meaningful, or delete the sentence.
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5060
|
1000
|
Stephens, Adrian
|
T
|
Y
|
1126.33
|
8.6.8.16
|
The reference in the "Notes" of the 20/40 BSS Coexistence" element is incorrect.
|
Change to 8.4.2.59.
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5095
|
1000
|
Stephens, Adrian
|
T
|
Y
|
1254.46
|
9.3.2.5
|
The "NAV (Fragment *)" shaded rectangles are misleading. They are shown as starting at the end of the Ack. In fact, they start at the end of the Fragment *.
|
Move the "NAV (Fragment 0)" block up and extend the left edge to align with the end of Fragment 0. Extend the left edge of "NAV (Fragment 1)" to align with the end of Fragment 1.
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5130
|
1000
|
Stephens, Adrian
|
G
|
Y
|
1313.19
|
9.13.5
|
"MPDUs in an A-MPDU carried in an HT PPDU shall be limited to a maximum length of 4095 octets.
A STA shall not transmit an MPDU in a VHT PPDU to a STA that exceeds the maximum MPDU length
capability indicated in the VHT Capabilities element received from the recipient STA."
These statements do not relate to the transport of A-MPDUs, but he formation of A-MPDUs from MDPUs.
|
Either change the heading to capture the actual purpose of this subclause or move these statements in a new sibling subclause "constraints on MPDUs carried in an A-MPDU".
|
MAC
|
Discuss
|
MAC: 2015-05-09 00:03:44Z: MAH - prefer the new subclause suggestion.
|
Assigned
|
|
Mark Hamilton
|
5137
|
1000
|
Stephens, Adrian
|
T
|
Y
|
1323.58
|
9.22.2.2
|
NOTE 4 talks about conditions b) or c) "for a secondary AC". But part of conditions b) and c) is that they are the primary AC. This is inconsistent.
|
Remove NOTE, or reword it to avoid references to b) and c).
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5141
|
1000
|
Stephens, Adrian
|
T
|
Y
|
1329.56
|
9.22.2.7
|
"All other channel access functions at the STA shall treat the medium as busy"
"treat the medium as busy" is underspecified. Better to include this in the definition of virtual carrier sense.
|
Add to 9.3.2.1 a statement that the virtual carrier sense indicates medium busy during the TXNAV duration and reference 9.22.2.7 for its definition.
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5234
|
1000
|
Gwynne, Gloria
|
E
|
N
|
1407.26
|
9.7.1
|
page 1287 of body. Unclear. Does "Higher layer protocols may negotiate a rate outside the mandatory rate set." apply only to OCB?
|
If only applies to OCB, say so: "STA in which dot11OCBActivated is true may attempt to negotiae ..." or "STA which is operating OCB may attempt to negotiate... " If not, add a carriage
return to separate into two paragraphs.
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5362
|
1000
|
Hunter, David
|
E
|
Y
|
839.08
|
8.4.2.29
|
"aggregated packet": this standard uses "packet" ambiguously, but the two defined meanings are clear: a packet is either a PPDU or a layer 3 (IETF definition) structure. The use of "packet"
on page 839 refers to neither.
|
Replace "packets" with "MPDUs".
|
MAC
|
|
EDITOR: 2015-04-28 12:55:54Z - Requires technical interpretation. Could mean A-MPDU and/or A-MSDU. Tranferred to MAC.
|
Assigned
|
|
Mark Hamilton
|
5398
|
1000
|
Hunter, David
|
T
|
Y
|
1089.22
|
8.6.2.2
|
"chosen ... to identify the request/report transaction.": implies that this procedure is a way for a sender to find a specific transaction. Instead the procedure is followed in order
to _provide an identifier_ for the current transaction.
|
Replace "to identify the" with "to provide an identifier for the specific"
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5542
|
1000
|
Hunter, David
|
E
|
Y
|
1638.16
|
10.8.5
|
"Any calculation ... shall cause the mitigation requirements for the channel in the current regulatory domain to be satisfied.": "shall cause" -- what kind of normative statement is that?
Technically, if those mitigation requirements just happen to be met (that is their satisfaction wasn't actually _caused_ by the calculation, then the STA fails this normative statement.
|
Replace "shall cause" with "needs to meet" and delete "to be satisfied". If those words don't sound regulatory enough, then replace "needs to meet" with "are required to meet" (and still
delete the "to be satisfied" at the end of the sentence.
|
MAC
|
|
EDITOR: 2015-04-29 07:32:23Z - Deletion of a "shall" may have a technical effect. Transferring to MAC.
|
Assigned
|
|
Mark Hamilton
|
5566
|
1000
|
Hunter, David
|
E
|
Y
|
1641.57
|
10.9.3
|
"setQuiet": typo.
|
On lines 57 and 60 and on page 1642 line 2 replace "setQuiet" with "set Quiet".
|
MAC
|
|
EDITOR: 2015-04-29 09:31:15Z - Transferring to MAC. I have changed the replacement text to match 624.51. However there might be a problem either at 624.51 or at 1050.24, because the meaning
of the AP Quiet Mode field does not appear to encompass use of this field set to 1 in IBSS, which is what 624.51 appears to require.
|
Assigned
|
|
Mark Hamilton
|
5571
|
1000
|
Hunter, David
|
T
|
Y
|
1644.32
|
10.9.7
|
"All measurement requests and reports are enabled by default.": this statement is inside a normative paragraph. Shouldn't this statement also be normative?
|
Replace "are enabled" with "shall be enabled".
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5573
|
1000
|
Hunter, David
|
T
|
Y
|
1644.42
|
10.9.8.1
|
"An attempt may be made to move a BSS to a new operating channel.": if this were actually a normative statement, it would be a passive normative -- with no indication of the subject;
can any STA do this, or in an infrastructure BSS just the AP, or...? But this is likely just an informative comment, so the "may" is misplaced.
|
Replace "An attempt may be made to move" with "A channel switch is an attempt to move".
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5584
|
1000
|
Hunter, David
|
T
|
Y
|
1646.01
|
10.9.8.3
|
"Each STA shall include a Channel Map field within the IBSS DFS elements that it transmits.": this implies _all_ such elements, but does not state the requirement directly. Also, once
again, the field is just _in_ the element.
|
Replace "field within the IBSS DFS elements" with "field in all IBSS DFS elements".
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5585
|
1000
|
Hunter, David
|
T
|
Y
|
1646.06
|
10.9.8.3
|
"is essential.": per the IEEE Style Manual requirements shall use "shall"/"should"/"may" and non-requirements should not appear to be requirements.
|
Replace (on line 5) "The ability to send" with "Each STA shall have the ability to send" and on line 6 delete "is essential".
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5586
|
1000
|
Hunter, David
|
T
|
Y
|
1646.08
|
10.9.8.3
|
"The potential for hidden nodes within an IBSS means that the IBSS channel switch protocol is best effort.": but protocols aren't best effort, or not; frame transmissions are best effort
or not. Also, "means that" is a type of hidden requirement.
|
Replace "The potential for hidden nodes within an IBSS means that the IBSS channel switch protocol is best effort."
with:
"Because of the potential for hidden nodes in an IBSS, the IBSS channel switch frames shall be transmitted best effort.."
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5587
|
1000
|
Hunter, David
|
T
|
Y
|
1646.1
|
10.9.8.3
|
"shall have an individual responsibility to cease transmission on a particular channel": don't know how we know whether an implementation has taken responsibility, much less individual
responsibility; and only on a particular channel, not every channel on which radar is detected?
|
Replace: "shall have an individual responsibility to cease transmission on a particular channel in the presence of radar."
with: "shall cease transmission on every channel on which radar has been detected."
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5596
|
1000
|
Hunter, David
|
T
|
Y
|
1647.16
|
10.9.8.3
|
"There are several circumstances when DFS owner recovery is required": "required" is a normative term that is out of place in an IEEE standard.
|
Replace: "recovery is required"
with: "recovery is needed"
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5617
|
1000
|
Hunter, David
|
T
|
Y
|
1648.5
|
10.9.8.4.3
|
"Announcement shall be set to the values identical to those in the received Channel Switch Announcement frame. The fields in the Mesh Channel Switch Parameters element shall be set to
the values identical to those in the received Mesh Channel Switch Parameters element, except for the Time To Live field": "identical to those" has a simpler alternative: "matching". And this paragaph is too long.
|
On lines 50 and 52 replace "the values identical to those in" with "the matching values in". On line 49 start a new paragraph with the sentence that begins "The fields in the Channel".
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5620
|
1000
|
Hunter, David
|
T
|
Y
|
1648.61
|
10.9.8.4.3
|
"and existing mesh peerings may be maintained in the new operating channel.": as long as the peers move to the new channel.
|
Replace "and existing mesh peerings may be maintained in the new operating channel." with "and, as long as the mesh peers move to the new operating channel, their peerings may be maintained
in the new channel."
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5621
|
1000
|
Hunter, David
|
T
|
Y
|
1649.02
|
10.9.8.4.3
|
"until a period of time equal to the ProbeDelay has transpired": but there is no such variable in the MLME. The only value of ProbeDelay available is that from the most recent invocation
by the SME of one of the three primitives: MLME-SCAN.request, MLME-JOIN.request, or MLME-START.request. In the current context (during a channel switch process) the appropriate primitive appears to be either the MLME-JOIN.request or the MLME-START.request,
so the text needs to specify either of those as the source of the value of the ProbeDelay parameter.
|
Replace "until a period of time equal to the ProbeDelay has transpired" with "until a period of time indicated by the ProbeDelay parameter (from the most recent SME invocation of either
the MLME-JOIN.request or the MLME-START.request) has transpired"
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5622
|
1000
|
Hunter, David
|
T
|
Y
|
1649.08
|
10.9.8.4.4
|
"the mesh STA is capable of operating in multiple operating classes": 'multiple" implies simultaneity - doubt that a mesh STA is capable of operating in several classes at once.
|
Replace "multiple" with "several".
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5623
|
1000
|
Hunter, David
|
T
|
Y
|
1649.17
|
10.9.8.4.4
|
"with behavior limits set of 16" and on line 21: "for which the behavior limits set listed in Annex E includes the value 16": as explained in Annex E, these references should be to 'behavior
limits 16" or "behavior limits set with the encoding 16 (see Table D-2)".
|
On line 17 replace "set of 16" with "set 16", and on lne 21 replace "listed iin Annex E includes the value 16;" with "listed in Annex E has the encoding 16 (see Annex D, Table D-2)."
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5625
|
1000
|
Hunter, David
|
T
|
Y
|
1649.26
|
10.9.8.5
|
"During a non-HT OBSS scan operation, the channel scan duration is a minimum of dot11OBSSScanPassiveTotalPerChannel TU": this really looks like the "is" should be a "shall be". Also the
total per channel TUs are likely to be more than 1, so replace "TU" with "TUs".
|
Replace "is a minimum" with "shall be a minimum" and on lines 27 and 28 replace "TU" with "TUs".
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5628
|
1000
|
Hunter, David
|
T
|
Y
|
1650.04
|
10.9.8.6
|
"to a new operating channel in a BSS shall be made": since this sublause is about DMG BSSs, should make that clear in this first sentence. Also, for clarification, "may make use of the
information in Supported Channel elements" should emphasize that the information is in received elements.
|
Replace "in a BSS" with "in a DMG BSS".
Replace "information in Supported Channel elements" with "information in received Supported Channel elements". Likewise, on line 11 replace "Announcement element in DMG Beacon frames" with "Announcement element in its transmitted DMG Beacon frames".
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
5631
|
1000
|
Hunter, David
|
T
|
Y
|
1650.29
|
10.9.9
|
"A Channel Switch Mode equal to 1 means that the STA in a BSS to which the frame containing the element is addressed shall transmit no further frames within the BSS until the scheduled
channel switch.": (1) this says nothing about the STA receiving this Channel Switch Mode field, but how else does the STA know?; (2) meaning is not the critical part of a requirement (the "if..then shall" is the critical part); (3) frames aren't addressed
to BSSs, but STAs in BSSs; (4) open question: this requirement only limits transmissions in a BSS - so the STA is still allowed to transmit (on the soon to be abandoned channel) Action frames to STAs outside the BSS?; (5) this requirement is mitigated by the
following that allows IBSS STAs to ignore this flag - so the "shall" is inaccurate in that case.
|
Replace:
"A Channel Switch Mode equal to 1 means that the STA in a BSS to which the frame containing the element is addressed shall transmit no further frames within the BSS until the scheduled channel switch."
with:
"If a STA in a BSS that is not an IBSS receives a Channel Switch Mode field that has the value 1, it shall not transmit any more frames to STAs in the BSS until the scheduled channel switch occurs."
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
6301
|
1000
|
RISON, Mark
|
T
|
Y
|
656.15
|
8.4.1.9
|
There's a "REFUSED_BASIC_RATES_MISMATCH" but there's nothing for HT-MCS or VHT-MCS+SS mismatch
|
Extend REFUSED_BASIC_RATES_MISMATCH to account for HT and VHT (5 instances)
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
6340
|
1000
|
RISON, Mark
|
T
|
Y
|
1088
|
8.6
|
"Vendor Specific" should not appear in $Foo frame Action field formats, since the VSIEs are in the Action frame not the Action field (per 8.3.3.13/14)
|
Remove vendor-specific elements at 1111.46, 1166.17, 1167.31, 1188.43, 1190.8, 1205.38, 1205.61, 1206.28, 1206.52,
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
6341
|
1000
|
RISON, Mark
|
T
|
Y
|
1088
|
8.6
|
"Vendor Specific" subelements are not needed in $Foo frame Action field formats, since the VSIEs can all be put at the end of the Action frame (per 8.3.3.13/14)
|
Remove vendor-specific subelements in subclause 8.6 (e.g. p 1114, 1127, 1183, 1184)
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
6342
|
1000
|
RISON, Mark
|
T
|
Y
|
1088
|
8.6
|
The $Foo frame Action field does not include VSIEs, MICEs or AMPEEs (per 8.3.3.13)
|
Remove those fields at 1188.43, 1190.8, 1191.7
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
6407
|
1000
|
RISON, Mark
|
T
|
Y
|
1180.61
|
8.6.14.25
|
"The Transmit Power Envelope element conveys the local maximum transmit power for various transmission bandwidths." -- this is already stated at 1047.3
|
Delete the cited text
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
6429
|
1000
|
RISON, Mark
|
T
|
Y
|
1306.36
|
9.7.12.2
|
The Tx Supported VHT-MCS and NSS Set is not used anywhere
|
Delete the referenced subclause
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
6503
|
1000
|
RISON, Mark
|
T
|
Y
|
1185.08
|
8.6.15.2
|
The length range for the TIM Element field is shown as 6-257. However, Figure 8-124 shows that the TIM Element has at most 5+251=256 octets
|
Change the upper limit to 256
|
MAC
|
|
|
Assigned
|
|
Mark Hamilton
|
6658
|
1000
|
RISON, Mark
|
E
|
Y
|
|
|
Change "VHT Operating" to "VHT Operation" at 1554.6.
Delete "carried within a frame" at 924.63. Delete "in a frame" at 1823.64, 1824.35.
Change "in a frame" to "in a Beacon frame or a Probe Response frame" at 1823.58.
Change 1527.20 from "if the Request element of the Probe Request includes the RCPI element ID" to "if there is a Request element in the Probe Request that includes the RCPI element ID".
[References might be to D3.0 rather than D4.0]
|
As it says in the comment
|
MAC
|
|
EDITOR: 2015-04-30 14:36:21Z - Transferring to MAC. These are not editorial changes.
|
Assigned
|
|
Mark Hamilton
|
6721
|
1000
|
RISON, Mark
|
T
|
Y
|
|
|
Does "pre-VHT" need defining?
|
Add a definition of the term
|
MAC
|
|
MAC: 2015-05-11 00:33:42Z: MAH - agree, but it is simpler. The usage appears only in clause 22, and only for "pre-VHT modulated fields". The meaning of this is described on P2494.49 (and
the NOTE at P2489.56). That description just needs to be sooner, and clearer, within clause 22.
|
Assigned
|
|
Mark Rison
|
6305
|
1000
|
RISON, Mark
|
T
|
Y
|
|
|
There is a zoo of inconsistent terminology for "carrier sense", whch makes it hard to understand exactly what is meant where and how the various PHYs compare: CS, CCA, CS/CCA, energy
detect, ED, PHYED, CCA-ED, CCA Mode 1-5
|
First rename CCA-ED to PHYRED (regulatory ED). Then call the ED which everybody uses PHYED, and the preamble detect PHYPD. Call the combination of things which yield the PHY part of "carrier
sense" PHYCS. Kill the terms CS, CCA, CS/CCA, CCA Mode, ED. Make it clear how "I'm currently transmitting" fits into "carrier sense", and whether "I've received the PPDU header so I know how long to consider the medium busy even though the energy has gone
away" is considered part of PHYCS or part of MACCS/virtual CS
|
GEN
|
Submission Required
|
|
Assigned
|
|
Mark Rison
|
6308
|
1000
|
RISON, Mark
|
T
|
Y
|
|
|
18.3.10.6 CCA requirements says: "For improved spectrum sharing, CCA-ED is required in some bands. The behavior class indicating CCA-ED is given in Table D-2 (Behavior limits sets). The
operating classes requiring the corresponding CCA-ED behavior class are given in E.1 (Country information and operating classes). A STA that is operating within an operating class that requires CCA-ED shall operate with CCA-ED. Unless required by regulation,
the CCA-ED shall not be required for license-exempt operation.
CCA-ED shall indicate a channel busy condition when the received signal strength exceeds the CCA-ED threshold as given by dot11OFDMEDThreshold. The CCA-ED thresholds for the operating classes requiring CCA-ED are subject to the criteria in D.2.5 (CCA-ED threshold)."
D.2.5 CCA-ED threshold says: "CCA-ED thresholds for operation in specific bands are given in E.2 (Band-specific operating requirements) where they differ from the values in PHY clauses."
So the OFDM PHY refers you to D.2.5 which refers you to E.2 except where the answer is the same as in the PHY clause ... but that's where you started!
|
Break the infinite loop. Define the CCA-ED thresholds in one place only
|
GEN
|
Submission Required
|
|
Assigned
|
|
Mark Rison
|
6335
|
1000
|
RISON, Mark
|
T
|
Y
|
1219.18
|
8.6.21.2
|
"One or more elements are present in this frame" -- need to explicitly list which those are, and their order
|
As it says in the comment (see also CID 3499)
|
MAC
|
Submission Required
|
|
Assigned
|
|
Mark Rison
|
6337
|
1000
|
RISON, Mark
|
T
|
Y
|
1220.24
|
8.6.21.3
|
"One or more elements can appear in this frame." -- need to explicitly list which those are, and their order
|
As it says in the comment (see also CID 3499)
|
MAC
|
Submission Required
|
|
Assigned
|
|
Mark Rison
|
6338
|
1000
|
RISON, Mark
|
T
|
Y
|
1205.57
|
8.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." -- need to explicitly list which
those are, and their order
|
As it says in the comment (see also CID 3499)
|
MAC
|
Submission Required
|
|
Assigned
|
|
Mark Rison
|
6339
|
1000
|
RISON, Mark
|
T
|
Y
|
1206.48
|
8.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." -- need to explicitly list which
those are, and their order
|
As it says in the comment (see also CID 3499)
|
MAC
|
Submission Required
|
|
Assigned
|
|
Mark Rison
|
6376
|
1000
|
RISON, Mark
|
E
|
Y
|
1593
|
10.3.5
|
There are numerous editorial and consistency issues with the description of the AP/PCP (re)assoc receipt procedures
|
I will propose text (not possible to give here)
|
EDITOR
|
Submission Required
|
EDITOR_A: 2015-05-02 01:11:09Z Need submission from Mark Rison.
|
Assigned
|
|
Mark Rison
|
6404
|
1000
|
RISON, Mark
|
E
|
Y
|
591.37
|
8.2.5.2
|
The first para of 8.2.5.2 is full of horrors
|
I will propose text (not possible to give here)
|
EDITOR
|
Submission Required
|
|
Assigned
|
|
Mark Rison
|
6422
|
1000
|
RISON, Mark
|
T
|
Y
|
|
|
Get rid of the BSS basic VHT set stuff in the same way the BSS basic HT set stuff was gotten rid of in CID 2010
|
As it says in the comment
|
MAC
|
Submission Required
|
MAC: 2015-05-11 00:28:44Z: MAH - need a submission to get all the details.
Note that the resolution to CID 2010 (which is to adopt the changes in 11-14/207r3 for CID 2010) already has a number of changes for the VHT material, included. So, the comment needs to be clarified as to exactly what changes done for HT (only) should now be
done for VHT.
|
Assigned
|
|
Mark Rison
|
6426
|
1000
|
RISON, Mark
|
T
|
Y
|
1262.53
|
9.3.2.12.3
|
"When a Data, Management or Extension frame is received in which the Retry subfield of the Frame Control field is equal to 1, the appropriate cache is searched for a matching frame. If
the search is successful, the frame is considered to be a duplicate." -- this does not apply when an MSDU is sent under a BA agreement, since the Retry bit need not be set and in any case the BA bitmap is consulted to look for dupes, not the cache
|
Amend the wording accordingly
|
MAC
|
Discuss
|
MAC: 2015-05-09 23:19:22Z: MAH - Disagree. The text at the start of 9.3.2.12 says, "Additional duplicate filtering is performed during Receive Buffer Operation for frames that are part
of a block ack agreement". This indicates that the receiver cache filtering _is_ done under Block Ack agreement (although only if the Retry bit is equal to 1). If the Retry bit really can never be equal to 1 under Block Ack, then the receiver cache text is
moot, per the sentence the commenter quoted, so no change is needed. If the Retry bit can ever be equal to 1 under Block Ack, then the question is whether the receiver cache would falsely discard a valid (non-duplicate) frame. There does not seem to be such
a problem case, so again, it is equivalent function to invoke the receiver cache or not, along with the Block Ack processing rules, and no change is necessary.
See also CID 6490.
Propose: Reject.
|
Assigned
|
|
Mark Rison
|
6442
|
1000
|
RISON, Mark
|
T
|
Y
|
1248.45
|
9.3.2.3.1
|
The spec says things like "immediate response" and "immediately following" and "immediately after" but does not state what this means. In general, it seems to mean "after SIFS", but in
some contexts this is not the case (e.g. 1409.49)
|
Delete the first para of 8.3.1.1 "In the following descriptions, "immediately previous" frame means a frame whose reception concluded
within the SIFS preceding the start of the current frame." and instead add something somewhere generic (maybe 9.3.2.3.1) the following: "In this standard, unless indicated otherwise, an "immediate response" (or similar constructs with "immediately") is one
which occurs SIFS after the frame causing the response, and an "immediately previous frame" (or similar constructs) is one whose reception concluded a SIFS before the start of the current frame."
|
MAC
|
Discuss
|
MAC: 2015-05-09 23:31:51Z: MAH - Propose Reject.
There are 175 instances of "immediately" (many of which are used in a completely different sense), and 306 of "immediate" (many of which are clearly not related to this comment). As a result, any globally applied meaning would have to be crafted very carefully
so as to not include unintended contexts. (Note, especially, use in clause 10, PHY clauses, Annex S, etc.)
Further, by removing the text from clause 8, and putting an "instructions for interpretation" type of sentence deep with a subclause of clause 9, is going to leave readers of clause 8 hopelessly confused. This change would need to be 1.4, or somewhere similar
- which compounds the concern stated above.
Thus, a global statement applied to the meaning of "immediate" or "immediately" seems overly dangerous.
Further, the commenter has not identified specific changes that are needed, to enable individual, localized changes that would resolve the comment.
|
Assigned
|
|
Mark Rison
|
6452
|
1000
|
RISON, Mark
|
T
|
Y
|
1260.38
|
9.3.2.9
|
How does EIFS (= aSIFSTime + ACKTxTime + DIFS) work if the ack timeout (= aSIFSTime + aSlotTime + aRxPHYStartDelay) is a significant fraction of it, in the case where the Ack is corrupted?
|
At 1260.38, after "In this instance, the STA shall
invoke its backoff procedure at the PHY-RXEND.indication primitive and may process the received frame" add "NOTE---If a frame with an incorrect FCS is received, EIFS is used in the course of this backoff procedure (see 9.3.2.3.7)."
|
MAC
|
Discuss
|
MAC: 2015-05-09 23:43:21Z: MAH - Propose: Reject. While this note is true, it is true for many cases. That is, when the backoff procedure is invoked, the idle medium sensing time for
that procedure is based on the rules in the procedure, which may or may not include the Ack Timeout interval. It does seem useful to try to list them all, or to specifically call out only this one.
|
Assigned
|
|
Mark Rison
|
6482
|
1000
|
RISON, Mark
|
T
|
Y
|
1248.21
|
9.3.2.1
|
"AirDelay is aAirPropagationTime indicated in the
Coverage Class field of the Country element received from the AP of the BSS with which the STA is
associated or the DO of the IBSS of which the STA is a member or from another mesh STA in the same
MBSS, or if no Country element has been received from the AP of the BSS with which the STA is associated,
the value of aAirPropagationTime indicated in the PLME-CHARACTERISTICS.confirm primitive." is circular, because the PLME-CHARACTERISTICS.confirm gets info from the PHY characteristics, and the PHYs say "As indicated by the coverage class (see 9.21.4 (Operation
with coverage
classes))."
|
This would probably best be fixed in 9.21.4. Perhaps "The default PHY parameters are based on aAirPropagationTime having a value of 0 us" could be changed to something like "When dot11OperatingClassesRequired
is false, or the aAirPropagationTime is not available from a Country element, the aAirPropagationTime shall be taken to be 0 us"
|
MAC
|
Submission Required
|
|
Assigned
|
|
Mark Rison
|
6490
|
1000
|
RISON, Mark
|
T
|
Y
|
1262.47
|
9.3.2.12.3
|
This subclause does not cover BA, where a SN cache is not consulted (a BA bitmap window is consulted), even if the Retry bit is set (1262.53)
|
Add words to that effect
|
MAC
|
Discuss
|
MAC: 2015-05-09 23:54:45Z: MAH - Disagree. The text at the start of 9.3.2.12 says, "Additional duplicate filtering is performed during Receive Buffer Operation for frames that are part
of a block ack agreement". This indicates that the receiver cache filtering _is_ done under Block Ack agreement (although only if the Retry bit is equal to 1). If the Retry bit really can never be equal to 1 under Block Ack, then the receiver cache text is
moot, per the sentence the commenter quoted, so no change is needed. If the Retry bit can ever be equal to 1 under Block Ack, then the question is whether the receiver cache would falsely discard a valid (non-duplicate) frame. There does not seem to be such
a problem case, so again, it is equivalent function to invoke the receiver cache or not, along with the Block Ack processing rules, and no change is necessary.
See also CID 6426.
Propose: Reject.
|
Assigned
|
|
Mark Rison
|
6496
|
1000
|
RISON, Mark
|
T
|
Y
|
1250.16
|
9.3.2.3.3
|
Does the SIFS 10% of aSlotTime include aAirPropagationTime too? Seems large. There is no need to allow for 10% of the aAirPropagationTime as a STA's timing accuracy is independent of
the aAirPropagationTime
|
Change to 10% of aSlotTime - aAirPropagationTime (2x in this subclause). See also 9.3.2.1's 10% and the 10%s in 9.3.2.3.10 and 9.3.2.3.11
|
MAC
|
Discuss
|
MAC: 2015-05-09 23:57:54Z: MAH: Needs discussion. Note that this measurement is specified with this phrase, "shall not allow the space between frames that are defined to be separated
by a SIFS, as measured on the medium, to vary from the nominal SIFS by more than ±10% of aSlotTime".
Since this is "as measured on the medium", but there is no indication of _where_ on the medium it is measured, it is quite possible that aAirPropagationTime (even aAirPropagationTime x 2) will come into effect within the measurement. How does this affect the
perceived conformance of the implementation being measured?
|
Assigned
|
|
Mark Rison
|
6583
|
1000
|
RISON, Mark
|
E
|
Y
|
|
|
"All other bits are reserved, and are set to 0 on transmission and ignored on reception."; "the WEP Key ID subfield in the MPDU shall be set to 0 on transmit and ignored on receive.";
"Bits 5 to 7 of the Nonce Flags field are reserved and shall be set to 0 on transmission."; "The reserved bits shall be set to 0 and shall be ignored on reception."; "If the value of Key Type (bit 3) is 0, then this bit shall be 0 on transmit and ignored on
receive. "; "It shall be set to 0 on transmit and ignored on receive."
|
Simplifiy all of these to a statement of the form to "x is reserved", except the one which just says to set reserved bits to 0 on tx and ignore on rx, which can just be deleted.
Note, however, that the statement that reserved bits are set to 0 on tx and ignored on rx is only made within the scope of clause 8, so this needs to be widened to cover other clauses
|
MAC
|
Submission Required
|
EDITOR: 2015-04-30 13:07:54Z - Submission required. Transferring to MAC.
|
Assigned
|
|
Mark Rison
|
6719
|
1000
|
RISON, Mark
|
T
|
Y
|
|
|
"used together with an operating class number" -- not for non-TVHT. Also say primary upper should match SCO. Also how is primary position specified for VHT? Also get rid of unused behaviours.
Also restrict the "defined by regulations" stuff explicitly to just TVHT and explain because of differening widths. Also what is 80+ for?
|
I will propose text once I've worked out what I was going on about
|
MAC
|
Submission Required
|
|
Assigned
|
|
Mark Rison
|
6733
|
1000
|
RISON, Mark
|
E
|
Y
|
|
|
Ref. to "8.4.2.21.10" in new BSSID stuff -- caption does not say "LCI report" nor "Location configuration information" nor "field" etc.
|
I will propose text once I've worked out what I was going on about
|
EDITOR
|
Submission Required
|
|
Assigned
|
|
Mark Rison
|
6775
|
1000
|
RISON, Mark
|
T
|
Y
|
|
|
"1-127" for rate sets is bogus because 127 and 126 are not rates but HT/VHT selectors
|
Either change to 1-125 or rename the parameter to refer to "rate set and BSS selector"
|
MAC
|
Discuss
|
MAC: 2015-05-11 15:16:19Z: MAH. Assumedly, this is referencing the occurance of "1-127" as the Valid range for several rate set parameters to some MLME primitives.
Propose: Reject. There is no normative text that specifies that the values 126 and 127 cannot be used as rate values in these rate sets. While it is logical that these values should be excluded, so they can be unambiguously used as BSS Membership Selectors,
a larger change is needed to accomplish this without creating inconsistency within the Standard.
|
Assigned
|
|
Mark Rison
|
6814
|
1000
|
RISON, Mark
|
T
|
Y
|
1321
|
9.22.2.1
|
Where is the stuff which explains how stuff is taken off queues? Is it just that each queue is a pseudo-STA fed MSDUs one at a time? That would still require a statement that a new MSDU
is not fetched if a previous one is outstanding
|
Add something about how/when items are taken off queues
|
MAC
|
Submission Required
|
MAC: 2015-05-12 06:00:00Z: MAH - Agreed. Need submission to get this right.
|
Assigned
|
|
Matthew Fischer
|
5133
|
1000
|
Stephens, Adrian
|
G
|
Y
|
1311.48
|
9.13.2
|
"A STA shall not transmit a VHT PPDU if the PPDU duration exceeds aPPDUMaxTime defined in Table 22-29
(VHT PHY characteristics).
NOTE--This restriction limits the maximum value in the LENGTHfield in the L-SIG field of a VHT PPDU to 4095.
A STA shall not transmit a VHT PPDU in TVWS bands if the PPDU duration exceeds aPPDUMaxTime
(defined in Table 23-25 (TVHT PHY characteristics)). "
These statements would better live in 9.14.
|
Move cited text to 9.14.
|
MAC
|
|
|
Assigned
|
|
Matthew Fischer
|
5866
|
1000
|
Schelstraete, Sigurd
|
T
|
N
|
587.37
|
8.2.4.7.1
|
The max PSDU size for VHT PPDU (fourth column) may be wrong. There is a separate comment on Table 22-29. Outcome of that comment resolution should be reflected in this Table 8-19.
|
See comment
|
MAC
|
|
|
Assigned
|
|
Matthew Fischer
|
5868
|
1000
|
Schelstraete, Sigurd
|
T
|
N
|
595.61
|
8.3.1.2
|
"In an RTS frame transmitted by a VHT STA in a non-HT or non-HT duplicate format and where the scrambling sequence carries the TXVECTOR parameters CH_BANDWIDTH_IN_NON_HT and DYN_BANDWIDTH_IN_NON_HT
(see 9.3.2.6 (VHT RTS procedure)), the TA field is a bandwidth signaling TA."
Is there any other case where the use of bandwidth signaling TA is allowed? If not, make this explicit.
|
Suggested wording, to be added at end of paragraph: "A bandwidth signaling TA shall not be used in any other case"
|
MAC
|
|
|
Assigned
|
|
Matthew Fischer
|
5873
|
1000
|
Schelstraete, Sigurd
|
T
|
N
|
611.56
|
8.3.1.20
|
"The TA field is set to the address of the STA transmitting the VHT NDP announcement frame or a bandwidth signaling TA" should be more specific. It's not just any signaling TA, but the
specific signaling TA that is obtained by setting the Individual/Group bit of the address of the transmitting STA to one.
|
Suggested wording: "The TA field is set to the address of the STA transmitting the VHT NDP announcement frame or the bandwidth signaling TA that is obtained by setting the Individual/Group
bit in that address to one"
|
MAC
|
|
|
Assigned
|
|
Matthew Fischer
|
5874
|
1000
|
Schelstraete, Sigurd
|
T
|
N
|
611.57
|
8.3.1.20
|
"In a VHT NDP Announcement frame transmitted by a VHT STA in a non-HT or non-HT duplicate format and where the scrambling sequence carries the TXVECTOR parameter
CH_BANDWIDTH_IN_NON_HT, the TA field is set to a bandwidth signaling TA."
Is there any other case where the use of bandwidth signaling TA is allowed? If not, make this explicit.
|
Suggested wording, to be added at end of paragraph: "A bandwidth signaling TA shall not be used in any other case"
|
MAC
|
|
|
Assigned
|
|
Matthew Fischer
|
5885
|
1000
|
Schelstraete, Sigurd
|
T
|
N
|
1311.48
|
9.13.2
|
Lines 48-55 deal with the maximum PPDU duration. This text belongs in Clause 9.14 (PPDU duration constraint), which contains similar text for HT and DMG STAs.
|
Move lines 48-55 to Clause 9.14
|
MAC
|
|
|
Assigned
|
|
Matthew Fischer
|
5886
|
1000
|
Schelstraete, Sigurd
|
T
|
N
|
1311.51
|
9.13.2
|
NOTE is incorrect. The LENGTH field in L-SIG is limited to 4095 because it is 12 bits long. It is the max value of the LENGTH field that determines the max VHT PPDU size, not the other
way round.
|
Delete NOTE
|
MAC
|
|
|
Assigned
|
|
Matthew Fischer
|
5892
|
1000
|
Schelstraete, Sigurd
|
T
|
N
|
1316.09
|
9.16
|
A statement similar to the first paragraph should be included for VHT transmisisons.
|
Add LDPC requirement for VHT.
|
MAC
|
|
|
Assigned
|
|
Matthew Fischer
|
5894
|
1000
|
Schelstraete, Sigurd
|
T
|
N
|
1329.14
|
9.22.2.7
|
The words "followed after SIFS by a PPDU containing one or more VHT Compressed Beamforming frames" belong with the second sub-bullet
|
Second sub-bullet should be: "a Beamforming Report Poll frame followed after SIFS by a PPDU containing one or more VHT Compressed Beamforming frames"
|
MAC
|
|
|
Assigned
|
|
Matthew Fischer
|
5900
|
1000
|
Schelstraete, Sigurd
|
T
|
N
|
1424.63
|
9.32.3
|
This section should not have requirements on VHT beamformee. Delete paragraph or move to appropriate section.
|
See comment
|
MAC
|
|
|
Assigned
|
|
Matthew Fischer
|
5901
|
1000
|
Schelstraete, Sigurd
|
T
|
N
|
1427.23
|
9.23.3
|
It would make sense to have a section on explicit feedback beamforming for VHT after clause 9.32.3
|
Add section "Explicit feedback beamforming for VHT" to clarify that Explicit feedback beamforming with immediate feedback is the only allowed format for VHT.
|
MAC
|
|
|
Assigned
|
|
Matthew Fischer
|
5959
|
1000
|
Fischer, Matthew
|
T
|
Y
|
512.45
|
6.3.103.3.2
|
The MLME-ESTIMATED-THROUGHPUT.confirm needs to have an uplink estimate in addition to the downlink estimate. The existing estimate could be improved. Some management pieces are missing
to allow the estimated throughput to be computed. A MIB variable is needed to correspond to the functionality.
|
A presentation will be provided to address these and other issues related to the estimated throughput MLME SAP.
|
MAC
|
Submission Required
|
|
Assigned
|
|
Matthew Fischer
|
5960
|
1000
|
Fischer, Matthew
|
T
|
Y
|
1306.06
|
9.7.12.1
|
Some implementations could have a maximum VHT NSS value that is dependent on the bandwidth of operation. Signaling to support this behavior is desired. Specifically, there is likely to
be a difference between maximum NSS support for the 80+80 and 160 MHz bandwidths vs the 20, 40 and 80 MHz bandwidths.
|
Provide the necessary signaling to allow bandwidth dependent maximum VHT NSS values to be indicated. A presentation will be provided with specific details as to how to accomplish this.
Propagate the changes to TVHT.
|
MAC
|
Submission Required
|
|
Assigned
|
|
Matthew Fischer
|
6221
|
1000
|
RISON, Mark
|
T
|
Y
|
611.49
|
8.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
|
Make the AID12 subfield reserved in that case (also, there is no AID in the STA Info field, to be pedantic)
|
MAC
|
|
|
Assigned
|
|
Matthew Fischer
|
6242
|
1000
|
RISON, Mark
|
T
|
Y
|
1316.01
|
9.16
|
Nothing seems to stop a VHT STA sending a VHT PPDU using LDPC to a STA which doesn't support this
|
Add a para "A VHT STA shall not transmit a frame with the TXVECTOR parameter FORMAT set to FTM and the TXVECTOR parameter FEC_CODING set to LDPC_CODING unless the RA of the frame corresponds
to a VHT STA for which the Rx LDPC subfield of the VHT Capabilities element received from that STA contained a value of 1 and dot11VHTLDPCCodingOptionActivated is true.". Change "a STA" to "an HT STA" at 1316.6
|
MAC
|
|
|
Assigned
|
|
Matthew Fischer
|
6250
|
1000
|
RISON, Mark
|
T
|
Y
|
617.45
|
8.3.2.2.2
|
"The maximum MPDU length that can be transported using A-MPDU aggregation is 4095 octets for non-DMG STAs" is not true for VHT STAs; nor is "Therefore, a non-DMG STA cannot
transport an A-MSDU of a length that exceeds 4065 octets"
|
Add "non-VHT" before "non-DMG" in both cited fragments
|
MAC
|
|
|
Assigned
|
|
Matthew Fischer
|
6251
|
1000
|
RISON, Mark
|
T
|
Y
|
616.05
|
8.3.2.1
|
"When the frame body carries an A-MSDU, the size of the frame body field is
limited by:
[...]
If A-MPDU aggregation is used, a maximum MPDU length of 4095 octets" is not true for VHT or DMG STAs
|
Add "at at non-VHT non-DMG STA" after "used"
|
MAC
|
|
|
Assigned
|
|
Matthew Fischer
|
6388
|
1000
|
RISON, Mark
|
T
|
Y
|
1045.23
|
8.4.2.158
|
Is an 80+80 MHz transmission always a "non-contiguous" one? Although 22.1.1 hints that it is ("The VHT PHY provides support for 20 MHz, 40 MHz, 80 MHz, and 160 MHz contiguous channel
widths and support for 80+80 MHz noncontiguous channel width.") nothing in the spec prevents a VHT AP from setting in the VHT Operation Information field:
* Channel Width to indicate 80+80
* Channel Center Frequency Segment 0 to be a segment adjacent to Channel Center Frequency Segment 1
It doesn't help that the adjective "noncontiguous" (sic) only sometimes appears with "80+80" (and ditto with "contiguous" and "160")
|
Add a sentence (the one shown between asterisks) to the bottom right cell of Table 8-242 at 1045.23 as follows: "For an 80+80 MHz operating channel width, indicates the channel center
frequency index of the 80 MHz channel of frequency segment 1 on which the VHT BSS operates. ***The channel center frequency index of segment 1 differs by more than 16 from the channel center frequency index of segment 0 (i.e. the channel center frequencies
are more than 80 MHz apart).*** Reserved otherwise."
Change "noncontiguous 80+80" to "80+80" throughout the spec except in 22.1.1 (about 26 instances).
Change "contiguous 160" to "160" throughout the spec except in 22.1.1 (about 15 instances)
|
MAC
|
|
|
Assigned
|
|
Matthew Fischer
|
6471
|
1000
|
RISON, Mark
|
T
|
Y
|
1410.03
|
9.31.2
|
"MRQs shall not be sent to STAs that have not advertised support for link adaptation." is not very precise. The VHT formulation at 1411.57, "A STA shall not send an MRQ to STAs that have
not set VHT Link Adaptation Capable subfield to Both in the VHT Capabilities Info field of the VHT Capabilities element." is better
|
Change the referenced sentence to "A STA shall not send an MRQ to STAs that have not set the MCS Feedback subfield to Both in the HT Extended Capabilities field of the HT Capabilities
element."; also add the missing "the" after "set" in the cited VHT text
|
MAC
|
|
|
Assigned
|
|
Matthew Fischer
|
6492
|
1000
|
RISON, Mark
|
T
|
Y
|
|
|
9.7.6.1: "Control frames carried in an A-MPDU that does not contain a VHT single MPDU shall be sent at a rate selected from the rules defined in 9.7.5.7"
9.7.5.7: is basically about Data and Management frames, though "The rules in this subclause also apply to A-MPDUs that aggregate MPDUs of type Data or Management with any other types of MPDU."
However Table 8-413---A-MPDU contents MPDUs in the control response context shows that you can have an (non-VHT single MPDU) A-MPDU without a Data or Management frame. In that situation what rate is used?
|
Clarify
|
MAC
|
|
|
Assigned
|
|
Matthew Fischer
|
6655
|
1000
|
RISON, Mark
|
E
|
Y
|
|
|
The material for VHT bandwidth operation etc. needs to be merged in with that for other PHYs
|
As it says in the comment (see also yellow stuff in 14/1104 for CID 3479)
|
MAC
|
Submission Required
|
EDITOR: 2015-04-30 14:18:21Z - This is beyond the scope of an editorial change. Transferring to MAC.
|
Assigned
|
|
Matthew Fischer
|
6704
|
1000
|
RISON, Mark
|
E
|
Y
|
1237
|
9
|
"A STA shall not transmit an MPDU in a VHT PPDU to a STA that exceeds the maximum MPDU length capability indicated in the VHT Capabilities element received from the recipient STA." --
why is this in 9.13.5 Transport of A-MPDU by the PHY data service?
|
Move to a more suitable location
|
MAC
|
|
|
Assigned
|
|
Menzo Wentink
|
5966
|
1000
|
Wentink, Menzo
|
T
|
Y
|
1324.15
|
9.22.2.3
|
EIFS can be avoided at devices that do not implement dynamic EIFS (yet) by requiring that a TXOP is always terminated with a transmission of an ACK at the lowest rate within the PHY.
(Dynamic EIFS is defined in 9.3.7, P1042L13.)
|
Require that the TXOP holder terminates a TXOP with an ACK at the lowest rate within the PHY (i.e. at 6 Mbps for 11ac).
|
MAC
|
Submission Required
|
|
Assigned
|
|
Menzo Wentink
|
5967
|
1000
|
Wentink, Menzo
|
T
|
Y
|
1042.53
|
8.4.2.157.3
|
In some cases it is desirable to be able to signal that the maximum supported NSS for 80+80 MHz or 160 MHz packet bandwidth is half the maximum supported NSS for 80 MHz packet bandwidth.
However, the Supported VHT-MCS and NSS Set does not currently support this.
|
Add the option of signaling half-Max Nss support for 80+80 and 160 MHz packet bandwidth.
|
MAC
|
Submission Required
|
|
Assigned
|
|
Menzo Wentink
|
6181
|
1000
|
RISON, Mark
|
T
|
Y
|
1157.36
|
8.6.13.4
|
The HT Operation element is not included if the BSS supports HT. This prevents a 40 MHz TDLS link being set up in a 20 MHz HT BSS, and leads to ambiguities if the BSS also supports VHT
|
Delete ", and the BSS does not support HT" at the referenced location. Also delete "but the BSS is not" in "The HT Operation element shall be present in a TDLS Setup Confirm frame when
both STAs are HT capable but the BSS is not." in 10.23.1
|
MAC
|
|
|
Assigned
|
|
Menzo Wentink
|
6186
|
1000
|
RISON, Mark
|
T
|
Y
|
1714.52
|
10.23.6
|
It is not clear whether two HT non-VHT STAs may establish a 40 MHz direct link when the BSS is a 20 MHz-only BSS
|
Clarify (e.g. does "The channel width of a TDLS direct link with a primary channel equal to the base channel shall not exceed the channel width of the BSS to which the TDLS peer STAs
are associated, except when the TDLS Wider Bandwidth subfield" apply in this case or only for VHT STAs?)
|
MAC
|
|
|
Assigned
|
|
Menzo Wentink
|
6199
|
1000
|
RISON, Mark
|
T
|
Y
|
1711.06
|
10.23.1
|
"A VHT STA with a TDLS link that is not an off-channel direct link shall use as its primary channel the channel indicated by the Primary Channel field in the HT Operation element." --
what if there isn't an HT Operation element (i.e. non-HT BSS or peer is not HT-capable)?
|
Clarify (perhaps say "shall use the primary channel of the BSS"?)
|
MAC
|
|
|
Assigned
|
|
Michael MONTEMURRO
|
6058
|
1000
|
Hamilton, Mark
|
T
|
Y
|
101.22
|
4.5.3.4
|
"No facilities are provided to move an RSNA during reassociation. Therefore, the old RSNA is deleted, and a
new RSNA is constructed." But isn't FT such a facility?
|
Change the paragraph to, "Only the fast BSS transition facility can move an RSNA during reassociation. Therefore, if FT is not used, the old RSNA is deleted and a new RSNA is constructed."
|
MAC
|
|
|
Assigned
|
|
Payam Torab Jahroni
|
5990
|
1000
|
TorabJahromi, Payam
|
T
|
Y
|
1492.24
|
9.38.3
|
There are no channel access rules defined for the variable-duration period between BRP request and response frames. With the duration longer than SIFS, it is important to keep the medium
busy while a response frame is being prepared. However, there are currently no rules to establish how the BRP initiator or the responder can keep the medium busy, resulting in collisions and interoperability problems.
|
Text will be provided.
|
MAC
|
Submission Required
|
|
Assigned
|
|
Payam Torab Jahroni
|
5991
|
1000
|
TorabJahromi, Payam
|
T
|
Y
|
1250.44
|
9.3.2.3.3
|
"A DMG STA that transmits a PPDU containing at least one individually addressed MPDU shall set the TXVECTOR parameter Turnaround to 1 if the STA is required to listen for an incoming
PPDU immediately following the transmission of the PPDU; otherwise, the STA shall set the TXVECTOR parameter Turnaround to 0. the STA shall set the TXVECTOR parameter Turnaround to 0 when it transmits an RTS frame." There are cases where a STA is not required
to listen, but the peer may see a transition from Rx to Tx, e.g., STA A and STA B in a Service period (A transmitting, B receiving), which is followed by another Service Period with B transmitting. Is this bit intended to be a PHY accelerator (Rx to TX predictor)
with 100% hit rate and some false negatives, or less than 100% hit rate and no false negatives? Define the correct behavior.
|
Text will be provided.
|
MAC
|
Submission Required
|
|
Assigned
|
|
Peter Eccelsine
|
5973
|
1000
|
Ecclesine, Peter
|
T
|
Y
|
3343.01
|
E.1
|
Close to half of the Japan table entries duplicate other entries as a legacy from 802.11j. We should indicate they are deprecated and may be reserved in a future version of the standard.
|
Add a note saying we are deprecating use of classes 3, 4, 5, 6, 8, 9, 10, 11, 13, 14, 15, 17, 18, 19, 20, 22, 23, 24, 26, 27, 28, 29, 33, 35, 38, 40, 43, 45, 47, 48, 49, 50, 52, 53, 54,
55 and they may be reserved in a future version of the standard.
|
GEN
|
Defer
|
GEN: 2015-05-11 23:47:58Z At 3343.3, Insert the following text: "Use of classes 3, 4, 5, 6, 8, 9, 10, 11, 13, 14, 15, 17, 18, 19, 20, 22, 23, 24, 26, 27, 28, 29, 33, 35, 38, 40, 43, 45,
47, 48, 49, 50, 52, 53, 54, 55 is deprecated and they may be reserved in a future version of the standard. " Comment - CID 5971 resolution may provide the deprecation.
|
Assigned
|
|
Peter Ecclesine
|
5314
|
1000
|
Hunter, David
|
E
|
Y
|
740.51
|
8.4.2.20.7
|
The sentence that begins "For operating classes that encompass a primary channel but do not identify the location of the primary channel," confuses operating classes with the field named
"Operating Class".
|
Replace the full sentence that begins "For operating classes that encompass ..".
with:
"A request frame is a request to make iterative measurements for all primary channel positions in all channels listed in the frame's AP Channel Report subelement when all of the following pertain:
" -- The operating class indicated by the value of the Operating Class field in that frame encompasses a primary channel.
" -- The frame does not identify the location of that primary channel.
" -- The value of the frame's Channel Number field is 255.
" -- The channel is supported.
" -- The measurement is permitted on the channel.
" -- The channel is permitted in the current regulatory domain."
|
MAC
|
|
EDITOR: 2015-04-28 09:09:55Z - This is a substantive re-writing. Requesting that MAC validate it. Transferring to MAC.
|
Assigned
|
|
Peter Ecclesine
|
5535
|
1000
|
Hunter, David
|
T
|
Y
|
1637.19
|
10.8.3
|
A comparison with the fourth paragraph of 10.8.2 leads to the question: why is there no specification of the use of Country, Power Constraint and VHT Transmit Power Envelope elements,
as well as Maximum Transmit Power Level field, etc. with respect to mesh STAs? Are mesh STAs not subject to power contraint regulations? Or are mesh STAs not allowed to use 11ac facilities?
|
Insert a new paragraph specifying the use of power constraint facilities to accommodate regulations.
|
MAC
|
|
|
Assigned
|
|
Peter Ecclesine
|
5556
|
1000
|
Hunter, David
|
E
|
Y
|
1640.04
|
10.9.1
|
"Detecting radar in the current and other channels based on regulatory requirements": "based on" appears to modify "channels", when it actually modifies "detecting"
|
Replace "channels based" with "channels, based".
|
MAC
|
|
EDITOR: 2015-04-29 09:00:33Z - Agree the statement is ambiguous. The question is whether it is the regulatory requirements that apply to detecting or to the "other channels". Requires
technical input. Transferring to MAC.
|
Assigned
|
|
Peter Ecclesine
|
5589
|
1000
|
Hunter, David
|
E
|
Y
|
1646.17
|
10.9.8.3
|
"within a spectrum-managed IBSS": but there is no definition of "spectrum-managed" anythng in this standard.
|
Replace "within a spectrum-managed IBSS" with "in an IBSS".
|
MAC
|
|
EDITOR: 2015-04-29 09:51:47Z - Presumably the qualification was intended to mean something. Should be replaced by a condition that is defined, such as a reference to MIB variables. This
is not an editorial. Transferring to MAC.
|
Assigned
|
|
Qi Wang
|
6558
|
1000
|
RISON, Mark
|
E
|
Y
|
1566.16
|
10.2.2.16
|
Half the stuff in 10.2.2.16.3 seems to be about the FMS Response, not the FMS Request
|
Move the stuff to do with the FMS Response to 10.2.2.16.4
|
MAC
|
|
|
Assigned
|
|
Qi Wang
|
6687
|
1000
|
RISON, Mark
|
E
|
Y
|
1566
|
10.2.2.16
|
Isn't "If the AP selects an alternate delivery interval or alternate maximum delivery interval from the value specified in the FMS Request, the FMS Status subelement shall be set to Alternate
Preferred, and the FMS subelement shall indicate the AP selected value(s)." in 10.2.2.16.3 FMS Request procedures duplication of stuff in ....16.4?
|
Remove the duplication
|
MAC
|
|
EDITOR_A: 2015-05-04 14:27:34Z Please discuss this CID together with CID 6558.
|
Assigned
|
|
sigurd Schelstraete
|
5879
|
1000
|
Schelstraete, Sigurd
|
T
|
N
|
1040.49
|
8.4.2.157.2
|
"Beamformee STS Capability" links the sounding feedback capability of a STA with the total number of streams that a STA can receive in an MU PPDU. There is no reason these values should
be the same and they should be decoupled to be future-safe.
The issue is explained in more detail in document IEEE 802.11-15/0057.
|
Will bring a detailed text proposal for this comment.
|
MAC
|
Submission Required
|
|
Assigned
|
|
Stephen McCann
|
6094
|
1000
|
Hamilton, Mark
|
T
|
Y
|
3574.15
|
V.3.2
|
This subclause has some significant problems with the architecture of an "AP" and its "BSS". (A single AP can't have multiple BSSIDs, for example. This is probably multiple APs and probably
also multiple ESSs, SSIDs, DSs and Portals. There could be a single physical device that includes the multiple APs, but that is a different architectural structure, and not made clear here.)
|
An Interworking expert will be needed to sort this out.
|
MAC
|
Submission Required
|
|
Assigned
|