|
Discussion:
Clearly the reference is wrong. The proposed change is also wrong, because Element IDs are irrelevant.
Note that all action frames are not bufferable. This is arguably wrong. This means they cannot be reliably transmitted to power savers.
For example a directed deenablement frame or a measurement request could be generated by the AP, and it seems to me that these deserve
not to get lost. However, that is changing the scope of the comment.
Proposed Resolution:
Change "Management frames are categorized as bufferable or nonbufferable, as shown in Table 8-85 (Element IDs)." to "Management frames are categorized as bufferable or nonbufferable, as shown in Table 10-1."
3719
|
1556.09
|
10.2.2.19
|
"AP may allow ... STAs ... to enter the Doze state during a TXOP." But what dictates when the AP actually does allow STAs to enter the Doze state during TXOPs? If the AP only _may_ allow that, when does it actually allow that? (An AP that _may_ allow that still is not required to actually ever allow it.) Note that the paragraph below begins: "If the AP allows" (not: "If the AP may allow").
|
Replace "may allow" with "is allowing".
|
Context: 1556.10:
A VHT AP may allow non-AP VHT STAs in TXOP power save mode to enter the Doze state during a TXOP. A VHT AP shall indicate this, which it does by transmitting a VHT PPDU with the TXVECTOR parameter TXOP_PS_NOT_ALLOWED set to 0.
|
Proposed Resolution:
Revised. An AP that supports TXOP power save is not required to offer TXOP power saving during any particular TXOP. It indicates whether it allows TXOP power saving as described in the following sentence. So “is allowing” is incorrect and “may allow” is correct. The language used in this para can be changed to make this operation more transparent.
Change “. A VHT AP shall indicate this” to “, which it does”
3730
|
1587.03
|
10.3.7
|
Missing normative verb.
|
Replace "shall an" with "shall transmit an".
|
Context: 1587.03:
Following the association or security association of a STA with a PCP, the PCP shall an unsolicited
Information Response frame (8.6.20.5 (Information Response frame format) to all the STAs associated with the PBSS.
|
Proposed resolution:
Accepted.
3738
|
1616.48
|
10.7.4.4
|
"cases where": but cases are not locations.
|
Replace "in cases where" with "when".
|
Context: 1616.48
The AP-initiated DLS teardown procedure may be used in cases where the STA is unable to initiate the DLS teardown.
|
Discussion:
Less is more.
Note, that this normative statement is ill-formed. It doesn’t enumerate the conditions under which a STA is unable to initiate DLS teardown.
And it assumes that a STA is not an AP. “The STA” could equally well (but wrongly) refer to the AP. But let’s sweep all of that under the rug.
Proposed Resolution:
Replace “in cases where” with “if”.
3029
|
1621.01
|
10.8.7
|
"the inclusion of a Power Constraint element and a VHT Transmit Power Envelope element in Beacon, DMG Beacon, Announce, and Probe Response frames shall be optional" -- "inclusion ... shall be optional" is a very round the trees and through the woods three times way of saying things.
|
Replace with: "a Power Constraint element and a VHT Transmit Power Envelope element may be included in Beacon, DMG Beacon, Announce, and Probe Response frames"
|
Proposed Resolution:
Accepted.
3030
|
1624.14
|
10.9.3
|
"Transmission by any non-VHT STA in the BSS of any MPDU and any associated acknowledgment
of the BSS" -- just how are BSSs acknowledged?
|
I don't know what it's trying to say. Replace with something that makes sense.
|
Context: 1624
Transmission by any non-VHT STA in the BSS of any MPDU and any associated acknowledgment
of the BSS within either the primary channel or the secondary channel (if present) shall complete
before the start of the quiet interval.
|
Proposed Resolution:
Revised. Delete “of the BSS” at the cited location.
3522
|
1637.05
|
10.11.4
|
"a Statistics request frame" is ambiguous. This could be a STA Statistics request, or a Directional Statistics request.
|
Change to "STA Statistics request frame
|
Context: 1637.01:
Each separate measurement within the Radio Measurement Request frame shall be performed over a continuous measurement duration time period. In Measurement Request frames the requested Measurement Duration value shall not be set to 0 except when the request frame is a Beacon request in which the Measurement Mode field value is Beacon Table, or is a Statistics request frame, or is a request for triggered autonomous measurements.
|
Discussion:
I believe this reference is to the STA Statistics request. However this is not a frame, but an abbreviated reference to a Measurement Request frame, as described in 727.26.
There are a handful of such references, and the changes below fix them all. The capitalization of a number of “Directional Statistics request” is incorrect. There are three wrong
references to “Statistics Request frame”.
At 1637.05 change “Statistics request frame” to “STA Statistics request”.
At 1647.48 change “accepts a Statistics request” to “accepts a STA Statistics request
At 1647.54 change “reject the received Statistics request” to “reject the received STA Statistics request”
At 2930.53 and 2937.14 change “a statistics request” to “a STA statistics request”
Globally correct capitalization to “Directional Statistics request”.
Globally correct capitalization to “STA Statistics request”.
Globally change “Statistics Request frame” to “Statistics request”.
3443
|
1667.38
|
10.12.3
|
"their best known resolutions, which may exceed the resolutions required by regulatory authorities" -- so they may not?
|
"their best known resolutions, which may exceed, and shall not be worse than, the resolutions required by regulatory authorities"
|
Discussion, this is not about permission to exceed. Also, there is no need to say “shall meet regulatory requirements” – we have removed such statements from the draft.
“might exceed” expresses probability. Presumably the only other probable case is meeting regulatory requirements, but not exceeding them.
Proposed resolution:
Revised. Change “may exceed” to “might exceed” at the stated location.
3223
|
1801.53
|
10.33.2.2
|
There are two instances of "numerically larger" and potentially (if not deleted as a result of the comment above) one instance of "numerically smaller" for MAC address comparision as a tie-breaker. Clarify the meaning of "numerically" larger or smaller, keeping consistent with other sections of the standard.
|
Other sections (e.g., 10.1.4.3.6 PCP selection in a PBSS) have clarified as follows (seems like there has been a previous comment on this -- CID 2132): "... the MAC address of the STA is greater than (see 11.6.1 (Key hierarchy) for MAC address comparison) the MAC address of the peer STA ..."; similar change is recommended.
|
Context: 1801.51:
Upon receipt of an FST Setup Request frame, the responder shall respond with an FST Setup
Response frame unless it has a pending FST Setup Request frame addressed to the initiator and the
responder has a numerically larger MAC address than the initiator’s MAC address, in which case,
the responder shall delete the received FST Setup Request.
If, after the reception of the acknowledgment to the initiator’sFST Setup Request frame, the
initiator receives an FST Setup Request frame from the responder, the initiator shall not respond
with an FST Setup Response frame if its MAC address is numerically larger (see 10.1.4.3.6 (PCP
selection in a PBSS)) than the responder’s MAC address. Otherwise, if its MAC address is
numerically smaller than the responder’s MAC address, it becomes the responder and responds with the FST Setup Response frame and shall not send the FST Setup Request frame during the current FST session transition.
|
Discussion:
We resolved these by referring to 11.6.1. The following text is in the 3rd para:
“For the purposes of comparison, the MAC address is encoded as 6 octets, taken to represent an unsigned binary number. The first octet of the MAC address shall be used as the most significant octet. The bit numbering conventions in 8.2.2 (Conventions) shall be used within each octet. This results in a 48-bit unsigned integer labelled B0 (least significant) to B47 (most significant), where the I/G bit is in B40.”
|
I propose to add a reference, and some text to indicate why the reference is relevant.
Proposed Resolution:
Revised.
At 1801.53, after “numerically larger MAC address” add “(see 11.6.1.1 for comparison of MAC addresses)”
At 1801.58, change “numerically larger (see 10.1.4.3.6 (PCP selection in a PBSS))” to “numerically larger (see 11.6.1.1 for comparison of MAC addresses and see 10.1.4.3.6)”
3511
|
1806.01
|
10.33.2.2
|
D2.8, P1823.38 reference to Annex R seems wrong. Probably supposed to be Annex Q. (11ad 'bug')
|
Change "Annex R" reference to Annex Q.
|
Context: 1805.63:
If neither the initiator nor the responder perform in the role of AP or PCP as indicated through the STA Role field within the Multi-band element corresponding to the new band for that STA, one of the STAs can initialize a new BSS (10.1 (Synchronization), Annex R) on the new band for communication between the STAs.
|
Discussion. Annex R is the DS SAP spec. Annex Q is the AP functional description.
As the only possible BSS that can be initialized in the case “If neither the initiator nor the responder perform in the role of AP or PCP” is IBSS,
neither Annex Q nor Annex R are relevant.
Proposed Resolution:
Revised. Delete reference to Annex R at cited location.
3038
|
1859.61
|
10.3.4.2.2
|
"The values qrand qnr may be used for all loops in the hunting-and-pecking process but a new value for r must be generated each time a quadratic residue is checked. " -- the use of "must" is deprecated by IEEE-SA style.
|
"must" -> "shall"
|
Context: 1859.61:
The values qr and qnr may be used for all loops in the hunting-and-pecking process but a new value for r must be generated each time a quadratic residue is checked.
|
Proposed Resolution:
Accepted.
3449
|
2087.56
|
13.9
|
Table 13-5 is very confusing. Is it trying to say that "better than" is to be treated as equivalent to "less than"?
|
Clarify, perhaps by not using "less than" or "greater than" at all in this context (including annex W), and/or by italicising the special uses of these terms (as in the table)?
|
Proposed Resolution:
Rejected.
To answer the question, “better than” is equivalent to “less than”, because the metric represents a cost, starting at 0.
The commenter does not provide specific wording that would satisfy the comment.
3494
|
2178.35
|
17.2.1
|
nonshort-preamble-capable is a STA capability, we don't need to refer to "equipment"
|
Change "equipment" to "STA"
|
Context: 2178.33: (and proposed change)
The optional short preamble and header provides maximum throughput when interoperability with legacy and nonshort-preamble-capable equipment is not a consideration. That is, it is expected to be used only in networks of like equipment, whichSTAs that can all handle the optional mode.
|
Proposed Resolution:
Revised. Replace “like equipment, which can” with “STAs that can”
3044
|
2469.50
|
22.3.7.3
|
"where ... is defined in 1.5 (Mathematical Usage)" -- Is there any need to refer explicitly to the floor operator, and to repeat this reference throughout this Clause?
|
Remove any " is defined in ..." statements.
|
Proposed Resolution:
Revised. Remove any “…defined in 1.5…” (14 instances, all in the PHY).
3083
|
3492.62
|
N.2.2
|
"Where A-MPDU aggregation is employed, HT-immediate Block Ack is assumed." - who does the assuming?
|
Reword to avoid "assume" and the passive voice
|
Proposed Resolution:
Rejected. Annex N is an informative Annex, so the burden of rigour can be relaxed. The surrounding text uses the word “assume” in various guises a lot, so the proposed change would introduce local inconsistency.
Submission page Adrian Stephens, Intel Corporation
Dostları ilə paylaş: |
