| 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 ---
Thanks for this. I have the following comments: - CID 1391. The new 10.25.3 says nothing about the promised Ack frames ("Once the block ack exchange has been set up, Data and Ack frames are transferred using the procedure described in 10.25.3(#57).") - CID 1347. The point has been missed. The proposed change aligns DCF with EDCA (and presumably with what DCF implementations already do) - CID 1356. "data or management frames" should be "Data or Management frames" - CID 1356. Why is "If dot11RTSThreshold is 0, an RTS/CTS exchange shall precede all frame exchanges including
an individually addressed data or management frame" needed? This is covered by the previous para's "A STA using the DCF shall use an RTS/CTS preceding a frame
exchange including an individually addressed data or management frame when the length of the PSDU is greater than the length threshold indicated by dot11RTSThreshold." (except for the "using the DCF",
which should either be deleted or replaced with "using the DCF or EDCA") - CID 1356. "A STA may also use an RTS/CTS exchange for individually addressed
frames when it is necessary to distribute the NAV or when it is necessary to establish protection (see 10.27 (Protection mechanisms)).
A STA may also use an RTS/CTS exchange for other purposes.
" would be nicer as "A STA may also use an RTS/CTS exchange for individually addressed frames when it is necessary to
distribute the NAV, or when it is necessary to establish protection (see 10.27 (Protection mechanisms)), or for other purposes." - CID 1358. Is the NOTE still appropriate under the new reduced para, or should it be moved to 10.3.5 or deleted? - CID 1398. I don't think reference should be made to "or the STA Channel Width field in the HT Operation element". NCW is at its core about non-AP STAs changing their operating width. An AP always has the option of fiddling with the HT Operation, but that's a different thing, and is an option whether or not the peers support OMN - CID 1469, 1477. I'd like these pulled for now for more time to consider - CID 1382. For dot11BSSTransitionActivated to be true, logically, dot11BSSTransitionImplemented must also be true, yes, but the spec should not (and does not) rely on such inferences (e.g. in 11.25.2 "If dot11SCSActivated is true, dot11SCSImplemented shall be true.") Thanks, Mark --
Mark RISON, Standards Architect, WLAN English/Esperanto/Français Samsung Cambridge Solution Centre Tel: +44 1223 434600 Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601 ROYAUME UNI WWW:
http://www.samsung.com/uk From: ***** 802.11 REVm - Revision Maintainance List ***** [mailto:STDS-802-11-TGM@xxxxxxxx]
On Behalf Of Mark Hamilton --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
All, I have uploaded an updated REVmd MAC ad hoc comment spreadsheet, here:
https://mentor.ieee.org/802.11/dcn/17/11-17-0927-16-000m-revmd-mac-comments.xls
This includes resolutions that will be considered for MOTION at the Warsaw meeting, for CIDs: 1391, 1299, 1308, 1313, 1347, 1356, 1358, 1381, 1147, 1390, 1554, 1392, 1398, 1425, 1504, 1469, 1528, 1477, and 1382, as discussed
on recent teleconferences or at the Fort Lauderdate ad hoc session. I am still looking for volunteers to look at comments on MAC-level material that is PHY-specific, for DMG and S1G support. If anyone is willing to contribute in these areas, please let me know. Thanks. Mark To unsubscribe from the STDS-802-11-TGM list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1 To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1 |