OK, I'm really not understanding the value, but in the interests
of making progress I've added the requested NOTEs:
998.17: Each Delta SNR subfield is a 2s complement signed integer that
contains the [delta SNR] as a signed integer in dB (in the range -8 to 7 dB)
NOTE—This encoding covers the delta SNR range from –8 dB to 7 dB.
1762.12: The AOA Azimuth subfield contains the AOA azimuth result in 360º/2048 resolution. This subfield is an unsigned 2s complement number taking values between 0 and 2047.
NOTE—This encoding covers the azimuth range from 0 (0º) to 2047 (nearly 360º).
1762.19: The AOA Elevation subfield contains the AOA elevation result in 180º/1024 resolution, as a signed integer. This subfield is a signed 2s complement number taking values between –512 and 511.
NOTE—This encoding covers the elevation range from –512 (–90º) to 511 (nearly 90º).
1763.50: The AOD Azimuth subfield contains the angle of departure (AOD) azimuth result in 360º/2048 resolution. This subfield is an unsigned 2s complement number taking values between 0 and 2047.
NOTE—This encoding covers the azimuth range from 0 (0º) to 2047 (nearly 360º).
1763.59: The AOD Elevation subfield contains the signed AOD elevation result in 180º/1024 resolution, as a signed integer. This subfield is a signed 2s complement number taking values between –512 and 511.
NOTE—This encoding covers the elevation range from –512 (–90º) to 511 (nearly 90º).
1855.60: The Beam Azimuth field is specified in units of (360 / 4096)° and takes values from 0 to 4095.
NOTE—This encoding covers the azimuth range from 0 (0º) to 4095 (nearly 360º).
The Beam Elevation field is encoded as a 2s complement number taking values from –2048 to 2047 a signed integer in units of (180 / 4096)°.
NOTE—This encoding covers the elevation range from –2048 (–90º) to 2047 (nearly 90º).
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: Youhan Kim <youhank@xxxxxxxxxxxxxxxx>
Sent: Thursday, 12 November 2026 09:24
To: Mark RISON <m.rison@xxxxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: 11mf/D3.0 comment resolutions
|
Caution: External Emails May Contain Spoofed Addresses, Malicious Links, or Attachments – Verify Before Engaging.
|
Thanks, Mark.
Please see inlined as [YK].
Regards,
Youhan
From: Mark RISON <m.rison@xxxxxxxxxxx>
Sent: Thursday, November 12, 2026 9:13 AM
To: Youhan Kim <youhank@xxxxxxxxxxxxxxxx>;
STDS-802-11-TGM@xxxxxxxxxxxxxxxxx <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
Subject: RE: 11mf/D3.0 comment resolutions
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hello Youhan,
-->
998.17: Each Delta SNR subfield is a 2s complement signed integer that contains the [delta SNR] as a signed integer in dB (in the range -8 to 7 dB)
Or coverting the "in the range -8 to 7 dB" to a NOTE is also fine.
Do you not agree with the Discussion para that:
Also, per the rules of unsigned numbers and signed 2s complement numbers, an n-bit field containing an unsigned integer can contain values in the range 0 to 2n−1 and containing a 2s complement number −2n−1
to 2n−1−1. This is basic maths that anyone who reads the 802.11 standard should be expected to grok.
? The request when I presented earlier this week was to include NOTEs for
things that involve division by 4, but here it's a plain integer.
[YK] While I am ok with the it in general, I do think there are certain cases where preserving history and avoiding inadvertent mistakes by readers. I am
more on the side of better-safe-than-sorry.
-->
1120.56: the offset value is a
2s complement integer signed integer in units of 0.5 dB
I'm not seeing any difference here.
[YK] dBm -> dB.
All the deleted text should be converted to NOTE instead.
Please convert the deleted text NOTE.
See above re basic maths.
[YK] While I am ok with the it in general, I do think there are certain cases where preserving history and avoiding inadvertent mistakes
by readers. I am more on the side of better-safe-than-sorry.
"CID 1396" should be changed to "CIDs 2616 and 2617"?
Ah, yes, thanks for catching that!
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: Youhan Kim <youhank@xxxxxxxxxxxxxxxx>
Sent: Thursday, 12 November 2026 09:02
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx; Mark RISON <m.rison@xxxxxxxxxxx>
Subject: Re: 11mf/D3.0 comment resolutions
|
Caution: External Emails May Contain Spoofed Addresses, Malicious Links, or Attachments – Verify Before Engaging. |
Hi, Mark.
Thanks for this.
Regarding CID 2616, could you please make the following updates to the text changes?
-->
998.17: Each Delta SNR subfield is a 2s complement signed integer that contains the [delta SNR] as a signed integer in dB (in the range -8 to 7 dB)
Or coverting the "in the range -8 to 7 dB" to a NOTE is also fine.
-->
1120.56: the offset value is a
2s complement integer signed integer in units of 0.5 dB
All the deleted text should be converted to NOTE instead.
Please convert the deleted text NOTE.
"CID 1396" should be changed to "CIDs 2616 and 2617"?
Thanks,
Youhan
From: Mark RISON <m.rison@xxxxxxxxxxx>
Sent: Thursday, November 12, 2026 2:07 AM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
Subject: [STDS-802-11-TGM] 11mf/D3.0 comment resolutions
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hello,
I have uploaded
https://mentor.ieee.org/802.11/dcn/26/11-26-1978-04-000m-resolutions-for-some-comments-on-11mf-d3-0-lb295.docx
,
which contains resolutions for the comments below (note the Proposed
Change below is the change proposed by the commenter, not necessarily
the change proposed to resolve the comment).
Please take a look and tell me before AM2 if you have any concerns,
since we have a lot of things to get through in TGmf today! Note that
comments whose resolution is highlighted in green are already ready
for motion and those in a table with red highlight are not being
proposed for resolution today.
|
CID |
Page |
Clause |
Comment |
Proposed Change |
|
2008 |
1758.06 |
"The P2P Ranging Availability subelement is included in the IFTMR and IFTM frames for non-TB FTM session negotiation with a non-AP RSTA." - I believe the term is "non-TB ranging", also a link would be nice. |
Replace with "The P2P Ranging Availability subelement is included in the IFTMR and IFTM frames for non-TB ranging FTM session negotiation with a non-AP RSTA, see 11.21.6.4.4.4." |
|
|
2514 |
1283.39 |
In the description of the FTE, it says "R1KH-ID indicates the identity of the R1KH", which is not clear. Is the body of the R1KD-IH subelement just an identifier? How big is it supposed to be? Similarly it's not clear what's in the R0KH-ID subelement |
Other locations indicate this is actually a MAC address. This should be specified |
|
|
2532 |
11 |
Why both 11.10.14 Multiple BSSID set and 11.1.3.8
Multiple BSSID procedure? |
Merge into one subclause by making 11.10.14 a new last subclause of
11.1.3.8 |
|
|
2539 |
2413.36 |
10.23.3.5.1 |
"A TXOP obtained by receiving a QoS (+)CF-Poll" -- the TXOP is obtained by the transmitter of the CF-Poll, not by the receiver |
Reword (not sure exactly what the sentence is trying to say) |
|
2547 |
13 |
The spec is inconsistent as to which FT messages the RSNXE is included in. Table 9-87--Presence of fields and elements in Authentication frames says it can only be present in message 1. Figure 13-5--Over-the-air FT protocol in an RSN and 13.7.1 FT reassociation
in an RSN say it can only be present in messages 3 and 4. Table 13-1--FT authentication elements says it can be in messages 1, 3 and 4 |
Agree which messages the RSNXE can be present in for FT, then make sure the spec consistently says so and does not mention the RSNXE in other messages |
|
|
2556 |
2896.33 |
"The insertion of an element means that the element was not present in the previous Beacon frame, is present in the current Beacon frame, and will be carried in the next Beacon frame. " -- the receiver has no way to know for sure whether the element will be
included in the next frame (maybe CSA, but even there there could be weird corner cases where the AP immediately advertises a CSA on the new channel). Also, should there be something about the removal of an element (e.g. no more Quiet)? |
Change to "The insertion of an element means that the element was not present in the previous Beacon frame, is present in the current Beacon frame, and (for an AP) will be carried in the next Beacon frame, or that it was present in the previous Beacon frame
and is not present in the current Beacon frame. " |
|
|
2567 |
9 |
"element is included in" is duplication and spec rot, but the following seem to be behaviour not just format/encoding: The EDMG Specific Parameters subelement is included in the IFTMR frame, as described in
9.6.7.32
(FTM Request frame format), and the IFTM frame, as described in
9.6.7.33 (FTM frame format), if the
Secure RTT Measurement subfield of the FTM Parameters field of these frames is equal to 1. The EDMG Wide Bandwidth Channel Switch element is included in DMG Beacon frames, Announce frames, or Information Response frames, as defined in
11.8.8.7
(Selecting and advertising new channels in an EDMG BSS).
If the initiator and the responder successfully negotiate an FTM session, and the negotiated ranging protocol is non-TB, then the Non-TB Specific subelement is included in both the IFTMR frame, to describe the requested set of parameters that the initiator
proposes to use, and in the IFTM frame.
If the initiator and the responder successfully negotiate an FTM session where the negotiated ranging protocol is TB, then the TB Specific subelement is included in both the IFTMR frame, to describe the requested set of parameters that the initiator proposes
to use, and in the IFTM frame.
The P2P Ranging Availability subelement is included in the IFTMR and IFTM frames for non-TB FTM session negotiation with a non-AP RSTA. |
Delete the cited sentences and move the behaviour to Clauses 10 and later |
|
|
2573 |
867.19 |
The allowed settings of A1 and A3 in probe requests is unclear: whether you can have A1 = unicast A3 = broadcast, or A1 = broadcast A3 = broadcast, and whether there are any additional subtleties with MBSSID (e.g. A1 and/or A3 has to be the txBSSID or something)
and/or 6G scanning |
As a strawman: at the referenced location add "In Probe Request frames, if the Address 3 field is the wildcard BSSID, the Address 1 field shall be the broadcast address." |
|
|
2575 |
4734.38 |
26.17.2.3.3 |
"-- Otherwise, if the channel is a PSC and the STA has determined the medium to be idle for a continuous period of at least dot11MinPSCProbeDelay from the start of the scan on the channel, then the STA may, subject to other rules in this subclause, send
a Probe Request frame to the broadcast address in that channel, with the SSID field set to the SSID that corresponds to an AP or with the Short SSID field of the Short SSID List element set to the short SSID that corresponds to an AP, and/or with the Address
3 field set to the BSSID of an AP, after invoking the backoff procedure, described in
10.23.2.2
(EDCA backoff procedure), starting from step c) of 11.1.4.3.2 (Active scanning procedure for a non-DMG STA)." seems to suggest you can have Addr1 = broadcast but Addr3 = BSSID. Is this valid, and if so what is the difference with Addr1 = Addr3 = BSSID? In
general terms the latter seems better since it allows early rx termination |
Clarify |
|
2578 |
1283.39 |
"R1KH-ID indicates the identity of the R1KH, which is used by the S0KH and the R0KH for deriving the PMK-R1s." is not clear as to the actual contents of subelement, and how the identity of the R1KH is actually encoded in the subement. Similarly for R0KH-ID. |
Change to "The Data field of the R1KH-ID subelement contains the identity of the R1KH, which ...". On page 1284 change "the R0KH-ID indicates the R0KH" to "the Data field of the R0KH-ID subelement contains the identify of the R0KH" (2x) |
|
|
2579 |
3706.33 |
13.5.2 |
Shouldn't Figure 13-5--Over-the-air FT protocol in an RSN(#11be)(#199) include RSNXEs in the Auth frames, at least in some cases, per Table 9-87--Presence of fields and elements in Authentication frames? Conversely the table does not mention RSNXEs in anything
but message 1 |
As it says in the comment |
|
2582 |
"roaming" is used about 10 times outside the context of "SP" or "consortium", but not defined |
Define the term, or change each instance to "BSS transition" |
||
|
2614 |
2325.47 |
There are references to "alternate rate"s but it's not clear how you can have two rates that give the same airtime, unless this is something implausible like switching between 80M 2SS and 40M 4SS or something |
Add a NOTE to give an example of two alternate rates |
|
|
2616 |
Canonicalise "2s complement signed integer" "2s complement integer" "2s complement number" "2s complement value" "2s complement format" "2s complement 8-bit number" |
I will provide the list of changes needed |
||
|
2617 |
"unsigned 2s complement" makes no sense! |
I will provide the list of changes needed |
||
|
2626 |
12.7 |
Stuff like "-- The Key Data descriptions specify what shall or may be included; nothing else shall be included except that one or more vendor specific KDEs and/or Vendor Specific elements may be included." in
12.7.6.1
General also applies to the GKH (12.7.7) |
Either duplicate the statements or have a subclause that applies to both 12.7.6 and 12.7.7 |
|
|
2635 |
3249.54 |
Things like "The QMFReconfigurationActivated subfield shall be set to 0 in the Extended Capabilities element when dot11QMFReconfigurationActivated is false." force the transmission of the octet containing the bit, even if it's the last octet and there are no
bits set in it |
Change to "... shall not be set to 1 ..." |
|
|
2651 |
12.7 |
12.7.4 notation is EAPOL-Key(S, M, A, I, K, Reserved, RSC, ANonce/SNonce, MIC, {Key Data}) 12.7.7.1
says
G1: EAPOL-Key(1, 1, 1, 0, G, 0, RSC, 0, MIC, ...
G2: EAPOL-Key(1, 1, 0, 0, G, 0, 0, 0, MIC ... so the Key MIC Present (second argument to EAPOL-Key()) is shown as 1, but it is 0 when an AEAD cipher is used. This is incorrect duplication of the next two subclauses. Ditto for
12.7.6.1 |
Delete lines 2 to 8 inclusive on page 3617, and from line 63.5 on page 3603 to line 14 on the next page. Note: this is a very detailed and specific statement of the changes that would satisfy the commenter |
|
|
2657 |
3.1 |
It would be useful to have something in 3.1 to say that a wrapped key is a key (or other sensitive material) that is encrypted and authenticated using a KEK. Note cf. CID 481 rejection that this concept appears in the form "wrapped <something>K" not "wrapped
key" |
Add a definition in 3.1:
wrapped key: A key (or other sensitive material) that is encrypted and authenticated using a key encapsulation key (KEK).
Notes from previous discussions: The Group did not like the generic definition of "wrapped key". Concern in the wrapped data expanding the use of "wrapped" and if it needed a better definition or usage.June 23: 12.7.3 text on wrapping could be moved to a new
clause in 12.7 about the Key Wrap Algorithms for use in the standard. The Title should include the word "Wrapped" maybe at 12.7.2 |
|
|
2755 |
273.35 |
3.2 |
"(STA_" should be "(STA)". There are other typo instances of "_" used instead of ")" in this subclause. |
As suggested. |
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
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