Re: [STDS-802-11-TGM] REVmc MAC Ad-Hoc comment status sheet update

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

All,

Another update today, for resolutions approved in Wednesday’s TGmc sessions, on the Motion MAC-AK tab, here: https://mentor.ieee.org/802.11/dcn/13/11-13-0361-48-000m-revmc-mac-comments.xls

Here’s the current CID and assignment status (16 total still open):

Unassigned: 3 (looking for volunteers on these – 2 look pretty simple, related to DMG SSW) (the third is being worked, pulled out of today’s motion)

- Carlos Cordeiro: 2

- Gabor Bajko: 1

- Mark Hamilton: 1

- Mark Rison: 4

- Matthew Fischer: 2

- Payam Torob Jahromi:: 1

- Vinko Erceg: 2

(Full details just below)

Mark

CID	Page	Line	Clause	Assignee	Submission	Comment	Proposed Change	Resolution	Ad-hoc Notes
3232	1009.01	1	8.4.2.136	Carlos Cordeiro	11-14/1594r0	It is not stated anywhere which frame(s) are used to carry the Awake Window element.	Add AwakeWindow to DMG Beacon and Announce frame body (Table 8-49 and Table 8-401), or state in 8.4.2.136 that the element can be carried in DMG Beacon and Announce frames, or other solution.		MAC: 2015-01-13 19:18:44Z - REVISED (MAC: 2015-01-13 19:05:19Z): Make the changes as noted in 11-14/1594r3 as noted for CID 3232. [Consider on Wed] MAC: 2014-12-22 19:01:51Z - Discussed Dec 12, still some open discussion (captured in 11-14/1568), Carlos will bring back. MAC: 2014-11-21 15:24:42Z: From telecon: Simple addition as proposed is not agreed; need to add to tables. Ordering of fields debated - will be considered separately (needs a new comment).
3499	1211.28	28	8.6.22.2	Carlos Cordeiro	11-14/1594r0	"Multiple elements can appear in this frame." Like what? Anything? This is underconstrained. List what can, and makes sense, to put here; or something	Clarify what elements are sensible or expected in this frame.		MAC: 2014-12-22 19:01:51Z - Discussed Dec 12, still some open discussion (captured in 11-14/1568), Carlos will bring back.
3209	1733.52	52	10.24.14	Gabor Bajko		The Proxy ARP functionality does not address how to handle the ARP Announcement packets used for Address Conflict Detection and Address Defense. It should be described, to avoid inconsistent behaviour among different Proxy ARP implementation.	Submission will be provided.		MAC: 2014-09-18 11:34:18Z: Considered 11-14/1173r1. Jouni asked for further time to review. Mark H noted that the uplink announcements need to be explicitly 'blocked' at the AP (so that it doesn't duplicate if it generates one), and if the AP does generate one it needs to go to the DS (and thereby 'elsewhere'), and not just to this BSS. Same thing on the IPv6 case, of course.
3521	237.15	15	6.3.26.6.2	Mark Hamilton	11-14/1358	Get rid of all TIMEOUT ReasonCode values, unless there is explicit discussion of it in the protocol/behavior (and then give it a more descriptive name)	Get rid of all TIMEOUT ReasonCode values, unless there is explicit discussion of it in the protocol/behavior (and then give it a more descriptive name). I.e., change TIMEOUT in 6.3.26.6.2 (and 6.3.26.7.2, 6.3.27.6.2, 6.3.27.7.2, 6.3.29.6.2 and 6.3.29.7.2) ReasonCode to INACTIVITY_TIMEOUT; delete TIMEOUT from 6.3.93.10.2 and 6.3.93.11.2 (unless Relay links have a timeout semantics specified somewhere else); etc.
3462				Mark Rison		"Alternate Preferred" -- actually it's not a mere preference, it's an override	Change to "Overridden" throughout (10 instances in 8.4.2.76, 10.2.2.16.3, 10.2.2.16.4 and 10.24.8)	REVISED (EDITOR: 2014-08-14 10:14:52Z) - Change "Alternate Preferred" to "Alternate Proposed" throughout. In reply to the commenter, "Overridden doesn't quite catch the semantics. The AP has not created the FMS, but suggested or proposed parameters that might be accepted. 'Overridden' would suit different semantics in which the FMS was created with the alternate paramters, but this is not the case here."	EDITOR: 2014-11-19 14:39:21Z - This is turning into a technical debate. Transferring to MAC. MGR: 2014-09-15 08:27:46Z - Then I'm confused by 1551.20: "If the AP selects an alternate delivery interval or alternate maximum delivery interval from the value specified in the FMS Request, the FMS Status subelement shall be set to Alternate Preferred, and the FMS subelement shall indicate the AP selected value(s)." It sounds like the AP has made the decision, not that it wants the STA to ask for something else.
3211	2361.16	16	20.4.4	Mark Rison	11-14/1104	aMPDUMaxLength is not defined in Table 20-25 (nor wasn't it defined in the 802.11n amendment). So what is the maximum length of an un-aggregated MPDU for the HT PHY? In Clause 16, 17, 18, and 19 this parameter is defined in the PHY characteristics table. For 802.11a and 802.11g the value is 4096 octets. However, the dot11FragmentationThreshold MIB variable limits the longest transmission to be 2346, originally for both PHYs, under the rules of Clause 9, but this was later changed to be 3000 octets in 802.11REVmb, and changed again in 802.11n to 8000 octets. With this last increase to dot11FragmentationThreshold, aMPDUMaxLength = 4096 octets became the effective limit for these two PHYs. Now, in 802.11n, aMPUDMaxLength was not defined in the HT PHY parameters, although it is still required as one of the parameters in the initialization of the PHY primitive. aPSDUMaxLength = 65536, and the aPPDUMaxTime = 10ms were added, and the configurable dot11MaxAMSDUlength MIB variable = either 7935 or 3839 (default) was added. These 3 parameters, together, do limit the PHY transmission in both the aggregated and unaggregated cases, but then the default value for dot11FragmentationThreshold, which becomes the limit of an unaggregate packet, is ill-defined because aMPDUMaxLength is undefined for the Clause 20 HT PHY. All that is really known is that 8000 octets is the upper limit for dot11Fragmentation Threshold. (See the last sentence of the description of dot11FragmentationThreshold on page 3120, line 57, which gives the equation for calculating dot11FragmentationThreshold as a function of aMPDUMaxLength.)	Define aMPDUMaxLength for the HT PHY. In this way, the length of the maximum unaggregated MPDU (and the default maximum fragment as defined by the value of dot11FragmentationThreshold in the MIB) will be well-defined, as well as the parameter to the PHY initialization. (Sorry for not finding this in REVmb or earlier ballots of REVmc.)		Some of the history is out-of-date. Nonetheless, the problem statement is accurate. Clauses 21, 22 and 23 probably have the same problem. Need a submission suggesting what the aMPDUMaxLength should be for HT, DMG, VHT and TVHT, and providing rationale for the selection(s).
3392	1272.11	11	9.6	Mark Rison	11-14/1413	"A STA shall support the concurrent reception of fragments of at least three MSDUs or MMPDUs. [...] The destination STA shall maintain a Receive Timer for each MSDU or MMPDU being received, for a minimum of three MSDUs or MMPDUs." -- does this always apply (e.g. DMG STAs -- see end of 9.5 and 9.22.2.1; also what about the risk of MSDU/MMPDU reordering caused by concurrent reception causing replay detection to discard MSDUs/MMPDUs)?	If it doesn't apply to all STAs, add suitable caveats		MAC: 2014-11-21 15:36:56Z - From telecon: Agree with the Reject proposal, as we are quite sure there is text somewhere else that does require this for all STAs. Need to recall that discussion (from the F2F in San Antonio) and find the cite. Will reconsider on the next telecon, and confirm that we've covered all the cases, and determined whether there are any special cases or not (after refreshing the memory of the F2F discussion, as well). Assigned to Mark R, for now.
3523	554.54	54	8.2.4.1.7	Mark Rison	11-14/1104	The rules in 8.2.4.1.7 are not consistent with 10.2.2.2. The concepts "MMDU is bufferable" and "PM bit is reserved" need to be separated. It makes no sense to say that an Action MMDU sent by a non-AP STA is bufferable, for example, just because you want to be able to say that the PM is valid in the MPDUs used to send it. The exception for the PM bit in Probe Responses sent in response to unicast Probe Requests in an IBSS makes no sense It's not clear enough which Control MPDUs have non-reserved PM bits and when. Note for example that 8.2.4.1.7 implies the PM bit in ACKs sent by a non-AP STA are not reserved.	Consider documents 11-12/1199 and 11-13/0131
3299	711.60	60	8.4.2.3	Matthew Fischer		Add a BSS membership selector for "private network" with the membership requirement to join the private network found in a specific location, e.g. include a new IE which contains an OUI field and a type field which together are a reference to a VSIE that matches that OUI value and with the type octet matching the octet that immediately follows the OUI value in the VSIE. The VSIE provides further details of what is required for membership, expressed in a vendor-specific manner. (continuation of rejected LB199 CID 2473 - rejected due to insufficient information)	Add a row to Table 8-86 "BSS membership value encoding", the row to contain: value "125", feature "vendor specific", interpretation: "Support of vendor specific features is required in order to join the BSS that was the source of the Supported Rates element or Extended Supported Rates element containing this value. The vendor specific features are identified by the vendor specific OUI and type values listed in the Vendor Specific BSS Membership Selector Information Element" - add a new element "Vendor Specific BSS Membership Selector IE" with a body that contains a variable length list of N "vendor specific BSS membership selector reference" fields, with the description for "vendor specific BSS membership selector reference field" as: Each vendor specific BSS membership selector reference field has a three octet OUI value and a one octet type value, together each OUI/type pair describes a vendor specific element that matches the given OUI/type pair and which contains information that describes, in a vendor specific manner, BSS membership conditions.
3301	587.50	50	8.3.1.1	Matthew Fischer		Implementations can benefit through the addition of another dynamic PS mechanism which is receiver bandwidth based. Add a BW-based dynamice PS mechanism.	Change the definition of the FC bits in the RTS frame to allow the More Frag, More Data, Protected Frame and Order bits to be used collectively to form the "TXOP Width" subfield which signals the width of the upcoming MSDU-bearing PPDUs that follow the RTS. Each of the 4 bits indicates which portion of the BSS operating width is being used for the MSDU-bearing PPDUs such that one bit indicates use of the primary 20 MHz channel, another indicates use of the primary 40 MHz channel, the third the secondary 40 MHz channel and the 4th bit indicates use of the secondary 80 MHz channel.
3231	1349.43	43	9.24.4	Payam Torob Jahromi		If no MSDUs or A-MSDUs are passed up to the next MAC process after the receipt of the BlockAckReq frame and the starting sequence number of the BlockAckReq frame is newer than the NextExpectedSequenceNumber for that block ack agreement, then the NextExpectedSequenceNumber for that block ack agreement is set to the sequence number of the BlockAckReq frame.	The statement is of the form "if (A and B) then C"; Break the if and define behavior for all combinations of A and B, including any missing ele statements (pseudo code in 9.24.7.3 seems to have defined a behavior).
3477	1298.33	33	9.13.6	Vinko Erceg	11-14/1104r4	The second bullet appears to allow a VHT single MPDU (i.e. one with EOF = 1) to be followed by null subframes with EOF = 0. Once EOF has been signalled, it makes no sense to unsignal it (cf. 145.33)	Change "0 in the EOF field" to "the same value in the EOF field as the preceding A-MPDU subframe"
3488				Vinko Erceg		In May 2014 IEEE 802.11 meeting, REVmc worked on a liaison letter from 3GPP. Throughput parameter was proposed to be used for network selection. However, this parameter needs to be defined in REVmc to be useful.	Define Throughput parameter in REVmc. I will bring contribution.
3430	1862.56	56	11.3.5.4			Having more than one thing (e.g. "KCK \|\| PMK") on the left of an equals sign is somewhat confusing	Use L() as in 11.6.1.3		MAC: 2015-01-14 18:44:57Z - Was: REVISED (MAC: 2015-01-13 20:08:34Z): Incorporate the text changes in 11-14/1104r11 for CID 3430. Pulled from MAC-AJ motion. EDITOR: 2014-11-19 14:11:42Z - Somehow, had failed to make the transfer. Transferred to MAC, really! EDITOR: 2014-10-23 15:27:48Z - This requires a technical interpretation of the meaning of these symbols. Transfer to MAC. Note the resolution "Replace "KCK \|\| PMK" with "(KCK \|\| PMK)"." has been speculatively edited. MGR: 2014-09-17 06:41:02Z - That doesn't really help address the confusion. As the proposed change says, you need to use L() as in 11.6.1.3, i.e. blah = KDF-512(zoo,zah,zing), KCK = L(blah, foo, bar), PMK = L(blah, baz, boing)
3674	1476.38	38	9.38.2.5			"When present, the Sector Sweep Ack (SSW-Ack) occurs following an SSW Feedback.": is this just a natural occurance? Need to indicate what STA issues this frame (and the fact that these two names are the names of frames).	Replace "(SSW-Ack) occurs following" with "(SSW-Ack) frame is issued after the STA receives an SSW Feedback frame."		Need inputs from domain experts. Transferred to MAC.
3673	1475.57	57	9.38.2.4			"Sector Sweep Feedback (SSW Feedback) occurs following each RSS.": is this just some naturally occuring phenonmenon? Need to indicate who issues the SSW Feedback frame, as well as the fact it is a frame.	Replace "(SSW Feedback) occurs following each RSS." with "(SSW Feedback) frame is issued by the STA after it completes each RSS."		EDITOR_Q: 2014-09-04 23:12:01Z - Need input from the domain experts. Transferred to MAC.

From: Hamilton, Mark
Sent: Wednesday, January 14, 2015 12:03 AM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: REVmc MAC Ad-Hoc comment status sheet update

All,

I have uploaded an updated comment spreadsheet with comments for the MAC Ad-Hoc of REVmc, here: https://mentor.ieee.org/802.11/dcn/13/11-13-0361-47-000m-revmc-mac-comments.xls

This spreadsheet includes two tabs of resolutions that are ready for motion, planned for the AM1 session tomorrow (Wed), “Motion MAC-AI”, and “Motion MAC-AJ”.

The CIDs below (27 of them) are still open, and assigned to the following individuals:

Unassigned: 2 (looking for volunteers on these – they look pretty simple, related to DMG SSW)

Brian Hart: 1

Carlos Cordeiro: 2

Emily Qi: 1

Gabor Bajko: 1

Mark Hamilton: 3

Mark Rison: 4

Matthew Fischer: 3

Payam Torob Jahromi: 1

Ron Porat: 1

Vinko Erceg: 8

For your convenience, the summary table is provided directly below. Please help early and often!

Mark

P.S., please remember that this is only the report for the MAC Ad-Hoc, there may be other comments awaiting your adoption, in GEN or EDITOR…

CID	Page	Line	Clause	Assignee	Submission	Comment	Proposed Change	Ad-hoc Notes
3471	1717.53	53	10.24.6.3	Brian Hart		There should be a mechanism to allow the initiating STA to known which parameter the responding STA is incapable of honouring	Use the Value field to indicate this (e.g. it could give the index of (one of) the field(s) which the rSTA is incapable of
3232	1009.01	1	8.4.2.136	Carlos Cordeiro	11-14/1594r0	It is not stated anywhere which frame(s) are used to carry the Awake Window element.	Add AwakeWindow to DMG Beacon and Announce frame body (Table 8-49 and Table 8-401), or state in 8.4.2.136 that the element can be carried in DMG Beacon and Announce frames, or other solution.	MAC: 2015-01-13 19:18:44Z - REVISED (MAC: 2015-01-13 19:05:19Z): Make the changes as noted in 11-14/1594r3 as noted for CID 3232. [Consider on Wed] MAC: 2014-12-22 19:01:51Z - Discussed Dec 12, still some open discussion (captured in 11-14/1568), Carlos will bring back. MAC: 2014-11-21 15:24:42Z: From telecon: Simple addition as proposed is not agreed; need to add to tables. Ordering of fields debated - will be considered separately (needs a new comment).
3499	1211.28	28	8.6.22.2	Carlos Cordeiro	11-14/1594r0	"Multiple elements can appear in this frame." Like what? Anything? This is underconstrained. List what can, and makes sense, to put here; or something	Clarify what elements are sensible or expected in this frame.	MAC: 2014-12-22 19:01:51Z - Discussed Dec 12, still some open discussion (captured in 11-14/1568), Carlos will bring back.
3460	1551.44	44	10.2.2.16.4	Emily Qi		No behaviour is indicated for "Alternate Preferred, due to existing stream with different delivery interval", "Alternate Preferred, due to policy limits on AP" and "Alternate Preferred, due to AP changed the delivery interval" (and maybe others?)	Add normative behaviour for all statuses
3209	1733.52	52	10.24.14	Gabor Bajko		The Proxy ARP functionality does not address how to handle the ARP Announcement packets used for Address Conflict Detection and Address Defense. It should be described, to avoid inconsistent behaviour among different Proxy ARP implementation.	Submission will be provided.	MAC: 2014-09-18 11:34:18Z: Considered 11-14/1173r1. Jouni asked for further time to review. Mark H noted that the uplink announcements need to be explicitly 'blocked' at the AP (so that it doesn't duplicate if it generates one), and if the AP does generate one it needs to go to the DS (and thereby 'elsewhere'), and not just to this BSS. Same thing on the IPv6 case, of course.
3523	554.54	54	8.2.4.1.7	Mark Hamilton		The rules in 8.2.4.1.7 are not consistent with 10.2.2.2. The concepts "MMDU is bufferable" and "PM bit is reserved" need to be separated. It makes no sense to say that an Action MMDU sent by a non-AP STA is bufferable, for example, just because you want to be able to say that the PM is valid in the MPDUs used to send it. The exception for the PM bit in Probe Responses sent in response to unicast Probe Requests in an IBSS makes no sense It's not clear enough which Control MPDUs have non-reserved PM bits and when. Note for example that 8.2.4.1.7 implies the PM bit in ACKs sent by a non-AP STA are not reserved.	Consider documents 11-12/1199 and 11-13/0131
3521	237.15	15	6.3.26.6.2	Mark Hamilton	11-14/1358r1	Get rid of all TIMEOUT ReasonCode values, unless there is explicit discussion of it in the protocol/behavior (and then give it a more descriptive name)	Get rid of all TIMEOUT ReasonCode values, unless there is explicit discussion of it in the protocol/behavior (and then give it a more descriptive name). I.e., change TIMEOUT in 6.3.26.6.2 (and 6.3.26.7.2, 6.3.27.6.2, 6.3.27.7.2, 6.3.29.6.2 and 6.3.29.7.2) ReasonCode to INACTIVITY_TIMEOUT; delete TIMEOUT from 6.3.93.10.2 and 6.3.93.11.2 (unless Relay links have a timeout semantics specified somewhere else); etc.
3459	1551.21	21	10.2.2.16.3	Mark Hamilton		There is no single "Alternate Preferred" status	Refer to the two specific statuses from table 8-203
3211	2361.16	16	20.4.4	Mark Rison	11-14/1104	aMPDUMaxLength is not defined in Table 20-25 (nor wasn't it defined in the 802.11n amendment). So what is the maximum length of an un-aggregated MPDU for the HT PHY? In Clause 16, 17, 18, and 19 this parameter is defined in the PHY characteristics table. For 802.11a and 802.11g the value is 4096 octets. However, the dot11FragmentationThreshold MIB variable limits the longest transmission to be 2346, originally for both PHYs, under the rules of Clause 9, but this was later changed to be 3000 octets in 802.11REVmb, and changed again in 802.11n to 8000 octets. With this last increase to dot11FragmentationThreshold, aMPDUMaxLength = 4096 octets became the effective limit for these two PHYs. Now, in 802.11n, aMPUDMaxLength was not defined in the HT PHY parameters, although it is still required as one of the parameters in the initialization of the PHY primitive. aPSDUMaxLength = 65536, and the aPPDUMaxTime = 10ms were added, and the configurable dot11MaxAMSDUlength MIB variable = either 7935 or 3839 (default) was added. These 3 parameters, together, do limit the PHY transmission in both the aggregated and unaggregated cases, but then the default value for dot11FragmentationThreshold, which becomes the limit of an unaggregate packet, is ill-defined because aMPDUMaxLength is undefined for the Clause 20 HT PHY. All that is really known is that 8000 octets is the upper limit for dot11Fragmentation Threshold. (See the last sentence of the description of dot11FragmentationThreshold on page 3120, line 57, which gives the equation for calculating dot11FragmentationThreshold as a function of aMPDUMaxLength.)	Define aMPDUMaxLength for the HT PHY. In this way, the length of the maximum unaggregated MPDU (and the default maximum fragment as defined by the value of dot11FragmentationThreshold in the MIB) will be well-defined, as well as the parameter to the PHY initialization. (Sorry for not finding this in REVmb or earlier ballots of REVmc.)	Some of the history is out-of-date. Nonetheless, the problem statement is accurate. Clauses 21, 22 and 23 probably have the same problem. Need a submission suggesting what the aMPDUMaxLength should be for HT, DMG, VHT and TVHT, and providing rationale for the selection(s).
3462				Mark Rison		"Alternate Preferred" -- actually it's not a mere preference, it's an override	Change to "Overridden" throughout (10 instances in 8.4.2.76, 10.2.2.16.3, 10.2.2.16.4 and 10.24.8)	EDITOR: 2014-11-19 14:39:21Z - This is turning into a technical debate. Transferring to MAC. MGR: 2014-09-15 08:27:46Z - Then I'm confused by 1551.20: "If the AP selects an alternate delivery interval or alternate maximum delivery interval from the value specified in the FMS Request, the FMS Status subelement shall be set to Alternate Preferred, and the FMS subelement shall indicate the AP selected value(s)." It sounds like the AP has made the decision, not that it wants the STA to ask for something else.
3479	1823.09	9	10.40.4	Mark Rison	11-14/1104r4	For non-VHT STAs to be able to fully benefit from the new power/regulatory/channel switching stuff, it is necessary for them e.g. to be able to receive a unicast (Extended) Channel Switch Announcement MMPDU with e.g. a VHT Transmit Power Envelope element	Add an Extended Capability bit to allow a non-VHT STA to indicate support for the VHT power/regulatory/channel switching stuff, and ensure the text requires VHT STAs to use the VHT power/regulatory/channel switching stuff with non-VHT devices which have indicated this capability
3392	1272.11	11	9.6	Mark Rison	11-14/1413r0	"A STA shall support the concurrent reception of fragments of at least three MSDUs or MMPDUs. [...] The destination STA shall maintain a Receive Timer for each MSDU or MMPDU being received, for a minimum of three MSDUs or MMPDUs." -- does this always apply (e.g. DMG STAs -- see end of 9.5 and 9.22.2.1; also what about the risk of MSDU/MMPDU reordering caused by concurrent reception causing replay detection to discard MSDUs/MMPDUs)?	If it doesn't apply to all STAs, add suitable caveats	MAC: 2014-11-21 15:36:56Z - From telecon: Agree with the Reject proposal, as we are quite sure there is text somewhere else that does require this for all STAs. Need to recall that discussion (from the F2F in San Antonio) and find the cite. Will reconsider on the next telecon, and confirm that we've covered all the cases, and determined whether there are any special cases or not (after refreshing the memory of the F2F discussion, as well). Assigned to Mark R, for now.
3301	587.50	50	8.3.1.1	Matthew Fischer		Implementations can benefit through the addition of another dynamic PS mechanism which is receiver bandwidth based. Add a BW-based dynamice PS mechanism.	Change the definition of the FC bits in the RTS frame to allow the More Frag, More Data, Protected Frame and Order bits to be used collectively to form the "TXOP Width" subfield which signals the width of the upcoming MSDU-bearing PPDUs that follow the RTS. Each of the 4 bits indicates which portion of the BSS operating width is being used for the MSDU-bearing PPDUs such that one bit indicates use of the primary 20 MHz channel, another indicates use of the primary 40 MHz channel, the third the secondary 40 MHz channel and the 4th bit indicates use of the secondary 80 MHz channel.
3299	711.60	60	8.4.2.3	Matthew Fischer		Add a BSS membership selector for "private network" with the membership requirement to join the private network found in a specific location, e.g. include a new IE which contains an OUI field and a type field which together are a reference to a VSIE that matches that OUI value and with the type octet matching the octet that immediately follows the OUI value in the VSIE. The VSIE provides further details of what is required for membership, expressed in a vendor-specific manner. (continuation of rejected LB199 CID 2473 - rejected due to insufficient information)	Add a row to Table 8-86 "BSS membership value encoding", the row to contain: value "125", feature "vendor specific", interpretation: "Support of vendor specific features is required in order to join the BSS that was the source of the Supported Rates element or Extended Supported Rates element containing this value. The vendor specific features are identified by the vendor specific OUI and type values listed in the Vendor Specific BSS Membership Selector Information Element" - add a new element "Vendor Specific BSS Membership Selector IE" with a body that contains a variable length list of N "vendor specific BSS membership selector reference" fields, with the description for "vendor specific BSS membership selector reference field" as: Each vendor specific BSS membership selector reference field has a three octet OUI value and a one octet type value, together each OUI/type pair describes a vendor specific element that matches the given OUI/type pair and which contains information that describes, in a vendor specific manner, BSS membership conditions.
3298	1032.26	26	8.4.2.157.3	Matthew Fischer	11-14/793r3	There is no text in this subclause to define the fields Rx Highest Supported Long GI Data Rate or Tx Highest Supported Long GI Data Rate.	Add a sentence or two indicating that the Rx Highest Supported Long GI Data Rate field and Tx Highest Supported Long GI Data Rate are defined in Table 8-251.	See also 3297
3231	1349.43	43	9.24.4	Payam Torob Jahromi		If no MSDUs or A-MSDUs are passed up to the next MAC process after the receipt of the BlockAckReq frame and the starting sequence number of the BlockAckReq frame is newer than the NextExpectedSequenceNumber for that block ack agreement, then the NextExpectedSequenceNumber for that block ack agreement is set to the sequence number of the BlockAckReq frame.	The statement is of the form "if (A and B) then C"; Break the if and define behavior for all combinations of A and B, including any missing ele statements (pseudo code in 9.24.7.3 seems to have defined a behavior).
3035	1829.56	56	10.43	Ron Porat		"A TVHT AP shall set the Channel Width subfield in the TVHT Operation Information field to indicate the BSS operating channel width and transmitted PPDU type depending on value of B0-B1 in TVHT-SIG-A1 field from those shown in Table 10-26 (TVHT BSS operating channel width" -- The MAC should not know about SIGNAL fields, only VECTOR parameters.	Replace: "of B0-B1 in TVHT-SIG-A1 field" with a reference to a TXVECTOR parameter.
3300	1029.23	23	8.4.2.157.2	Vinko Erceg		The universally complete set of architectures of VHT receivers does not imply identical spatial stream support for SU and MU cases. I.e. the ability to differentiate spatial stream support values for MU vs SU is missing. This comment also applies to TVHT.	Change bits 30-31 of the VHT Capabilities Info field from reserved to "MU NSS Reduction" with a definition of the "The value of MU NSS Reduction field is an unsigned integer representing the reduction in the maximum number of spatial streams that is supported by the STA when receiving or transmitting an MU PPDU as compared to the maximum number of spatial streams that are supported by the STA when receiving or transmitting an SU PPDU. The maximum number of spatial streams that are supported by the STA when receiving or transmitting an SU PPDU is equal to the smaller of the maximum number of spatial streams supported by the STA when receiving an SU PPDU and the maximum number of spatial streams supported by the STA when transmitting an SU PPDU. The maximum number of spatial streams supported by the STA when receiving an SU PPDU is the highest number of spatial streams for which the RX VHT-MCS map subfield does not contain the value of 3. The maximum number of spatial streams supported by the STA when transmitting an SU PPDU is the highest number of spatial streams for which the TX VHT-MCS map subfield does not contain the value of 3. " As an alternative, even though it seems odd, one could place these new bits in some of the reserved bit locations of the HT Cap IE in the Extended capabilities subfield where there are lots of bits available. All VHT STA must transmit this IE anyway. If the bits were placed in the HT IE location, then the field could be extended by one bit, and possibly even duplicated to differentiate TX from RX. Make similar changes for TVHT, e.g. 8.4.2.170
3297	1032.10	10	8.4.2.157.3	Vinko Erceg	11-14/793r3	The universally complete set of architectures of 80+80 receivers does not imply support for certain capabilities when operating in 160 MHz mode as is already suggested by the existence of the Highest Supported Long GI Data Rate fields. Some obvious combinations cannot currently be signaled. Also applies to TVHT (see, for example, 8.4.2.170)	Change the reserved field at bits 29-31 to become "Max NSS for 80+80 MHz" with the value in the field equal to nss supported for 80+80 MHz and a value of 0 to be used when 80+80 MHz is not supported. Change the reserved field at bits 61-63 to become "Max NSS for 160 MHz" with the value in the field equal to nss supported for 160 MHz and a value of 0 to be used when 160 MHz is not supported. Might also want to add a note saying that these values do not place an upper bound on the NSS supported for 20, 40, 80 MHz - those bounds are specified elsewhere. Note that similar changes should be executed for TVHT.	See also 3298
3491	1032.10	10	8.4.2.157.3	Vinko Erceg		Some obvious combinations of 80+80 receivers cannot currently be signaled.	Reserved field at bits 29-31 SHOULD BE: "Max NSS for 80+80 MHz" with the value in the field equal to NSS supported for 80+80 MHz and a value of 0 to be used when 80+80 MHz is not supported. The reserved field at bits 61-63 SHOULD BE: "Max NSS for 160 MHz" with the value in the field equal to NSS supported for 160 MHz and a value of 0 to be used when 160 MHz is not supported. Add note saying these values do not place an upper bound on the NSS supported for 20, 40, 80 MHz - those bounds are specified elsewhere.
3489	1046.00		8.4.2.170	Vinko Erceg		For TVHT different number of segments supported may have different number of Nss supported. Allow for this flexibility.	As in comment. I will bring contribution.
3488				Vinko Erceg		In May 2014 IEEE 802.11 meeting, REVmc worked on a liaison letter from 3GPP. Throughput parameter was proposed to be used for network selection. However, this parameter needs to be defined in REVmc to be useful.	Define Throughput parameter in REVmc. I will bring contribution.
3487	1032.00		8.4.2.157.3	Vinko Erceg		VHT capabilities for BW and Nss are coupled. However, same Nss does not have to apply for 80MHz, 160MHz and 80+80MHz BW.	Use reserved bits B29-B31 to indicate Max Nss for 80+80MHz BW (0 indicates that 80+80MHz BW is not supported). Use reserved bits B61-B63 to indicate Max Nss for 160MHz BW (0 indicates that 160MHz BW is not supported).
3486	1029.00		8.4.2.157.2	Vinko Erceg		VHT capabilities for BW and Nss are coupled. However, same Nss does not have to apply for 80MHz, 160MHz and 80+80MHz BW.	Use B2-B3 bits to indicate if 80+80MHz or 160MHz BWs are used.
3477	1298.33	33	9.13.6	Vinko Erceg	11-14/1104r4	The second bullet appears to allow a VHT single MPDU (i.e. one with EOF = 1) to be followed by null subframes with EOF = 0. Once EOF has been signalled, it makes no sense to unsignal it (cf. 145.33)	Change "0 in the EOF field" to "the same value in the EOF field as the preceding A-MPDU subframe"
3673	1475.57	57	9.38.2.4			"Sector Sweep Feedback (SSW Feedback) occurs following each RSS.": is this just some naturally occuring phenonmenon? Need to indicate who issues the SSW Feedback frame, as well as the fact it is a frame.	Replace "(SSW Feedback) occurs following each RSS." with "(SSW Feedback) frame is issued by the STA after it completes each RSS."	EDITOR_Q: 2014-09-04 23:12:01Z - Need input from the domain experts. Transferred to MAC.
3674	1476.38	38	9.38.2.5			"When present, the Sector Sweep Ack (SSW-Ack) occurs following an SSW Feedback.": is this just a natural occurance? Need to indicate what STA issues this frame (and the fact that these two names are the names of frames).	Replace "(SSW-Ack) occurs following" with "(SSW-Ack) frame is issued after the STA receives an SSW Feedback frame."	Need inputs from domain experts. Transferred to MAC.

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.