Hello Henry,
Thanks again for the comments. With respect to 11-24-1919, I tried to address all your comments in r3 with the exception of your question about Probe Responses. I may have misunderstood your question originally. The text currently says:
An AP sets the Protected Timestamp field to 1 to indicate that protection is enabled for the Timestamp field in Beacon frames that it transmits. Otherwise, it sets this field to 0. For non-AP STAs, this field is reserved. See 12.5.3.4.
That's fine. It originally talked about "protection is enabled for the TSF in Beacon frames"
but beacons don't have a TSF, and anyway you're not directly protecting the TSF
(which as I said in my comment is a function). Your new text captures this.
It's intended to mean "An AP sets the Protected Timestamp field to 1 to indicate that protection is enabled for (the Timestamp field in Beacon frames that it transmits)". A much simpler version would be:
An AP sets the Protected Timestamp field to 1 when dot11ProtectedTimestamp is true, and sets it to 0 otherwise. For non-AP STAs, this field is reserved. See 12.5.3.4
which is consistent with some of the other RSNXE field descriptions.
Yes, you could do that. In any case, the description of said MIB attribute
needs to be fixed because it too talks of "protection for the TSF in Beacon frames".
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
1 Cambridge Square, Cambridge CB4 0AE Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
From: Henry Ptasinski <henry@xxxxxxxxxx>
Sent: Monday, 28 April 2025 17:57
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: David Halasz <dave.halasz@xxxxxxxx>; ***** 802.11 REVm - Revision Maintainance List ***** <STDS-802-11-TGM@xxxxxxxx> (STDS-802-11-TGM@xxxxxxxx) <STDS-802-11-TGM@xxxxxxxx>
Subject: Re: 24/1915 (SAQ for low-tx devices) and 24/1919 (TSF protection)
Hi Mark,
Thanks again for the comments. With respect to 11-24-1919, I tried to address all your comments in r3 with the exception of your question about Probe Responses. I may have misunderstood your question originally. The text currently says:An AP sets the Protected Timestamp field to 1 to indicate that protection is enabled for the Timestamp field in Beacon frames that it transmits. Otherwise, it sets this field to 0. For non-AP STAs, this field is reserved. See 12.5.3.4.
It's intended to mean "An AP sets the Protected Timestamp field to 1 to indicate that protection is enabled for (the Timestamp field in Beacon frames that it transmits)". A much simpler version would be:An AP sets the Protected Timestamp field to 1 when dot11ProtectedTimestamp is true, and sets it to 0 otherwise. For non-AP STAs, this field is reserved. See 12.5.3.4
which is consistent with some of the other RSNXE field descriptions.
Thoughts?
- Henry
On Thu, Mar 20, 2025 at 6:50 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:
Thanks for these. I attach some comments.
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
1 Cambridge Square, Cambridge CB4 0AE Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
From: *** IEEE STDS-802-11 List *** <STDS-802-11@xxxxxxxxxxxxxxxxx> On Behalf Of Henry Ptasinski
Sent: Tuesday, 18 March 2025 21:38
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] TGmf teleconference announcement - 28 April
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hi Mike,
Please add 11-24/1915 and 11-24/1919 to the queue. These both have minor changes to address comments received from when I presented them in Nov.
Thanks,
- Henry
On Thu, Mar 13, 2025 at 2:13 PM M Montemurro <montemurro.michael@xxxxxxxxx> wrote:
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hello everyone,
As discussed yesterday, TGmf will be holding a teleconference at 10am ET on 28 April 2025 for 2 hours.
The agenda for the teleconference will include contributions that we were unable to review during the session this week.
Cheers,
Mike
--