| 9038 |
1072.48 |
9.4.2.174 |
|
(Follow-up to CID 8269) "The
Estimated Air Time Fraction subfield is 8 bits in length
and contains an unsigned integer that represents
the predicted percentage of time, linearly scaled with 255
representing 100%, that a new STA joining the
BSS will be allocated for PPDUs carrying Data of the
corresponding AC for that STA." -- if you look at R.7 it
turns out that this is exactly the time for the PPDUs, not
including any contention/IFS time. This is a very subtle
point (and differs from e.g. admission control) |
Change the cited text at the
referenced location to "The Estimated Air Time Fraction
subfield is 8 bits in length and contains an unsigned
integer that represents
the predicted percentage of air time (so not including
interframe space), linearly scaled with 255 representing
100%, that a new STA joining the
BSS will be allocated for PPDUs carrying Data of the
corresponding AC for that STA (so not including any
Management or Control frames)." |
|
EDITOR |
|
EDITOR: 2016-08-23 09:01:03Z
- This is a pile-on to comment 8269 (r02-269), which
stated:
" "The Estimated Air Time Fraction subfield is 8 bits in
length and contains an unsigned integer that represents
the predicted percentage of time, linearly scaled with 255
representing 100%, that a new STA joining the
BSS will be allocated for PPDUs carrying Data of the
corresponding AC for that STA." -- if you look at R.7 it
turns out that this is exactly the time for the PPDUs, not
including any contention/IFS time. This is a very subtle
point (and differs from e.g. admission control) "
with proposed change: " After the cited text add a
"NOTE---This time is purely for the PPDUs and does not
include overheads such as contention, IFS and protection
frames." "
This was resolved thus: " proposed note is not viewed as
necessary, as the cited text is clear. "
The new comment proposes changing the description of the
subfield to indicate it does not include IFSs, Management,
or Control frames. |
|
| 9004 |
1096.39 |
9.4.5.21 |
|
It says "Country Code", but
there is no such subfield in the Plan Information Tuple
field |
Change "Country Code" to
"Currency Code" at the referenced location |
|
EDITOR |
|
EDITOR: 2016-08-23 09:10:01Z
- The comment is correct, and in scope. |
|
| 9032 |
1626.47 |
11.3.5.4 |
|
(Follow-up to CID 8202) It is
not clear whether TSPECs are preserved across
reassociation to the same AP. Consider what happens if
e.g. the TS Info Ack Policy is Block Ack (since the BA
agreements have been reset). If reassociation to the same
AP preserves TSes, you'd be left with a TS with BA policy
without a BA agreement. 11.4.9.1 says "All TSPECs that
have been set up shall be deleted upon disassociation and
reassociation." (but note this contradicts 11.4.9.2's
(DMG-only) "A non-AP and non-PCP STA that associates,
disassociates or reassociates (except for reassociation to
the same AP) shall locally delete all existing allocations
and all TSs that have been established using a PTP
TSPEC.")
Note that what other specifications do and don't do is not
relevant to what the specification of IEEE Std 802.11 STAs
are required to do. |
At the end of the first
numbered list in 11.3.5.4 add "TSes established by a TSPEC
element whose TS Info Ack Policy subfield was equal to
Block Ack". At the end of the second numbered list in
11.3.5.4 add "TSes established by a TSPEC element whose TS
Info Ack Policy subfield was not equal to Block Ack". At
1646.36 change "All TSPECs that have been set up shall be
deleted upon disassociation and reassociation.
Reassociation
causes" to "All TSPECs that have been set up shall be
deleted upon disassociation and upon reassociation to a
different AP. Reassociation
to a different AP causes". |
|
EDITOR |
|
EDITOR: 2016-08-23 08:53:36Z
- This is a pile-on to comment 8202 (r02-202), which
stated:
" Are TSPECs preserved across reassociation to the same
AP? What if e.g. the TS Info Ack Policy is Block Ack
(since the BA agreements have been reset)? Although the
list in 11.3.5.4 does not discuss this, my recollection is
that reassociation to the same AP preserves TSes, so then
you'd be left with a TS with BA policy without a BA
agreement. My memory might be broken, since 1649.51 says
"All TSPECs that have been set up shall be deleted upon
disassociation and reassociation." (but this contradicts
1651.48's "A non-AP and non-PCP STA that associates,
disassociates or reassociates (except for reassociation to
the
same AP) shall locally delete all existing allocations and
all TSs that have been established using a PTP
TSPEC.") "
With resolution: " Add TSPECs to the list of things that
are destroyed on reassociation to the same AP "
This new comment has the same comment, but an alternative
change, which preserves TSPECs on reassociation to the
same AP.
The earlier comment was rejected with reason: " REJECTED
(MAC: 2016-07-24 20:27:01Z): The CRC could not reach
concensus on the changes necessary to address the comment.
Straw polls held:
July 21st Straw Poll:
A) Continue to work on the CID
B) Reject the CID – and not make a change
Results: 0-5-11 " |
|
| 9014 |
2003.13 |
12.7.2 |
|
Per discussions and
resolutions on D7.0, "CCMP" refers to any strength of
CCMP. If a specific strength of CCMP is intended, it needs
to be specified (compare Table 12-4 and Tables 9-131 and
9-132) |
Change "CCMP" to "CCMP-128"
at the referenced location |
|
EDITOR |
|
EDITOR: 2016-08-23 09:10:53Z
- The commenter is probably correct. But, I don't see any
changes related to CCMP-128 in D7.0. Comment 6285 makes a
similar change for GCMP, so I guess this can be
interpreted as a pile-on. |
|
| 9015 |
2003.16 |
12.7.2 |
|
Per discussions and
resolutions on D7.0, "CCMP" refers to any strength of
CCMP. If a specific strength of CCMP is intended, it needs
to be specified. Presumably the same applies to BIP |
Change "BIP" to
"BIP-CMAC-128" at the referenced location and also at
884.59 (first instance) in 9.4.2.55 |
|
EDITOR |
|
EDITOR: 2016-08-23 09:11:17Z
- Comment 6285 makes a similar change for GCMP.
Interpreting this as a pile-on. |
|
| 9031 |
2136.23 |
14.5.4 |
|
(Follow-up to CID 8325)
14.5.4 needs to cover IGTKdata not just GTKdata |
At the end of the last
paragraph of the referenced subclause, add "The IGTKData
subfield
in the Authenticated Mesh Peering Exchange element shall
contain the Key ID concatenated by the IPN and the IGTK
(as specified in 9.4.2.118 (Authenticated Mesh Peering
Exchange
element))."
At 2144.24 change 9.4.2.118 to 14.5.4 |
|
EDITOR |
|
EDITOR: 2016-08-22 12:54:57Z
- This is a "pile-on" to comment 8324. That comment is not
an unsatisfied comment, because the commenter did not
indicate it had to be satisfied. The cited location did
not change, but might reasonably be interpreted as
affected by the changes from CID 8324. |
|
| 9001 |
2450.33 |
20.4.3.3.3. |
|
Lenght=1208 is invalid
(maximum is 1023, intent is 128). in the next formula
[(120-6]/8] should be [(128-6)/8] |
See document 16-1068 |
|
EDITOR |
|
EDITOR: 2016-08-22 12:58:50Z
- The text has been stable since D5.0. Agree that this is
an error.
The first issue ("1208") is an editing error, since the
resolution of comment 6225 clearly indicates. The second
issue (120->128) is an error in the resolution of
comment 6225, and is arguably a pile-on to that comment. |
|
| 9033 |
3621.40 |
R.7 |
|
(Follow-up to CID 8222; see
also CID 8260) It is claimed that one can determine
"EstimatedThroughputInbound and
EstimatedThroughputOutbound for each AC of a current or
potential link to another STA using Equation (R-1)", but
Equation (R-1) refers to EST_AirtimeFraction, which is
defined as " the estimated portion of airtime that is
available
for outbound transmissions", so does not work for inbound
traffic |
Delete
"EstimatedThroughputInbound and" at 3621.40. At the end of
R.7 add a para "The mechanism by which ESP STAs determine
values for EstimatedThroughputInbound is outside the scope
of the standard." |
|
EDITOR |
|
EDITOR: 2016-08-23 08:57:02Z
- This is a pile-on to comment 8222 (r02-222), which
stated: " "EstimatedThroughputInbound and
EstimatedThroughputOutbound for each AC of a current or
potential link to another STA using Equation (R-1)", but
Equation (R-1) is just about estimating
EstimatedThroughput and there is no indication how the
Inbound and Outbount estimates are derived from this "
with proposed change: " Change "timatedThroughput =" at
line 45 to "EstimatedThroughputInbound =
EstimatedThroughputOutbound =" "
This was resolved as follows: " REJECTED (GEN: 2016-07-28
21:50:31Z) ) at 3623.40 the text indicates the equation
can be used for either inbound or outbound. "
The new comment has an alternative change - to make the
calculation of EstimatedThroughputInbound explicitly
unspecified. |
|