2476
|
80.51
|
4.4.3
|
Shouldn't association, etc, have a qualifier for "not mesh service"? See the DSS examples.
|
As suggested.
|
REVISED (GEN: 2014-01-10) incorporate changes as shown in 11-13/1399r5
|
NR
|
This is a faulty comment resolution. The cited document shows a rejection, not a revised.
|
2044
|
1062.54
|
8.6.20.2
|
"The format of the Power Save Configuration Request frame Action field is shown..." -- no it's not. The action field does not include category or DMG action fields.
|
Remove the Category and DMG Action fields from all the "action field" figures in 8.6.20 and remove accompanying descriptions.
|
ACCEPTED (MAC: 2013-12-19 03:59:34Z)
|
NR
|
EDITOR: 2014-02-11 11:03:47Z- Please reject this comment. The commenter is mistaken. An action field, as shown in Figure 8-65 starts with the Category field, and includes everything after
it specified by the specific frame format.
|
2348
|
1172.54
|
9.20.3.4
|
"may not" is ambiguous -- does it mean "might not" or "is not permitted" ("shall not")?
|
Replace "may" with "might".
|
REVISED (MAC: 2013-11-13 23:30:23Z): Replace "may" with "might" in both occurences in the cited sentence.
|
MR
|
EDITOR: 2013-11-28 13:45:30Z- I can find only one occurrence at the cited location.
|
2351
|
1178.51
|
9.20.4.3
|
"may not" is ambiguous -- does it mean "might not" or "is not permitted" ("shall not")?
|
Replace "may not" with "is not".
|
REVISED (MAC: 2013-11-13 23:34:03Z): Replace the first "may" in the cited sentence with "might", replace the second "may" with "is"
|
MR
|
EDITOR: 2013-11-28 13:49:25Z- Changed the first "may". I cannot find a second "may.
|
2472
|
1368.21
|
10.1.4.5
|
If an IBSS contains a mix of STA capabilities, e.g. non-HT and HT, then a non-HT STA cannot adopt the HT Op IE as shown in 6.3.3.2 nor can it transmit the IE in its beacons.So it does
not transmit this IE in beacons then when an HT STA sees the beacon from the non-HT STA and the non-HT STA happens to have an older TSF, then does the HT STA stop transmitting the HT Op IE in its beacons?I.e. does the HT STA "adopt" the "lack of the presence
of the HT Op IE"? There is a general question here of whether an IBSS falls to the LCD of capabilities of its members or not, and should there be some desription explicitly stating that a STA either DOES or DOES NOT fall to the LCD?
|
Include an explicit description of the behavior of a STA in an IBSS that has greater capability than other members - that is continues to send indication of those capabilities, e.g. HT
Operation IE, even when the last beacon with the highest TSF has appeared with e.g. NO HT OP IE
|
REVISED (MAC: 2014-01-20 03:20:41Z): Insert a sentence at the end of the 5th paragraph in 10.1.4.5:
When an IBSS contains STAs with a mix of STA capabilities, e.g. non-HT and HT, a STA in the IBSS adopts the behavioral parameters of the last beacon with the highest TSF (e.g. HT STA does not continue use of HT and does not include an HT Operations element
in its beacons).
|
IR
|
The example: "(e.g., a HT STA does not continue use of HT and does not include an HT Operations element in its beacons)" is only true when it has received a Beacon that does not contain
an HT Operations element.
Also "a HT STA does not continue use of HT" is too sweeping. Surely the HT STA can use HT format PPDUs talking to an HT peer, provided it respects the channelization of the now non-HT IBSS, and protects these transmissions appropriately.
Please consider qualifying the example.
|
2367
|
1495.61
|
10.12.2.1
|
The enablement exchange sequence is a sequence of frames that are defined in clause 8, not a sequence of messages.
|
Replace "two-message" with "two-frame" and replace "message" with "frame" on lines 15, 16, 20, 41, 49, 55, and 59. On page 1491 replace "message" with "frame" on lines 19 and 37. On page
1493 replace "message" with "frame" on lines 15, 21 and 29 (all three in the figure).
|
REVISED (MAC: 2014-01-22 01:00:45Z): make changes as requested, plus also change "one-message" to "one-frame" at 1496L9.
|
IR
|
EDITOR: 2014-02-11 14:35:26Z- Note to reviewers, commenter's page line numbering is wrong, but relative positions are right.
Note to TGmc, replacing "message" with "frame" has created a number of frame types that don't actually exist, such as a enablement confirmation frame, or an enablement frame. Please reconsider this resolution and change these names to actual names of frames.
|
2376
|
1570.42
|
10.25.3
|
GAS 'messages' really are GAS frames; in this case "message" is just being used to say "information".
|
On this line replace "messages" with "information". On lines 23 and 57 replace "message" with "frame". On page 1566 lines 2 and 29 replace "message" with "frame". On page 1567 lines 2
and 45 replace "message" with "frame". On page 1567 line 5 replace "messages" with "frames". On page 1568 lines 2 and 46 replace "message" with "frame". On page 1568 line 3 replace "messages" with "frames".
|
REVISED (MAC: 2014-01-22 01:13:44Z): Make changes as proposed. Also add "frame" following "GAS Query Request" and "GAS Query Response"
|
MR
|
EDITOR: 2014-02-11 15:29:25Z-
(note to reviewers, commenter's numbering comes from D1.5).
Made the changes indicated by the commenter, but not the additional ones in the resolution. Note that there is no such frame as a GAS Query Request frame, nor is there a GAS Query Response frame. There are other GAS frames used as a transport for queries and
requests. There's a lot of CAPITALIZATION OF REALLY COOL THINGS in gas.
Also did not change "message sequence diagram" which is the proper name of this kind of diagram.
TGmc please review this resolution in the light of this response.
|