long in TU. Since the quiet time duration should follow the TXOP rule, the duration field is change to one byte with resolution of 32 micro second. The maximum duration is 8ms. 5770 96.28 9.4.2.224 The details of setting Quiet Time Period request elements are missing Clarify Revised: revised text is in clauses 9.4.2.242.3 5771 96.28 9.4.2.224 In case of not periodic QTP, how to set Quite Time Period is not defined define the case for not periodic QTP Revised: Repeat count 0 indicated that request is for one time only operation. Revised text is in clauses 9.4.2.242.3 5952 207.15 27.16.3.2 The spec only provides the methods to new Quiet Time Periods. But once a periodic Quiet Time Period is configured, there should be some ways to cancel it when necessary. As suggested Revised: Revised text is in clauses 9.4.2.242.3 5950 96.53 9.4.2.224 The spec requires the Quiet Period Offset field is set to the offset of the start of the first quiet period As suggested Revised: Accept the comment and using TBTT as the anchor
receiver can't discard the duplicated frame. It is simpler to replace the offset field with a start timer field. 5845 97.30 9.4.2.225 The description of Quiet Time Period Offset field of Quiet Time Response element is wrong. Replace: "Quiet Time Period Request", with "Quiet Time Period Response" Duplicated: The comment is addressed in CID 5950 8205 96.31 9.4.2.224 why there is a need to define a "periodic sequence" of quiet elements? clarify Rejected: The field is to address the need of certain per-to-peer operation that exchange frames in regular interval. 5846 95.48 9.4.2.223 Quiet Time Period Setup element is not needed. Since the Quiet Time Period is negotiated through Request & Response alerady, this Setup element is redundant Remove it from the text Rejected: The “Quiet Time Period Setup” element serves two purposes. To inform the STAs that an AP designates a period to give STAs participating in a specific peer-to-peer operation preference for channel access. It also allows the AP to dynamically control the allocation of quiet time period. 6471 96.32 9.4.2.224 The format of the element is in the Figure. In many other places in the draft, format is defined in figures. In Change " shown" to "defined". Rejected: The baseline 802.11-2016 uses “shown” when referring to a figure.
the present instance, is this showing really a definition? If so, say so. 6473 97.43 9.4.2.225 Vague and uninformative language: "indicates a specified operation". Which oiperation? Where is it specified? Provide additional, clarifying information. If this operation is specified elsewhere in the draft, say so and provide a reference. If the specification is by the vendor, and thus outside the scope of this draft, delete the word "specified". Duplicated: CID 3041. The quoted text was removed. 7777 96.22 9.4.2.223 What does "the HE STA support it can transmit frames" mean? Clarify. Same thing in 9.4.2.224 and 9.4.2.225. Revised: Additional text is added to 9.4.2.242.3 to address the comment. 8203 95.54 9.4.2.223 What does "improve probability" mean? Improve with respect to what? explain or delete Revised: Additional text is added to 9.4.2.242.2 address the comment. 8206 95.48 9.4.2.223 Is there a field in the HE Capability element to indicate support for this feature? If not then I believe it needs to be added. as in comment Rejected: It is define in Table 9-262z 9112 96.37 9.4.2.224 The term "Vendor Specific Service Identifier" is used in Figure 9-589cz, "Vendor Specific Service ID" on P96L22 and also "Vendor Specific Service Type" on P207L48, which appear to be the same parameter. Clarify and use a consistent term at the cited places. "Vendor Specific Service ID" may be the suitable one to use. In addition, an example of such a Service ID may be useful to avoid confusion with many specific service related terms introduced by the IEEE 802.11aq draft. Rejected: The “Vendor Specific Service Identifier” is addressed by CID 3041 . The change of "Vendor Specific Service Type" on P207L48 was addressed by the companion