July 2014 doc.: Ieee 802. 11-14/780r2 ieee p802. 11



Yüklə 288,8 Kb.
səhifə5/5
tarix04.05.2017
ölçüsü288,8 Kb.
1   2   3   4   5

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


Yüklə 288,8 Kb.

Dostları ilə paylaş:
1   2   3   4   5




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©azkurs.org 2020
rəhbərliyinə müraciət

    Ana səhifə