[STDS-802-11-TGM] https://mentor.ieee.org/802.11/dcn/13/11-13-0233-29-00

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

Some updates from the last telecon applied.

Current status is:

Ballot/Draft	Assigned	Discuss	Ready for Motion	Approved	Grand Total
199	33	1	21	442	497
EDITOR			1	442	443
201311 approved				189	189
201401 approved				105	105
201403 approved				148	148
Editor Motion May 2014			1		1
GEN	12	1	4		17
Gen Review	1				1
Submission requested	4				4
(blank)	2	1			3
Deprecation	3				3
Assigned to Adrian	2				2
Gen Motion Telecon April-May			4		4
MAC	21		16		37
(blank)	21				21
Motion MAC-X			16		16
Grand Total	33	1	21	442	497

And the assigned comments:

show assigned comments
Assignee	CID	LB	Commenter	Type of Comment	Part of No Vote	Page	Clause	Comment	Proposed Change	Owning Ad-hoc	Ad-hoc Status	Ad-hoc Notes	state
Adrian Stephens	2051	199	Adrian Stephens	G	Y	1133.38	9.4.4.3	Desire considered dangerous. We have 136 instances of desire(d\|s). But STAs don't have desire. Worse, when used in the passive voice (e.g. "the desired UP", "unless extra protection against PCF collisions is desired.") the identity of the entity suffering these pangs of desire is discretely hidden.I claim that this word is harmful and should be eliminated. "unless extra protection against PCF collisions is desired" could become "unless a STA determined that extra protection against PCF collisions is needed. How a STA makes this determination is implementation defined."	Review all uses of "desire" and replace with non-emotive language based on observables.e.g. "desired" BSSIS can become a target BSSID.	MAC	Needs submission	Propose: Agree in priniciple. Needs a submission.	Assigned
Adrian Stephens	2060	199	Adrian Stephens	G	N	3050.34	O.2	The changes indicated in the resolution of comment 234 on figure O-3 made no sense to me as editor.	Please review Figure O-3 versus the resolution of comment 234 and determine if any additional changes are necessary.	GEN	Discuss	See CID 2463	Assigned
Adrian Stephens	2094	199	Adrian Stephens	T	Y	1294.21	9.35.2.2	"may ignore DMG Beacon frames" -- what is the normative effect of "ignoring" something? Is this actually an exception to behaviour described elsewhere?	Add the exception to the material it is an exception to.	MAC			Assigned
Adrian Stephens	2157	199	Adrian Stephens	G	Y	1437.35	10.4.10	Generally there's a lot of unnecessary qualification introduced by .11ad. For example in " PCP shall send a DELTS frame to the non-PCP DMG STA", it is unnecessary to include DMG in "non-PCP DMG STA" because the PCP cannot send a DELTS to a non-DMG STA. We went through a process in REVmb days of removing unnecessary "QoS" qualifications. Looks like we might need to do the same for DMG.	Review this subclause and remove any unnecessary qualification.	MAC			Assigned
Adrian Stephens	2183	199	Adrian Stephens	G	Y	2383	B.4.24.1	Invalid or bogus references at:2386.10 (8.4.2.111.2), 2386.11 (11.3), 2386.15 (8.4.2.145),2386.23 (9.13a9.14),2387.31 (9.4.2.138), 2387.35 (8.4.2.140),2387.44 & 2387.57 (8.4.2.138),2392.55 (8.4.2.138), 2392.59 (8.4.2.140),2393.07 (8.4.2.138), 2393.11 (8.4.2.140)		GEN	Needs submission	GEN: 2014-02-21 16:00:18Z change assignment to Adrian	Assigned
Adrian Stephens	2185	199	Adrian Stephens	G	Y			There are ~30 "shall ignore" statements.The danger with these, is that they are used to create exceptions to rules, without recording the exception in the rule itself.Or they are clarifications that no such requirement exists.For example: "If A then do B. If A and C, Ignore A."This should instead be "If A and not C, do B."	Review all "shall ignore" statements and replace them either:1. With an informative note " ... ignores ..."2. By adding an exception to a separate rule tha the "shall ignore" attempts to "override".	GEN	Needs submission		Assigned
Adrian Stephens	2463	199	Mark Hamilton	T	Y	3050.27	O.2	The Editor was right to be unsure about the resolution to CID 234, there is an error in Figure O-3. The AID 0 arrow should not be there to the second row. Also the O-5 changes are not complete.	Delete the second (lower) arrow for AID 0 in Figure O-3. On Figure O-5, add an indication of AID 0, with a split arrow to both the left cells (first and second row). Change the title of Figure O-7 to "Partial Virtual Bitmap example #5" (including lower-case 'e').	GEN	Discuss	GEN: 2014-03-18 09:59:43Z - See CID 234 as well Proposed Accept - See CID 2060	Assigned
Dorothy Stanley	2411	199	Graham Smith	T	Y	1949.01	16	As noted in CID 32,"11b is Poison". Clause 16 devices have the capability of bringing 2.4GHz networks to their knees. 13/0416 (latest is r5 at time of writing comment) shows that there is no technical reason to maintain Clause 16 devices. It is suggested that a note be added to this Clause to indicate that it is now 'out of favor' and that it is likely to be dropped in the (near) future.	Add text under heading "Devices supporting the DSSS system are no longer encouraged and likely to be deprecated from this Specification in subsequent revisions"	GEN	Needs submission		Assigned
Dorothy Stanley	2412	199	Graham Smith	T	Y	1974.01	17	As noted in CID 32,"11b is Poison". Clause 17 devices are coupled to Clause 16 DSSS and as such have the capability of bringing 2.4GHz networks to their knees. 13/0416 (latest is r5 at time of writing comment) shows that there is no technical reason to maintain Clause 16 or 17 devices. It is suggested that a note be added to this Clause to indicate that it is now 'out of favor' and that it is likely to be dropped in the (near) future.	Add text under heading "Devices supporting the high rate extention to the DSSS system are no longer encouraged and likely to be deprecated from this Specification in subsequent revisions"	GEN	Needs submission		Assigned
Dorothy Stanley	2423	199	John Coffey	T	Y	2048.25	9.1.2	The standard requires 11n and 11g (i.e., HT and ERP) PHYs to support transmit and receive of all 11b modes. Given the enormous disparity in efficiency between 11b and the OFDM modes, this no longer makes sense as a universal requirement for all products, and any such requirements should be removed, if not necessary to support coexistence. A straightforward way of accomplishing at least some of this is to remove the requirement that ERP PHYs support the 5.5 and 11 Mbps CCK data rates. Since Clause 20 (HT) references Clause 19 (ERP), this would remove 5.5 and 11 Mbps as requirements for HT also. This would not affect the requirment to be able to detect the long or short preamble (1 Mbps and 2 Mbps) and to take appropriate action based on such a detection, thus preserving the current level of coexistence.	Delete 5.5 and 11 from list of mandatory data rates for ERP PHY. Also make corresponding changes throughout, including section 9.1.3 (P2048 LL30-37) (add 5.5 and 11 to list of exceptions); section 19.3.5 (P2054 LL39-40) (delete 5.5 and 11 from list); and Annex B.4.9 (P2307 LL33-37) (remove 5.5 and 11; add new entry ERP1a for 5.5 and 11, optional)	GEN	Needs submission		Assigned
Graham Smith	2413	199	Graham Smith	T	Y	2027.12	18.3.10.6	We know where -82dBm comes from (min sensitivity). Is it OK to assume the 'common' -72dBm was chosen simply on 10dB above this level (i.e. about 50% of the range - not really as on practice -92dBm is minimum sensitivity)? Similarly the common -62dBm as 20dB above minimum (i.e. about 25% of the extreme range)? Is there any regulatory basis for this or, most likely, is it based on letting a Wi-Fi STA at the furthest range get in? This is based upon maximum range concerns not so much a 'managed' range/cell. There is a real case to consider allowing higher CCA such that the overall traffic can be increased as explained in presentation 13/1012	Change CCA levels from mandatory. Consider allowing new CCA text which could be proposed by commenter. This also applies to Clauses 19.4.5 and 20.3.20.5.2	GEN	Needs submission		Assigned
Mark Hamilton	2005	199	Adrian Stephens	T	Y	29.44	3.2	The "See EAPOL-Key frame" is bogus, because the two terms are no longer synonyms.	Add a definition, or delete cited entry	MAC	Review	MAC: 2014-03-09 20:16:47Z: Revised. Change the definition of EAPOL-Start to be "A Data MPDU that carries all or part of an 802.1X EAPOL PDU of type EAPOL-Start."	Assigned
Mark Hamilton	2009	199	Adrian Stephens	G	Y	140.01	6.3.4.2.2	The JOIN.request primitive is of dubious use. In a non-FHSS (remember, we just got that to hop out of the standard), this has no effect on behavior. No frames are transmitted based on this primitive. No state machines are affected.Why then does this primitive still exist?And if we want to keep the primitive, why does it need things like HT Operational Rate Set?	Remove the MLME-Join primitives and all references to them.Or failing that, delete all but the Selected BSS parameter.	MAC	Discuss	MAC: 2014-03-10 03:46:14Z: Propose: Reject. MLME-JOIN serves an explicit purpose, as described in 10.1.4.5. In particular, the non-AP STA will synchronize its TSF to the AP (allowing it to follow Beacon timing from this point in time). This primitive is also used to set a number of operating parameters which are otherwise not in any MLME primitive issued by a non-AP STA (for example, the rate set parameters, including HTOperationalMCSSet). In this way, the MLME-JOIN is parallel to the MLME-START in terms of initializing the MAC to specific (perhaps non-default) operating parameters. It is agreed that there is some redundancy between MLME-JOIN and later primitives (especially MLME-ASSOCIATE). A submission is needed to address this, specifically.	Assigned
Mark Hamilton	2054	199	Adrian Stephens	G	Y	1152.11	9.11	What is a "non-DMG network"? Surely better to related to transmission by a non-DMG STA, in which case why not insert "non-DMG" twice, as is done elsewhere?	Replace "in a non-DMG" network by inserting "non-DMG" betfore STA at the start of these two statements. Remove the introductory sentence and promote to body text.	MAC	Review	MAC: 2014-03-10 04:25:34Z - Revised. Accept proposed changes. Also, at 1116L18, delete "in a non-DMG network"; at 1158L7, replace "non-DMG network" with "non-DMG BSS"; at 1167L60, replace "non-DMG network" with "non-DMG BSS"; at 1227L21, replace "non-DMG network" with "non-DMG BSS"; at 1227L25, replace "DMG network" with "DMG BSS".	Assigned
Mark Hamilton	2119	199	Adrian Stephens	T	N	97.39	4.9.3	"Since multiple STAs coordinated by the same MM-SME share the PHY, the STAs do not directly exchange frames with each other."I am not sure exactly what this is saying. Is it saying that the STAs do not need to exchange frames, or are not capabile of exchaning frames?If it is saying they cannot, then we have changed the meaning of the MAC service to one that can neither transmit nor receive from certain MAC addresses. For example, a broadcast does not reach all the MACs in the BSS (ignoring packet errors) because of this.	Add these constraints to the description of the MAC data service.	MAC	Review	MAC: 2014-03-09 20:45:11Z: Revised. Change, "STAs do not directly exchange frames with each other" to "STAs can not directly exchange frames with each other." This addresses the ambiguity of the statement. As for the MAC Service, nowhere does the MAC Service say or imply that all STAs can exchange frames directly with each other - consider hidden nodes, for example. Thus, no further change is needed.	Assigned
Mark Hamilton	2154	199	Adrian Stephens	G	Y	1432.23	10.4.4.4	"All MSDUs corresponding to a TID that was successfully negotiated through the ADDTS exchange with a U-PID element with the No-LLC field equal to 1(M34) shall have their LLC header stripped before transmission and the agreed LLC header added before delivery at the peer MAC-SAP. (11ad)"Passive voice considered dangerous. The following statement "shall have ... stripped" hides who does this. Also this is not an MLME activity, but a MAC data-plane activity, and may be above the MAC data SAP.	Determine where the stripping takes place. If it is in the MAC data plane, move this statement into clause 9. If it is above the MAC data plane, this is out of scope, and move it to an informative annex.Reword so that it cites the entity responsible for this action.	MAC	Review	MAC: 2014-03-18 09:25:28Z: Revised. Change to, "Before transmission, the MAC shall strip the LLC header from all MSDUs corresponding to a TID that was successfully negotiated through the ADDTS exchange with a U-PID element with the No-LLC field equal to 1, and the negotiated header shall by added by the peer MAC before delivery at the peer MAC-SAP."	Assigned
Mark Hamilton	2155	199	Adrian Stephens	T	Y	1434.4	10.4.7	The changes from CID 1412 removed the ADDTS failure timeout. The changes to the figures 10-16 should be more radical than described in that comment resolution, because now a .confirm is not provided in the case of timeout. Errors are handled above the MLME by the SME, which might choose to send an MLME-DELTS.request to cover case 2.	Remove the timeout from the two cases in Figure 10-16. Consider adding mandatory SME behavior on timout to send a DELTS.request in the case of timeout.Remove the text: "shall send a DELTS to the HC specifying the TSID and direction of the failed request"	MAC			Assigned
Mark Hamilton	2168	199	Adrian Stephens	G	Y	1623.4	10.33.2.2	Embedded "magic numbers"	Replace with name of status code throughout table.	MAC	Needs submission	MAC: 2014-01-17 05:44:40Z: Agree completely, and the text just before, and a few pages after the table has the same problem. However, the root cause of this problem is that table 8-42 doesn't have a name for very many of the values, so there is no agreed name to reference in other locations like the cited location. See CID 91 which was intended to address the root cause. Then, the cited location (and nearby text) could be modified to align. But, CID 91 died of loneliness.	Assigned
Mark Hamilton	2360	199	David Hunter	E	Y	1470.19	10.11.4	Confused writing makes the requirements unclear. What exactly does "shall not be set to 0 except for Beacon request with Measurement Mode set to Beacon Table Mode, Statistics request and request for triggered autonomous measurements." mean? Also: "Beacon Table Mode" does not appear to be the name of a frame, field, element, etc, so should be in lower case. Is it clear what type of frame constitutes the last type of request? Where is that specified?	Delete the comma after "frames" and replace the quoted sentence fragment with "shall not be set to 0 except when the request frame is a Beacon request in which the Measurement Mode field value is beacon table mode, or is a Statistics request frame, or is a request for triggered autonomous measurements." And specify exactly what frames make up the "request for triggered autonomous measurements". Also specify explictly somewhere (MIB?) the value of "beacon table mode".	MAC	Discuss	MAC: 2014-01-19 16:50:09Z - Is the terminology (for example), "Statistics request frame" what we want to use for a Measurement Request frame that has a Measurement Report element which has the Measurement Type field set to STA statistics report? The full description is way too wordy, and we need shorthand phrase. What is the right/best shorthand? A nit: there is also a Directional statistics report, so we cannot shorthand to just "statistics", we need to say "STA statistics" EDITOR: 2013-10-25 13:49:11Z The proposed resolution does not address 'And specify exactly what frames make up the "request for triggered autonomous measurements"', which requires technical interpretation. Transferring to MAC to continue the resolution. The resolution as of this date will be present in D2.1, and will be adjusted to track any subsequent changes in MAC.	Assigned
Mark Hamilton	2410	199	Graham Smith	T	Y	2745.02		dot11HRCCAModeImplemented only appears in Annex C.3 I can find no reference to it outside of Annex C.3. Suggest it is deleted.	Delete dot11HRCCAModeImplemented at P2745L2, P2753L57, P2754L8-27, P2819L37	GEN	Needs submission	GEN: assigned to Mark HAMILTON - Dec 20, 2013	Assigned
Mark Hamilton	2434	199	Mark Hamilton	T	Y	116.01	5.2.1	Figure 5-1 is confusing. It looks a lot like 802.1Q's bridge diagram, but this is not at all the same thing. It also has several unlabeled blocks which are confusing. And, it implies that 802.1X port control is above LLC which is incorrect.	Replace Figure 5-1 with that contained in a submission from the ARC SC.	GEN	Needs submission		Assigned
Mark Hamilton	2454	199	Mark Hamilton	T	Y	1093.19	9.2.2	Figure 9-1 still has FH, IR, etc.	Delete "FHSS, IR" from this figure	MAC	Review	MAC: 2014-03-18 09:00:02Z: Changes already made by the Editor.	Assigned
Mark Hamilton	2455	199	Mark Hamilton	T	Y	1093.02	9.2.2	Figure 9-1 line to DCF is confusing	Draw the figure so that label connectors don't have to pass "behind" boxes (making it look like they are connecting to that box). Push the label off to one side so that it's connector can be drawn without disappearing behind boxes. (If it has to disappear behind other labels, that's not ideal, but better.) Do this for the DCF label and the SP Access label.	MAC	Review	MAC: 2014-03-18 07:59:37Z: Revised. Redraw with the two referenced labels moved to the side and down, as shown in 14-0422r0.	Assigned
Mark Hamilton	2458	199	Mark Hamilton	T	Y	1160.6	9.20.2.3	EDCAF operation needs help to improve understanding - it has not evolved well. For example, 9.19.2.3 has become a convoluted machine built from 4 separate bullet lists. 9.19.2.3 and 9.19.2.5 both discuss backoff counter decrements, and when they occur. 9.2 shows EDCA as "on top of" DCF, but EDCA TXOPs violate 9.3.4.3 (6th paragraph). Etc.	This needs off-line work, and a thought-out proposal.	MAC	Needs submission		Assigned
Mark Hamilton	2459	199	Mark Hamilton	T	Y	217.32	6.3.26.6.2	Get rid of all TIMEOUT and UNSPECIFIED_FAILURE ReasonCode values, unless there is discussion of them explicit in the protocol/behavior (and then give them a descriptive name)	Get rid of all TIMEOUT and UNSPECIFIED_FAILURE ReasonCode values, unless there is discussion of them explicit in the protocol/behavior (and then give them a descriptive name)	GEN	Needs submission		Assigned
Mark Hamilton	2460	199	Mark Hamilton	T	Y	588.01	8.4.1.9	All StatusCodes and ResultCodes should have a name	It's just easier to talk about these, if they have a name.	MAC	Needs submission		Assigned
Mark Hamilton	2462	199	Mark Hamilton	T	Y	1417.42	10.3.5.4	Reassociation to the same AP behaviour is not clearly defined (e.g. effect on TSes, whether failure leaves you unassociated, whether you need to re-do 4WH, meaning of PM bit in Reassociation Request, etc.)	Clarify that reassociation to the same AP transitions the non-AP STA to not be in power save mode. No other behaviors are affected.	MAC	Needs submission	MAC: 2013-11-13 22:37:13Z: Yes, you shall do the 4WH again (or FT) - well, you will lose your PTK. Did the group that shall not be named agree with the above? Check on TSes, too. And, testing of the above. It might be wishful thinking to think anything will be retained. (Could put in text warning of this.)	Assigned
Mark Hamilton	2464	199	Mark Hamilton	T	Y	510.51	8.2.4.1.7	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 senseIt'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	MAC	Needs submission		Assigned
Mark Rison	2425	199	Jon Rosdahl	G	Y	2233.01		CID 269: Scrub PICS: was was assigned to Mark RISON -- who created 11-12/1345r0, the submission was overreaching, and corrected more than was requested/thought by the comments.	Document 11-12/1345r0 contains many changes to the PICS that would be a positive change. A new Document will be prepared to identify those changes and submitted to the REVmc Task Group	GEN	Needs submission		Assigned
Matthew Fischer	2471	199	Matthew Fischer	T	Y	1155.55	9.19	Several elements and frames use the operating class. Additions were made to the operating class for 11n and 11ac. These additions were for wider BW modes - older STA do not understand those operating classes, but the STA operating in the new operating classes generally include backwards compatible operating modes.e.g. 11ac includes 80 mhz BW operation and there is an operating class to support thislegacy 11a STA do not understand the new operating class, but they can probably still associate as 20 mhz only STA, and therefore, would benefit by knowing that the 20 mhz operating class is supported by the target BSS/APTherefore, whenever operating class is transmitted, it should be transmitted with the highest possible mutual understood operating class between the sender and the receiver, limited by the highest supported operating class of the third party being described		MAC	Needs submission		Assigned
Matthew Fischer	2473	199	Matthew Fischer	T	Y	629.62	8.4.2.3	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.	As suggested.	MAC	Needs submission		Assigned
Matthew Fischer	2479	199	Matthew Fischer	T	Y	539.08	8.3.1.9.1	The highest indicated modulation and stream combinations for some PHYs result in phy rates that will reduce throughput efficiency to exceedingly low levels if the maximum block ack window size is not allowed to increase beyond the existing 64.	Increase the maximum allowed MPDUs in the Block Ack frame to 256 by creating a new form of Block Ack that supports a longer BA window and a longer BA bitmap	MAC	Needs submission		Assigned
Matthew Fischer	2481	199	Matthew Fischer	T	Y	1142.14	9.7.6.5	ACK (and other control response frames) are supposed to be sent at rates as specified in this subclause. Generally speaking, this subclause prescribes ACK transmission at a Basic Rate, which is, for eliciting frames that are transmitted at higher rate or MCS values, typically a rate that is lower than the rate or MCS of the eliciting frame by at least two increments. When the eliciting frame is at one of the lower rates/MCS, then the ACK will often be at the same rate/MCS. Normally, this is ok - reliability of the ACK transmission is good or better than the eliciting frame because the eliciting frame usually has significantly more bits than the ACK. But if the eliciting STA has a higher TX power, then the rate for the ACK can be too high and is very likely to fail. It would be nice if the eliciting STA can signal to the responder that a lower rate/MCS will be needed. This ensures a receiveable ACK and it allows the eliciting STA to correctly compute the ACK duration for DUR field use.	Allow a control response frame to be sent at a rate/MCS lower than otherwise allowed when there is a power difference or for other reasons. Create a mechanism that allows the eliciting STA to indicate the preferred response rate/MCS. E.g. signal in the eliciting frame, a value of step down in rate/MCS from the normally computed value for the response frame.	MAC	Needs submission		Assigned

Best Regards,

Adrian P STEPHENS

Tel: +44 (1793) 404825 (office)
Tel: +44 (7920) 084 900 (mobile, UK)

Tel: +1 (408) 2397485 (mobile, USA)

----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

From: Stephens, Adrian P
Sent: 09 April 2014 13:32
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: https://mentor.ieee.org/802.11/dcn/13/11-13-0233-28-000m-revmc-wg-ballot-comments.xls uploaded and current status

Dear TGmc members,

Following last week’s telecon, I have updated

https://mentor.ieee.org/802.11/dcn/13/11-13-0233-28-000m-revmc-wg-ballot-comments.xls

to show the current state of play.

Here is our current status:

Ballot/Draft	Assigned	Discuss	Ready for Motion	Approved	Grand Total
199	37	1	17	442	497
EDITOR			1	442	443
201311 approved				189	189
201401 approved				105	105
201403 approved				148	148
Editor Motion May 2014			1		1
GEN	16	1			17
Gen Review	1				1
Submission requested	4				4
(blank)	2	1			3
Deprecation	4				4
Assigned to Adrian	4				4
Assigned to Dorothy	1				1
MAC	21		16		37
(blank)	21				21
Motion MAC-X			16		16
Grand Total	37	1	17	442	497

The following have assignments:

Assignee	GEN	MAC	Grand Total
Adrian Stephens	6	3	9
Dorothy Stanley	5		5
Graham Smith	1		1
Mark Hamilton	3	14	17
Mark RISON	1		1
Matthew Fischer		4	4
Grand Total	16	21	37

show assigned comments
Assignee	CID	LB	Commenter	Type of Comment	Part of No Vote	Page	Clause	Comment	Proposed Change	Owning Ad-hoc	Ad-hoc Status	Ad-hoc Notes	state
Adrian Stephens	2051	199	Adrian Stephens	G	Y	1133.38	9.4.4.3	Desire considered dangerous. We have 136 instances of desire(d\|s). But STAs don't have desire. Worse, when used in the passive voice (e.g. "the desired UP", "unless extra protection against PCF collisions is desired.") the identity of the entity suffering these pangs of desire is discretely hidden.I claim that this word is harmful and should be eliminated. "unless extra protection against PCF collisions is desired" could become "unless a STA determined that extra protection against PCF collisions is needed. How a STA makes this determination is implementation defined."	Review all uses of "desire" and replace with non-emotive language based on observables.e.g. "desired" BSSIS can become a target BSSID.	MAC	Needs submission	Propose: Agree in priniciple. Needs a submission.	Assigned
Adrian Stephens	2060	199	Adrian Stephens	G	N	3050.34	O.2	The changes indicated in the resolution of comment 234 on figure O-3 made no sense to me as editor.	Please review Figure O-3 versus the resolution of comment 234 and determine if any additional changes are necessary.	GEN	Discuss	See CID 2463	Assigned
Adrian Stephens	2094	199	Adrian Stephens	T	Y	1294.21	9.35.2.2	"may ignore DMG Beacon frames" -- what is the normative effect of "ignoring" something? Is this actually an exception to behaviour described elsewhere?	Add the exception to the material it is an exception to.	MAC			Assigned
Adrian Stephens	2157	199	Adrian Stephens	G	Y	1437.35	10.4.10	Generally there's a lot of unnecessary qualification introduced by .11ad. For example in " PCP shall send a DELTS frame to the non-PCP DMG STA", it is unnecessary to include DMG in "non-PCP DMG STA" because the PCP cannot send a DELTS to a non-DMG STA. We went through a process in REVmb days of removing unnecessary "QoS" qualifications. Looks like we might need to do the same for DMG.	Review this subclause and remove any unnecessary qualification.	MAC			Assigned
Adrian Stephens	2177	199	Adrian Stephens	T	Y	2184.15	21.3.10	Either the changes made for Motion 34 (less than becomes less than or equal) are incorrect, in which case they should be unmade. Or they are correct, in which case matching changes need to be made in the other PHY clauses, and on the equation line below.Changes at lines 15 and 22.	Either unmake changes or propagate to other PHYs.	GEN	Needs submission		Assigned
Adrian Stephens	2182	199	Adrian Stephens	T	Y	2219.58	21.9	"the PHY shall maintain (#1601)PHY-CCA.indication(BUSY) primitive for any signal 20 dB higher" -- Indications are discrete events, not continuous signals. "shall maintain" is incorrect.	Propagate changes for the same reason from the HT PHY.	GEN	Needs submission		Assigned
Adrian Stephens	2183	199	Adrian Stephens	G	Y	2383	B.4.24.1	Invalid or bogus references at:2386.10 (8.4.2.111.2), 2386.11 (11.3), 2386.15 (8.4.2.145),2386.23 (9.13a9.14),2387.31 (9.4.2.138), 2387.35 (8.4.2.140),2387.44 & 2387.57 (8.4.2.138),2392.55 (8.4.2.138), 2392.59 (8.4.2.140),2393.07 (8.4.2.138), 2393.11 (8.4.2.140)		GEN	Needs submission	GEN: 2014-02-21 16:00:18Z change assignment to Adrian	Assigned
Adrian Stephens	2185	199	Adrian Stephens	G	Y			There are ~30 "shall ignore" statements.The danger with these, is that they are used to create exceptions to rules, without recording the exception in the rule itself.Or they are clarifications that no such requirement exists.For example: "If A then do B. If A and C, Ignore A."This should instead be "If A and not C, do B."	Review all "shall ignore" statements and replace them either:1. With an informative note " ... ignores ..."2. By adding an exception to a separate rule tha the "shall ignore" attempts to "override".	GEN	Needs submission		Assigned
Adrian Stephens	2463	199	Mark Hamilton	T	Y	3050.27	O.2	The Editor was right to be unsure about the resolution to CID 234, there is an error in Figure O-3. The AID 0 arrow should not be there to the second row. Also the O-5 changes are not complete.	Delete the second (lower) arrow for AID 0 in Figure O-3. On Figure O-5, add an indication of AID 0, with a split arrow to both the left cells (first and second row). Change the title of Figure O-7 to "Partial Virtual Bitmap example #5" (including lower-case 'e').	GEN	Discuss	GEN: 2014-03-18 09:59:43Z - See CID 234 as well Proposed Accept - See CID 2060	Assigned
Dorothy Stanley	2401	199	David Hunter	T	Y	3036.17		Recommended practices ("should" statements) do not belong in an informative clause (Annex N).	Do one of:-- Replace "Recommended practices: in the title of N.2 with "Current practices" and rewrite all of the "It is recommended" statements as statements of fact about current practices-- Delete N.2.-- List Annex N (on page 3038) as normative.	GEN	Discuss	GEN: 2014-03-12 initially started to review, more discussion needed.	Assigned
Dorothy Stanley	2411	199	Graham Smith	T	Y	1949.01	16	As noted in CID 32,"11b is Poison". Clause 16 devices have the capability of bringing 2.4GHz networks to their knees. 13/0416 (latest is r5 at time of writing comment) shows that there is no technical reason to maintain Clause 16 devices. It is suggested that a note be added to this Clause to indicate that it is now 'out of favor' and that it is likely to be dropped in the (near) future.	Add text under heading "Devices supporting the DSSS system are no longer encouraged and likely to be deprecated from this Specification in subsequent revisions"	GEN	Needs submission		Assigned
Dorothy Stanley	2412	199	Graham Smith	T	Y	1974.01	17	As noted in CID 32,"11b is Poison". Clause 17 devices are coupled to Clause 16 DSSS and as such have the capability of bringing 2.4GHz networks to their knees. 13/0416 (latest is r5 at time of writing comment) shows that there is no technical reason to maintain Clause 16 or 17 devices. It is suggested that a note be added to this Clause to indicate that it is now 'out of favor' and that it is likely to be dropped in the (near) future.	Add text under heading "Devices supporting the high rate extention to the DSSS system are no longer encouraged and likely to be deprecated from this Specification in subsequent revisions"	GEN	Needs submission		Assigned
Dorothy Stanley	2423	199	John Coffey	T	Y	2048.25	9.1.2	The standard requires 11n and 11g (i.e., HT and ERP) PHYs to support transmit and receive of all 11b modes. Given the enormous disparity in efficiency between 11b and the OFDM modes, this no longer makes sense as a universal requirement for all products, and any such requirements should be removed, if not necessary to support coexistence. A straightforward way of accomplishing at least some of this is to remove the requirement that ERP PHYs support the 5.5 and 11 Mbps CCK data rates. Since Clause 20 (HT) references Clause 19 (ERP), this would remove 5.5 and 11 Mbps as requirements for HT also. This would not affect the requirment to be able to detect the long or short preamble (1 Mbps and 2 Mbps) and to take appropriate action based on such a detection, thus preserving the current level of coexistence.	Delete 5.5 and 11 from list of mandatory data rates for ERP PHY. Also make corresponding changes throughout, including section 9.1.3 (P2048 LL30-37) (add 5.5 and 11 to list of exceptions); section 19.3.5 (P2054 LL39-40) (delete 5.5 and 11 from list); and Annex B.4.9 (P2307 LL33-37) (remove 5.5 and 11; add new entry ERP1a for 5.5 and 11, optional)	GEN	Needs submission		Assigned
Dorothy Stanley	2424	199	John Coffey	T	N	2048.37	9.1.3	The standard requires 11n and 11g (i.e., HT and ERP) PHYs to support transmit and receive of the 11b Short Preamble. This is optional for 11b. This requirement no longer makes sense (if it ever did), as there are legacy deployed devices that do not recognize the short preamble or defer for it, and it seems that most deployed devices do not transmit the short preamble.	Remove the sentence beginning "In addition, it is mandatory ...". Also make corresponding changes throughout, including section 19.3.2.1 (P2052 LL32-41) (change "three" to "two" and delete short preamble from list; add extra line saying that an ERP STA may support the short preamble); section 19.3.2.3 (P2053 L16) (delete sentence begiining "For the ERP..."); section 19.3.5 (P2054 L40) (delete "or short"), and (P2054 L46) (delete "short preamble").	GEN	Needs submission		Assigned
Graham Smith	2413	199	Graham Smith	T	Y	2027.12	18.3.10.6	We know where -82dBm comes from (min sensitivity). Is it OK to assume the 'common' -72dBm was chosen simply on 10dB above this level (i.e. about 50% of the range - not really as on practice -92dBm is minimum sensitivity)? Similarly the common -62dBm as 20dB above minimum (i.e. about 25% of the extreme range)? Is there any regulatory basis for this or, most likely, is it based on letting a Wi-Fi STA at the furthest range get in? This is based upon maximum range concerns not so much a 'managed' range/cell. There is a real case to consider allowing higher CCA such that the overall traffic can be increased as explained in presentation 13/1012	Change CCA levels from mandatory. Consider allowing new CCA text which could be proposed by commenter. This also applies to Clauses 19.4.5 and 20.3.20.5.2	GEN	Needs submission		Assigned
Mark Hamilton	2005	199	Adrian Stephens	T	Y	29.44	3.2	The "See EAPOL-Key frame" is bogus, because the two terms are no longer synonyms.	Add a definition, or delete cited entry	MAC	Review	MAC: 2014-03-09 20:16:47Z: Revised. Change the definition of EAPOL-Start to be "A Data MPDU that carries all or part of an 802.1X EAPOL PDU of type EAPOL-Start."	Assigned
Mark Hamilton	2009	199	Adrian Stephens	G	Y	140.01	6.3.4.2.2	The JOIN.request primitive is of dubious use. In a non-FHSS (remember, we just got that to hop out of the standard), this has no effect on behavior. No frames are transmitted based on this primitive. No state machines are affected.Why then does this primitive still exist?And if we want to keep the primitive, why does it need things like HT Operational Rate Set?	Remove the MLME-Join primitives and all references to them.Or failing that, delete all but the Selected BSS parameter.	MAC	Discuss	MAC: 2014-03-10 03:46:14Z: Propose: Reject. MLME-JOIN serves an explicit purpose, as described in 10.1.4.5. In particular, the non-AP STA will synchronize its TSF to the AP (allowing it to follow Beacon timing from this point in time). This primitive is also used to set a number of operating parameters which are otherwise not in any MLME primitive issued by a non-AP STA (for example, the rate set parameters, including HTOperationalMCSSet). In this way, the MLME-JOIN is parallel to the MLME-START in terms of initializing the MAC to specific (perhaps non-default) operating parameters. It is agreed that there is some redundancy between MLME-JOIN and later primitives (especially MLME-ASSOCIATE). A submission is needed to address this, specifically.	Assigned
Mark Hamilton	2054	199	Adrian Stephens	G	Y	1152.11	9.11	What is a "non-DMG network"? Surely better to related to transmission by a non-DMG STA, in which case why not insert "non-DMG" twice, as is done elsewhere?	Replace "in a non-DMG" network by inserting "non-DMG" betfore STA at the start of these two statements. Remove the introductory sentence and promote to body text.	MAC	Review	MAC: 2014-03-10 04:25:34Z - Revised. Accept proposed changes. Also, at 1116L18, delete "in a non-DMG network"; at 1158L7, replace "non-DMG network" with "non-DMG BSS"; at 1167L60, replace "non-DMG network" with "non-DMG BSS"; at 1227L21, replace "non-DMG network" with "non-DMG BSS"; at 1227L25, replace "DMG network" with "DMG BSS".	Assigned
Mark Hamilton	2119	199	Adrian Stephens	T	N	97.39	4.9.3	"Since multiple STAs coordinated by the same MM-SME share the PHY, the STAs do not directly exchange frames with each other."I am not sure exactly what this is saying. Is it saying that the STAs do not need to exchange frames, or are not capabile of exchaning frames?If it is saying they cannot, then we have changed the meaning of the MAC service to one that can neither transmit nor receive from certain MAC addresses. For example, a broadcast does not reach all the MACs in the BSS (ignoring packet errors) because of this.	Add these constraints to the description of the MAC data service.	MAC	Review	MAC: 2014-03-09 20:45:11Z: Revised. Change, "STAs do not directly exchange frames with each other" to "STAs can not directly exchange frames with each other." This addresses the ambiguity of the statement. As for the MAC Service, nowhere does the MAC Service say or imply that all STAs can exchange frames directly with each other - consider hidden nodes, for example. Thus, no further change is needed.	Assigned
Mark Hamilton	2154	199	Adrian Stephens	G	Y	1432.23	10.4.4.4	"All MSDUs corresponding to a TID that was successfully negotiated through the ADDTS exchange with a U-PID element with the No-LLC field equal to 1(M34) shall have their LLC header stripped before transmission and the agreed LLC header added before delivery at the peer MAC-SAP. (11ad)"Passive voice considered dangerous. The following statement "shall have ... stripped" hides who does this. Also this is not an MLME activity, but a MAC data-plane activity, and may be above the MAC data SAP.	Determine where the stripping takes place. If it is in the MAC data plane, move this statement into clause 9. If it is above the MAC data plane, this is out of scope, and move it to an informative annex.Reword so that it cites the entity responsible for this action.	MAC	Review	MAC: 2014-03-18 09:25:28Z: Revised. Change to, "Before transmission, the MAC shall strip the LLC header from all MSDUs corresponding to a TID that was successfully negotiated through the ADDTS exchange with a U-PID element with the No-LLC field equal to 1, and the negotiated header shall by added by the peer MAC before delivery at the peer MAC-SAP."	Assigned
Mark Hamilton	2155	199	Adrian Stephens	T	Y	1434.4	10.4.7	The changes from CID 1412 removed the ADDTS failure timeout. The changes to the figures 10-16 should be more radical than described in that comment resolution, because now a .confirm is not provided in the case of timeout. Errors are handled above the MLME by the SME, which might choose to send an MLME-DELTS.request to cover case 2.	Remove the timeout from the two cases in Figure 10-16. Consider adding mandatory SME behavior on timout to send a DELTS.request in the case of timeout.Remove the text: "shall send a DELTS to the HC specifying the TSID and direction of the failed request"	MAC			Assigned
Mark Hamilton	2168	199	Adrian Stephens	G	Y	1623.4	10.33.2.2	Embedded "magic numbers"	Replace with name of status code throughout table.	MAC	Needs submission	MAC: 2014-01-17 05:44:40Z: Agree completely, and the text just before, and a few pages after the table has the same problem. However, the root cause of this problem is that table 8-42 doesn't have a name for very many of the values, so there is no agreed name to reference in other locations like the cited location. See CID 91 which was intended to address the root cause. Then, the cited location (and nearby text) could be modified to align. But, CID 91 died of loneliness.	Assigned
Mark Hamilton	2360	199	David Hunter	E	Y	1470.19	10.11.4	Confused writing makes the requirements unclear. What exactly does "shall not be set to 0 except for Beacon request with Measurement Mode set to Beacon Table Mode, Statistics request and request for triggered autonomous measurements." mean? Also: "Beacon Table Mode" does not appear to be the name of a frame, field, element, etc, so should be in lower case. Is it clear what type of frame constitutes the last type of request? Where is that specified?	Delete the comma after "frames" and replace the quoted sentence fragment with "shall not be set to 0 except when the request frame is a Beacon request in which the Measurement Mode field value is beacon table mode, or is a Statistics request frame, or is a request for triggered autonomous measurements." And specify exactly what frames make up the "request for triggered autonomous measurements". Also specify explictly somewhere (MIB?) the value of "beacon table mode".	MAC	Discuss	MAC: 2014-01-19 16:50:09Z - Is the terminology (for example), "Statistics request frame" what we want to use for a Measurement Request frame that has a Measurement Report element which has the Measurement Type field set to STA statistics report? The full description is way too wordy, and we need shorthand phrase. What is the right/best shorthand? A nit: there is also a Directional statistics report, so we cannot shorthand to just "statistics", we need to say "STA statistics" EDITOR: 2013-10-25 13:49:11Z The proposed resolution does not address 'And specify exactly what frames make up the "request for triggered autonomous measurements"', which requires technical interpretation. Transferring to MAC to continue the resolution. The resolution as of this date will be present in D2.1, and will be adjusted to track any subsequent changes in MAC.	Assigned
Mark Hamilton	2410	199	Graham Smith	T	Y	2745.02		dot11HRCCAModeImplemented only appears in Annex C.3 I can find no reference to it outside of Annex C.3. Suggest it is deleted.	Delete dot11HRCCAModeImplemented at P2745L2, P2753L57, P2754L8-27, P2819L37	GEN	Needs submission	GEN: assigned to Mark HAMILTON - Dec 20, 2013	Assigned
Mark Hamilton	2434	199	Mark Hamilton	T	Y	116.01	5.2.1	Figure 5-1 is confusing. It looks a lot like 802.1Q's bridge diagram, but this is not at all the same thing. It also has several unlabeled blocks which are confusing. And, it implies that 802.1X port control is above LLC which is incorrect.	Replace Figure 5-1 with that contained in a submission from the ARC SC.	GEN	Needs submission		Assigned
Mark Hamilton	2454	199	Mark Hamilton	T	Y	1093.19	9.2.2	Figure 9-1 still has FH, IR, etc.	Delete "FHSS, IR" from this figure	MAC	Review	MAC: 2014-03-18 09:00:02Z: Changes already made by the Editor.	Assigned
Mark Hamilton	2455	199	Mark Hamilton	T	Y	1093.02	9.2.2	Figure 9-1 line to DCF is confusing	Draw the figure so that label connectors don't have to pass "behind" boxes (making it look like they are connecting to that box). Push the label off to one side so that it's connector can be drawn without disappearing behind boxes. (If it has to disappear behind other labels, that's not ideal, but better.) Do this for the DCF label and the SP Access label.	MAC	Review	MAC: 2014-03-18 07:59:37Z: Revised. Redraw with the two referenced labels moved to the side and down, as shown in 14-0422r0.	Assigned
Mark Hamilton	2458	199	Mark Hamilton	T	Y	1160.6	9.20.2.3	EDCAF operation needs help to improve understanding - it has not evolved well. For example, 9.19.2.3 has become a convoluted machine built from 4 separate bullet lists. 9.19.2.3 and 9.19.2.5 both discuss backoff counter decrements, and when they occur. 9.2 shows EDCA as "on top of" DCF, but EDCA TXOPs violate 9.3.4.3 (6th paragraph). Etc.	This needs off-line work, and a thought-out proposal.	MAC	Needs submission		Assigned
Mark Hamilton	2459	199	Mark Hamilton	T	Y	217.32	6.3.26.6.2	Get rid of all TIMEOUT and UNSPECIFIED_FAILURE ReasonCode values, unless there is discussion of them explicit in the protocol/behavior (and then give them a descriptive name)	Get rid of all TIMEOUT and UNSPECIFIED_FAILURE ReasonCode values, unless there is discussion of them explicit in the protocol/behavior (and then give them a descriptive name)	GEN	Needs submission		Assigned
Mark Hamilton	2460	199	Mark Hamilton	T	Y	588.01	8.4.1.9	All StatusCodes and ResultCodes should have a name	It's just easier to talk about these, if they have a name.	MAC	Needs submission		Assigned
Mark Hamilton	2462	199	Mark Hamilton	T	Y	1417.42	10.3.5.4	Reassociation to the same AP behaviour is not clearly defined (e.g. effect on TSes, whether failure leaves you unassociated, whether you need to re-do 4WH, meaning of PM bit in Reassociation Request, etc.)	Clarify that reassociation to the same AP transitions the non-AP STA to not be in power save mode. No other behaviors are affected.	MAC	Needs submission	MAC: 2013-11-13 22:37:13Z: Yes, you shall do the 4WH again (or FT) - well, you will lose your PTK. Did the group that shall not be named agree with the above? Check on TSes, too. And, testing of the above. It might be wishful thinking to think anything will be retained. (Could put in text warning of this.)	Assigned
Mark Hamilton	2464	199	Mark Hamilton	T	Y	510.51	8.2.4.1.7	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 senseIt'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	MAC	Needs submission		Assigned
Mark Rison	2425	199	Jon Rosdahl	G	Y	2233.01		CID 269: Scrub PICS: was was assigned to Mark RISON -- who created 11-12/1345r0, the submission was overreaching, and corrected more than was requested/thought by the comments.	Document 11-12/1345r0 contains many changes to the PICS that would be a positive change. A new Document will be prepared to identify those changes and submitted to the REVmc Task Group	GEN	Needs submission		Assigned
Matthew Fischer	2471	199	Matthew Fischer	T	Y	1155.55	9.19	Several elements and frames use the operating class. Additions were made to the operating class for 11n and 11ac. These additions were for wider BW modes - older STA do not understand those operating classes, but the STA operating in the new operating classes generally include backwards compatible operating modes.e.g. 11ac includes 80 mhz BW operation and there is an operating class to support thislegacy 11a STA do not understand the new operating class, but they can probably still associate as 20 mhz only STA, and therefore, would benefit by knowing that the 20 mhz operating class is supported by the target BSS/APTherefore, whenever operating class is transmitted, it should be transmitted with the highest possible mutual understood operating class between the sender and the receiver, limited by the highest supported operating class of the third party being described		MAC	Needs submission		Assigned
Matthew Fischer	2473	199	Matthew Fischer	T	Y	629.62	8.4.2.3	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.	As suggested.	MAC	Needs submission		Assigned
Matthew Fischer	2479	199	Matthew Fischer	T	Y	539.08	8.3.1.9.1	The highest indicated modulation and stream combinations for some PHYs result in phy rates that will reduce throughput efficiency to exceedingly low levels if the maximum block ack window size is not allowed to increase beyond the existing 64.	Increase the maximum allowed MPDUs in the Block Ack frame to 256 by creating a new form of Block Ack that supports a longer BA window and a longer BA bitmap	MAC	Needs submission		Assigned
Matthew Fischer	2481	199	Matthew Fischer	T	Y	1142.14	9.7.6.5	ACK (and other control response frames) are supposed to be sent at rates as specified in this subclause. Generally speaking, this subclause prescribes ACK transmission at a Basic Rate, which is, for eliciting frames that are transmitted at higher rate or MCS values, typically a rate that is lower than the rate or MCS of the eliciting frame by at least two increments. When the eliciting frame is at one of the lower rates/MCS, then the ACK will often be at the same rate/MCS. Normally, this is ok - reliability of the ACK transmission is good or better than the eliciting frame because the eliciting frame usually has significantly more bits than the ACK. But if the eliciting STA has a higher TX power, then the rate for the ACK can be too high and is very likely to fail. It would be nice if the eliciting STA can signal to the responder that a lower rate/MCS will be needed. This ensures a receiveable ACK and it allows the eliciting STA to correctly compute the ACK duration for DUR field use.	Allow a control response frame to be sent at a rate/MCS lower than otherwise allowed when there is a power difference or for other reasons. Create a mechanism that allows the eliciting STA to indicate the preferred response rate/MCS. E.g. signal in the eliciting frame, a value of step down in rate/MCS from the normally computed value for the response frame.	MAC	Needs submission		Assigned

Best Regards,

Adrian P STEPHENS

Tel: +44 (1793) 404825 (office)
Tel: +44 (7920) 084 900 (mobile, UK)

Tel: +1 (408) 2397485 (mobile, USA)

----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

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.

[STDS-802-11-TGM] https://mentor.ieee.org/802.11/dcn/13/11-13-0233-29-000m-revmc-wg-ballot-comments.xls uploaded and current status