worth anything. In a dense interference when there are environment in which some peer-to-peer operations in the devices follow the HE BSS. recommendation and others do not, the "quiet period" The protocol is not meant to will actually be quite noisy. be deterministic or So what's the point? Apart guaranteed. The protocol from that the mechanism, would do no harm to BSS even if it worked, would operation even if no STA allow devices to make volunteered to stay silent in a arbitrary reservations of the quiet time period." medium without a requirement for actually After further discussion with using it, and without a the commenter, the method of canceling unused commenter agrees to submit quiet periods; even if this a contribution to addressing worked, it shouldn't be his concern. allowed. It is not enough to say that this mechanism might be useful in some circumstances; the question is whether it is useful *enough* to include in the draft? This is already a very bloated amendment and we should take the opportunity of deleting marginal modes. 323.14 The second sentence in the Delete the Rejected: 1st paragraph of section 2nd The two sentences are trying 27.16.4.1 is redundant and sentence in to describe the behaviors of can be removed. It captures the 1st two types of STAs. The first the same information as the paragraph sentence is to make it clear preceeding sentence. of that a STA participating the 27.16.4.1 specific peer-to-peer operation can send. The second sentence is to make it clear that a STA not participating the specific peer-to-peer operation should not send but it is not a “shall” requirement. As discussed before, the intent of the feature is to reduce the possibility of interference. 11870 323.21 Reference to field name is As in Accept: not consistent in this comment The is not necessary “field” section. It should be QTP and is deleted. Support TGax editor, please make changes as shown in document 11-18/0444r2 under CID 11870 12212 323.18 " high priority"is Suggest to Revised: ambiguous. explain
worth anything. In a dense environment in which some devices follow the recommendation and others do not, the "quiet period" will actually be quite noisy. So what's the point? Apart from that the mechanism, even if it worked, would allow devices to make arbitrary reservations of the medium without a requirement for actually using it, and without a method of canceling unused quiet periods; even if this worked, it shouldn't be allowed. It is not enough to say that this mechanism might be useful in some circumstances; the question is whether it is useful *enough* to include in the draft? This is already a very bloated amendment and we should take the opportunity of deleting marginal modes. interference when there are peer-to-peer operations in the HE BSS. The protocol is not meant to be deterministic or guaranteed. The protocol would do no harm to BSS operation even if no STA volunteered to stay silent in a quiet time period." After further discussion with the commenter, the commenter agrees to submit a contribution to addressing his concern. 323.14 The second sentence in the 1st paragraph of section 27.16.4.1 is redundant and can be removed. It captures the same information as the preceeding sentence. Delete the 2nd sentence in the 1st paragraph of 27.16.4.1 Rejected: The two sentences are trying to describe the behaviors of two types of STAs. The first sentence is to make it clear that a STA participating the specific peer-to-peer operation can send. The second sentence is to make it clear that a STA not participating the specific peer-to-peer operation should not send but it is not a “shall” requirement. As discussed before, the intent of the feature is to reduce the possibility of interference. 11870 323.21 Reference to field name is not consistent in this section. It should be QTP Support As in comment Accept: The “field” is not necessary and is deleted. TGax editor, please make changes as shown in document 11-18/0444r2 under CID 11870 12212 323.18 " high priority"is ambiguous. Suggest to explain Revised:
11-18-0444-02-00ax-cr-for-27-16-4.docx