|
CID
|
mgr comment
|
APS response
|
Pull?
|
Comment
|
Proposed Change
|
Resolution
|
|
5140
|
Have the 24 instances been reviewed?
|
This is not a comment on the resolution.
|
xxx it's a question on whether the comment has been fully responded to, since the commenter reported 24 instances
|
"at least PIFS time" - PIFS doesn't need "time" to follow it. PIFS is already a period of time.
|
Replace this instance by "at least a PIFS". Review the 24 instances of "*IFS time" and remove "time" where possible.
|
ACCEPTED (EDITOR_A: 2015-05-02 00:49:55Z)
|
|
6126
|
How about "on the air", "on-the-air", "the air interface"?
|
The resolution is OK.
|
xxx if "over the air" is informal and should be changed to "over the WM", then ditto the other forms shown in column P
|
"over the air" is informal usage
|
Change each instance of "over the air" to "over the wireless medium (WM)"
|
ACCEPTED (EDITOR_Q: 2015-05-31 19:43:51Z)
|
|
6695
|
How can a capability variable not be determined by device capabilities, or something determined by device capabilities not be a capability variable?
|
The resolution is OK.
|
xxx needs discussion
|
""This is a capability variable.
Its value is determined by device capabilities." seems to be duplication. Delete the second sentence.
|
As it says in the comment
|
REJECTED (EDITOR_A: 2015-05-04 13:08:14Z) The first sentence talks about the type of variable of the MIB attribute, while the second sentence talks about how the value of
this MIB attribute is determined. It is not a duplication.
|
|
6840
|
Note this should be <micro> not <Greek letter mu>
|
no change required. I don't recognise <micro> and <mu> as any different.
|
xxx searching does recognise them as different
|
Wrong unit in "-1.5 us."
|
Replace us with <mu>s
|
ACCEPTED (EDITOR_A: 2015-05-03 04:12:38Z)
|
|
6839
|
Note this should be <micro> not <Greek letter mu>
|
no change required. I don't recognise <micro> and <mu> as any different.
|
xxx searching does recognise them as different
|
Wrong unit in table heading
|
Replace us with <mu>s
|
ACCEPTED (EDITOR_A: 2015-05-24 14:25:48Z)
|
|
6348
|
Should "Management" and "Data" be uppercased here? I think maybe not
|
Resolution is OK
|
xxx when we capitalised Management etc. we said this was only when they were the "primary" adjective. See e.g. "control frame response" (2x, both all lowercase)
|
It says "The bandwidth of a PS-Poll frame does not constrain the bandwidth of an immediate data response to that PS-Poll frame." -- it doesn't constrain the bw of a mgmt frame
either
|
Change "data response" to "Management or Data frame response" in the cited text
|
ACCEPTED (EDITOR_A: 2015-05-02 00:52:30Z)
|
|
6834
|
The resolution doesn't actually indicate a change, even though it says REVISED
|
It permitted an action of the editor resulting in potential change, revised is appropriate.
|
xxx it is not possible for the commenter to determine whether the issue has been addressed + there is a future promise in the proposed resolution
|
8.4.2.96, 11.3.5.4: add a blank line after "where"
|
As it says in the comment
|
REVISED (EDITOR: 2015-05-28 12:54:26Z) - Editor to check that the appropriate template styles have been applied at these locations. This will be referred to the publication
editor to determine whether a global adjustment to the style for variable list is appropriate or not.
|
|
6586
|
The wording is not consistent: "If $blah, the STA concludes that the transmission of the MPDU has failed." and then "$foo shall be interpreted as failure of the MPDU transmission."
and then "$bar is defined to be a failure." They should all be of the same form (e.g. "shall be considered transmission failure")
|
The resolution is OK
|
xxx does not address the comment, which explicitly asked for consistency
|
The rules for "successful transmission and transmission failure" for the purposes of EDCA backoff are made harder to follow because terms are not used consistently
|
In this subclause, always use "MPDU", not "frame", and express the rules in the same way (so e.g. not "the STA concludes that the transmission of the MPDU has failed" and then
"The recognition of a valid response frame [...] shall be interpreted as a successful response.")
|
REVISED (EDITOR_A: 2015-05-05 10:01:03Z) Follow the proposed change in replacing "frame" with "MPDU". As for the comment that express the rules in the same way, the rules
of transmission failure are consistent. Specifically, while the first rule says "the STA concludes that the transmission of the MPDU has failed", the second rule says "The recognition of anything else, including any other valid frame, shall be interpreted
as failure of the MPDU transmission." There is no "The recognition of a valid response frame [...] shall be interpreted as a successful response." in clause 9.22.2.
|
|
5235
|
This is set by an external entity, not something the STA sets
|
Resolution is OK. Mark's comment is not editorial. It has review status anyway.
|
xxx makes no sense. STAs do not set dot11Activated variables, eternal entities do
|
page 1709 of body. Unclear. Apparently conflicting shalls on lines 21 and 24.
|
Change 1st sentence to: "When a STA joins a BSS, if Dot11OBCactivated is present, it shall set it to false."
|
REVISED (EDITOR_A: 2015-05-04 10:30:47Z) Change the cited sentence to "When a STA joins a BSS, it shall set dot11OCBActivated to false if it is present".
|
|
6047
|
Wait, wait, wait! Per the comments resolved in Athens, the comment and proposed change are not clear enough, and so the comment needs to be REVISED!
|
Stop wasting my time.
|
xxx I'm serious. When I had these kinds of comments in the past, I was told they are not clear, so now I have to explicitly say "It says "white rhino"" and "Change to "black
bear"". Has the policy changed?
|
Mesh Data frames
|
mesh Data frames
|
ACCEPTED (EDITOR_A: 2015-04-30 07:17:59Z)
|
|
6691
|
What about the "may decide the priority"?
|
Resolution is OK. "may decide the priority" is a different case.
|
xxx it's a case raised by the commenter in the comment
|
"may decide to X" -> "may X" (7x; also one "may decide the priority").
|
As it says in the comment
|
REVISED (EDITOR: 2015-04-30 14:15:28Z) - Delete "decide to" at 383.33, 1693.18 (twice), 1693.28 (twice), 1756.63.
At 2134.36 replace "decide to" with "attempt to".
|