| 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 ---
> - For the changes under CID 269, I have a slight concern: is it always the DMG caps/op? This is FST, so it involves
multiple PHYs. Maybe sometimes you include e.g. the HT Cap/Op elements instead? I would welcome input from a DMG expert I agree with Mark. The change made under CID 269 is incorrect - that is not the intent. The sentence in question states “…that
are applicable to the band and channel number indicated within its most recently transmitted Multi-band element that was transmitted on the same band and channel number on which it is transmitting the FST Setup Request or FST Setup Response frames.”
In other words, the capabilities and operation elements that are to be included are those relative to the “other” band, i.e., the band indicated in the Multi-band element. The reason the text was written this way in terms of “… the
Capabilities element, the Operation element …” was because it would be very difficult to keep this text up to date every time we have
a new amendment defining its own capability and operation elements. At a minimum, we should create a submission to undo this change.
Thanks, Carlos. From: ***** 802.11 REVm - Revision Maintainance List ***** [mailto:STDS-802-11-TGM@xxxxxxxx]
On Behalf Of Mark Rison --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Thanks to the editors for this. I have some comments: - The change made under CID 172 to say A GDD dependent STA shall cease all transmission when dot11GDDEnablementValidityTimer has expired. looks suspect to me (the previous bullet and the figure above are equally suspect). A MIB variable does not expire. Probably needs reworking to talk about the GDD enablement validity timer, whose starting value is set by dot11GDDEnablementValidityTimer, expiring, or something like that - I think the changes from "may" to "might" under CID 229 are not right at (my emphasis to show the key words): * 1551.47: "
A second HT AP that detects a first HT AP’s Beacon frame with the OBSS Non-HT STAs Present field equal to 1
might cause HT-greenfield format and RIFS sequence
transmissions of the second AP’s BSS
to be protected by setting the HT Protection field of its HT Operation element to non-HT mixed mode." * 2136.27: "The management entity of this STA chooses a set of STAs with which it might need to authenticate and then
might cause the MAC to send an IEEE 802.11 Open System authentication message to each targeted STA." - For the changes under CID 261, is TGmd happy that e.g. a broadcast is "addressed to" devices? Also more generally some of the changes look suspect to me - For the changes under CID 269, I have a slight concern: is it always the DMG caps/op? This is FST, so it involves multiple PHYs. Maybe sometimes you include e.g. the HT Cap/Op elements instead? I would welcome input from a DMG expert 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: Dorothy Stanley [mailto:dstanley1389@xxxxxxxxx]
--- This message came from the IEEE 802.11 Working Group Reflector ---
All, Please see
http://www.ieee802.org/11/private/Draft_Standards/11md/index.html where D0.2 includes the 802.11ai roll-in and resolutions to all comment collection comments approved through the July plenary. Thanks to Emily Qi, Editor, and Edward Au, sub-editor for their work on producing this version. Emily and Edward will be incorporating the approved 802.11ah amendment between now and the September meeting. Thanks, Dorothy ---------------------- dorothy.stanley@xxxxxxx _______________________________________________________________________________
If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.
Instead, go to
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11 and then press the LEAVE button.
If there is no LEAVE button here, try
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-RO. 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 _______________________________________________________________________________ |