| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---_______________________________________________________________________________As I don't expect to make it to any phone conference or face to face meeting in the near future, I thought I would use email to stick my oar in.
CID1020:
"The name "group membership" is (IMHO) overly general. There are lots of different types of groups. e.g. .11ac Has MU-MIMO group membership."
"Replace all unadorned use of this term by .11aa with "GCR Group Membership".
The proposed change does not work because the group membership management feature is used to learn the contents of the dot11GroupAddressesTable of associated STAs. This table existed prior to 11aa and its use is independent from the use of GCR. I agree that the term "group membership" is overly general and we need a new term, but "GCR group membership" ain't it.
Looking at the description of dot11GroupAddressesTable it says "A conceptual table containing a set of MAC addresses identifying the multicast-group addresses for which this STA receives frames.". Would something like "Group addressed reception management" work as a replacement for "Group membership management" ?
CID1025:
<about the more data bit in group addressed frames>
Maybe I am misreading the comment, but they don't seem to be in conflict. One says "the bit is one when there is more to send" and the other says "the bit is zero when there is no more data to send".
CID1042:
"The addition by .11aa of the DELBA GCR Group Address does not indicate whether the field is optional or not. Either way creates a problem. Either it is not optional, in which case legacy devices are now non-compliant, or it is optional, in which case there is no straightforward way to parse the frame - given that the action field is followed by vendor specific elements of unknown length. i.e. the lengthof the frame cannot be used to determine the presence of this field."
I think it should be the "GCR Group Address element" (8.4.2.125) which is an optional element, rather than a naked MAC address. This matches the changes made by 11aa to the other block ack frame formats.
CID1044:
""The Public Key field contains the public key of the AP that is sending this Public Key frame and is defined in 8.4.1.39 (Scalar field)". I beg to differ. The cited location does not contain the definition of a Public Key field."
Yes, it really does contain the definition of the _format_ of the key. The public key is made up of the group ID and the scalar value. Suggest changing "The Public Key field contains the public key of the AP that is sending this Public Key frame and is defined in 8.4.1.39" to "The Public Key field contains the scalar value of the public key of the AP that is sending this Public Key frame and is defined in 8.4.1.39"
CID1052:
<bad grammar around 11aa addition>
Suggest changing "In the absence of a PCF or use of the group addressed transmission service (GATS), when group addressed MPDUs in which the To DS field is 0 are transferred from a STA, only the basic access procedure shall be used." to "When group addressed MPDUs in which the To DS field is 0 are transferred from a STA only the basic access procedure shall be used, unless these MPDUs are delivered using PCF or the group addressed transmission service (GATS)."
CID1053:
<GCR-SP delivery>
I think the 11aa additions can be removed. For legacy reasons, the group addressed frames are still buffered when PS mode is active. A STA using GCR-SP will get concealed versions of the group addressed MSDUs on a different schedule to DTIM. Therefore there is no need to put in the wriggle text "except when using GCR-SP" because the PS schedule still applies.
CID1060:
"is responsible for" in a note sounds like a requirement.
It is not a requirement, it is a warning to AP implementers to watch out for an ambiguity in the block ack bitmap. It's not perfect, but how about changing "The originator is responsible for recognizing that these bit positions apply to MPDUs irrelevant to the STA and for not spuriously retrying MPDUs." to "These bit positions apply to MPDUs irrelevant to the originating STA and it is recommended that the STA avoid spuriously these retrying MPDUs."
CID1065:
"There is no such beast as an "ADDTS Reserve Request action frames""
Yes there is. It is defined in 8.5.3.7
CID1074:
"Need to define the notation <0>32 here, or reference where it is defined"
Agree with proposed resolution. It is supposed to indicate 32 octets, where each octet contains the value zero.
CID1075:
"Need to define Max and Min for addresses, perhaps by reference to where this function is defined."
Min and max are already used in the spec for addresses. For example in 11.3.4.2.2. We need to make sure they use the same rules.
Alex
Date: Mon, 11 Mar 2013 13:00:20 +0000
From: Adrian.P.Stephens@xxxxxxxxx
Subject: [STDS-802-11-TGM] https://mentor.ieee.org/802.11/dcn/13/11-13-0233-01-000m-revmc-wg-ballot-comments.xls uploaded
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---_______________________________________________________________________________ IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.R1 contains additional categorization and some comment resolution of the editorial comments:
(plus some transfers to MAC/GEN) (pre-ballot roll-over comments are included in below…)
LB
Owning Ad-hoc
Comment Group
Unassigned
Needs submission
Discuss
Assigned
Resolved
Approved
Duplicate
Grand Total
0
EDITOR
201209 approved
7
7
201211 approved
120
120
201301 approved
144
1
145
For Style Guide
11
11
Grammar - punctuation
1
1
EDITOR Total
283
1
284
0 Total
283
1
284
193
EDITOR
Assigned to Mark Rison
12
12
Draft mechanics
1
2
1
4
Editorial
4
5
1
168
178
Grammar - punctuation
10
10
Invalid comments
1
1
Language - ensure
25
25
Language - setup
8
8
MIB
2
2
Normative language
55
1
56
Style - caps
13
3
1
6
23
Style - character code
1
3
4
Style - commonality
6
1
7
Style - consistency
18
1
19
Style - equations
1
1
Style - spacing
1
2
3
Style - terminology
2
10
3
3
18
Trivial Technical
16
5
21
EDITOR Total
115
51
9
14
203
392
GEN
Annexes
14
14
Assigned to Mark Rison
16
16
Discuss
5
5
PHY
20
20
PICS
5
5
(blank)
83
83
GEN Total
117
26
143
MAC
MAC - Behaviour
96
96
MAC - Frame formats
75
75
Mesh
4
4
Security
26
26
(blank)
16
49
65
MAC Total
217
49
266
193 Total
449
51
9
89
203
801
Grand Total
449
51
9
89
203
283
1
1085
Best Regards,
Adrian P STEPHENS
Tel: +44 (1793) 404 825
Tel: +44 (7920) 084 900
Tel: +1 (408) 239 7485
----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________