Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
--- This message came from the IEEE 802.11 Working Group Reflector ---
FWIW...negative requirements are often a problem. Usually not verifiable (one can not show something never happens) and often cause confusion and/or heartache (sometimes not immediately). Absence may make the heart grow fonder but is usually harder to verify
in all cases. And according to the IEEE-SA style manual, "may not" is invalid. "may" is equivalent to "may or may not". "shall not" should be a red flag to poor specification, and "may not" is simply wrong.
Just a general observation....
Ben
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Tuesday, August 30, 2022 9:24 AM To: STDS-802-11@xxxxxxxxxxxxxxxxx <STDS-802-11@xxxxxxxxxxxxxxxxx> Subject: Re: [STDS-802-11] Channel Switch Count question/suggested change in REVme --- This message came from the IEEE 802.11 Working Group Reflector ---
> I am concerned that removing the “… it shall not include a Max Channel Switch Time element in a Beacon or Probe Response frame” is adding a new requirement that an AP that sends a Channel Switch Announcement with the Channel Switch Announcement element set to 0 shall include a Max Channel Switch Time element.
I don't buy this at all. Not saying "it shall not include X" does not imply "it shall include X". Otherwise every element would have to have hundreds of "it shall not include X"s specified.
> Alternative proposal: change the clause to: “… it
may
I would not want a "may not". I suppose I could live with a "it may include a MCSTe".
> Rejected: There is no known benefit of including the Max Channel Switch Time element in a Beacon or Probe Response frame with a Channel Switch Count field of the Channel Switch Announcement element set to 0.
I think there are at least two benefits to the MCSTe: 1) for the STA to be able to lengthen any "AP has gone away, time to roam" timeout 2) for the STA to be able to decide that waiting for the AP to turn up would spoil its latency/throughput expectations, and to immediately roam to another AP instead
Both of these would be applicable in the zero count case.
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: Joseph Levy <000019588066c6b7-dmarc-request@xxxxxxxxxxxxxxxxx>
--- This message came from the IEEE 802.11 Working Group Reflector --- Dear All,
I am concerned that removing the “… it shall not include a Max Channel Switch Time element in a Beacon or Probe Response frame” is adding a new requirement that an AP that sends a Channel Switch Announcement with the Channel Switch Announcement element set to 0 shall include a Max Channel Switch Time element. While this may have some benefit to the non-AP STAs, informing it of the maximum time the AP will take to complete the channel switch, this does put a “new” requirement on the AP to provide this information. I don’t know if this something an AP can do with minimum impact. Also, this is a change in AP behavior and existing APs will not follow this new behavior as the current requirement clearly states that the element is not included. Therefore it is probably best to not require this a new behavior. If the benefit of adding this additional information to the Channel Switch Announcement is viewed as beneficial it may be preferred to simply allow the Max Channel Switch Time element to be included, at the discretion of the AP, by replacing the “shall” with a “may”.
Alternative proposal: change the clause to: “… it
may
This alternative proposal allows the current behavior of the AP of not including the Max Channel Switch Time element and the proposed new behavior of including the Max Channel Switch Time element to both be allowed.
Also it should be noted that there are benefits of having all APs behave in the same manner and existing APs currently follow the requirement not to include a Max Channel Switch Time element. If it is viewed that the inclusion of the element is beneficial to non-AP STAs then this new behavior should be allowed, however if there is no benefit for this new behavior then the comment should be rejected. Rejected: There is no known benefit of including the Max Channel Switch Time element in a Beacon or Probe Response frame with a Channel Switch Count field of the Channel Switch Announcement element set to 0.
Regards, Joseph
From: Lumbatis, Kurt <kurt.lumbatis@xxxxxxxxxxxxx>
--- This message came from the IEEE 802.11 Working Group Reflector --- I am fine with those changes.
Kurt Lumbatis Distinguished Software Engineer DOCSIS CPE R&D SW Architecture (Wi-Fi)
ARRIS AND RUCKUS HAVE JOINED COMMSCOPE
3871 Lakefield Dr, Suwanee, GA 30024 USA Office: +01-678-473-2921
From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
--- This message came from the IEEE 802.11 Working Group Reflector --- All,
I’m looking for those interested in Channel Switch Announcement procedures, to consider a change being proposed in REVme (see below).
Does anyone have a comment/concern with this proposed change?
Thanks. Mark
To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 |