Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBK] ] comment resolution for first batch (207) of LB279 editorial CIDs

Thanks for this, Roy.  My responses (penultimate column) to some of the proposed resolutions:

 

CID

Clause

Page

Comment

Proposed Change

mgr response

Resolution

1183

 

0.00

"make corresponding changes throughput the 11az text where the Secure 13 LTF Parameters element, or the Secure LTF Counter field in the element is referred to:" -- per extensive REVme discussions global search and replace instructions are not acceptable and an explicit list of locations is required (in fact here it's even worse as would require the Editors to identify "the 11az text" in 802.11-2024)

Identify all the changes explicitly

As I say in my comment, it is the position of the TGme Editors that "globally change X to Y" is not an acceptable resolution (let alone "make corresponding changes")

REVISE
TGbk Editor: change the instructions as shown here referencing REVme as the new baseline.
"Change “HE-LTF” to “LTF” in Figure 9-788eu (Secure HE-LTF Parameters element format) as shown and make corresponding changes throughoutput the REVme text where the Secure LTF Parameters element, or the Secure LTF Counter field in the element is referred to: (#202305-05)"

1195

 

0.00

It was agreed in REVme that the distinction between fields and subfields is spurious and should not be continued

Delete all "sub"s in "subfield"

I believe the style guide now deprecates all use of "subfield"

REJECT
The commentor failed to identify specific new uses of subfield that are inconsistent with the style guide.

1237

 

0.00

There are zillions of instances of "LMR" and I suspect most are missing "frame"

As it says in the comment

See above re global changes, especially ones that cannot be automated

REVISE
TGbk editor: change all instances of "LMR" that refer to the transmission of a frame to "LMR frame". Remaining instances of "LMR" are unchanged, when simply referring to the use of the report within the frame.

1248

 

0.00

"BW" should be "bandwidth" (or "Bandwidth" at the start of sentences/cells etc.

As it says in the comment

28.14: 320 MHz BW option
80.2: 35.14 PPDU format, BW, MCS, NSS, and DCM selection rules
Also 72.5 "the BW subfield " should be "the UL BW [sub]field"?

REJECT
No page numbers, sections or specific instances are specified.

1255

 

0.00

The "; see 12.3.4.5" stuff is confusing when there's more stuff in the sentence

Change them all to "(see 12.3.4.5)"

E.g. 39.31 "If the Range Reporting is 32 performed in the context of a Secure FTM Session, see 11.21.6.3 (FTM procedure negotiation), 33 the corresponding LMR and FTM; see 11.21.6.5.1 (Availability Window parameter 34 modification); frames shall be transmitted using Protected Fine Timing Action frames, and see 35 9.6.34 (Protected Fine Timing Frame details). ".  I thought you were happy to do global searches?  I find 54 "; see"s

REJECT
No page numbers, sections or specific instances are specified.

1338

 

0.00

Do we really use "Tx" rather than "transmit" in the baseline?

Check with the WG Editors

Yes, but are those 40 in error?  If so we should not add to it

REJECT
Yes, REVme has 40 instances of Tx antenna.

1294

 

77.04

"See Subclause 9.6.7.52" -- about what?

Clarify

Say just see 9.6.7.52 not see Subclause 9.6.7.52

REVISE
TGbk editor: change the bullet containing the quoted text to be: "ISTA Passive TB Ranging Measurement Reports: see Subclause 9.6.7.52 (Secondary RSTA Broadcast Passive TB Ranging Measurement Report frame format). "

1240

11.21.6.3.3

26.37

"RSTA Assigned Max Bandwidth" needs to be "RSTA assigned max bandwidth" throughout and italicised at this location.  Ditto for "RSTA Assigned R2I STS" (-> "assigned") and the I2R one too

As it says in the comment

Don't uppercase "max"

REVISE
TGbk editor: there are 3 instance of RSTA Assigned Max Bandwitdth, change to RSTA assigned Max bandwitdth
There are 3 instances of RSTA Assigned R2I STS, change to RSTA assigned R2I STS. There are 2 instances of RSTA Assigned I2R STS, change to RSTA assigned I2R STS.

1264

11.21.6.4.3.3

0.00

"Trigger frame Ranging Sounding" should be "Ranging Sounding Trigger frame" (3x)

As it says in the comment

Will all the Ranging Sounding Trigger frames become TF Ranging Sounding frames then?

REVISE
TGbk editor: change all instances of "Trigger frame Ranging Sounding" to "TF Ranging Sounding frame", to match the baseline.

1289

11.21.6.4.8.3

72.03

"An RSTA transmitting a Ranging NDP Announcement frame and an HE/EHT Ranging NDP 4 after receiving an HE/EHT Ranging NDP as a response to a Passive Sounding Ranging Trigger 5 frame shall set the TXVECTOR parameter CH_BANDWIDTH to be the same value as the BW 6 subfield of the Common Info field in the Passive Sounding Ranging Trigger frame whose 7 bandwidth is less than or equal to 160 MHz. If the bandwidth of the Passive Sounding Ranging 8 Trigger frame is equal to 320 MHz, the RSTA shall set the TXVECTOR parameter 9 CH_BANDWIDTH to CBW320. " is odd

Change to "An RSTA transmitting a Ranging NDP Announcement frame and an HE/EHT Ranging NDP after receiving an HE/EHT Ranging NDP as a response to a Passive Sounding Ranging Trigger frame shall, if the bandwidth of this frame is 320 MHz, set the TXVECTOR parameter CH_BANDWIDTH to be the same value as the BW subfield of the Common Info field. If the bandwidth of the Passive Sounding Ranging Trigger frame is 320 MHz, the RSTA shall set the TXVECTOR parameter CH_BANDWIDTH to CBW320. " and similarly for subsequent paras

OK, in my proposed change I think the first "is 320 MHz" should have been "is less than or equal to 160 MHz" but otherwise what's wrong with it?  The proposed resolution has broken/confusing "whose"

REVISE
TGbk Editor: The proposal by the commenter is technically wrong because it does not facilitate the 160MHz or lower transmission. For improved clarify, replace the quoted text with:

"An RSTA receiving an HE/EHT Ranging NDP solicited by a Passive Sounding Ranging Trigger frame, shall set the TXVECTOR parameter CH_BANDWIDTH to be the same value as the BW subfield of the Common Info field in the Passive Sounding Ranging Trigger frame whose bandwidth is less than or equal to 160 MHz, to initiate a transmission of a Ranging NDP Announcement frame and an HE/EHT Ranging NDP. In the case the bandwidth of the soliciting Passive Sounding Ranging Trigger frame is equal to 320 MHz, the RSTA shall set the TXVECTOR parameter CH_BANDWIDTH to CBW320."

1310

36.2.2

0.00

RANGING_FLAG is odd.  Why is it a present/not present thing rather than a Boolean

Clarify

I don't understand.  In Table 36-1 the RANGING_FLAG is only present for EHT (so 11ax is a red herring) but the definition of the actual value is missing.  Maybe this should become a technical

REJECT
The use of "present", or "not present" is required because the TXVECTOR is a shared interface with previous amendments (11ax, 11be) which may not implement 11bk. TXVECTOR is used for transmission of frames and formats that may not relate to ranging, and for backwards compatibility the "present", "not present" methodology is used.

1311

36.2.2

0.00

Shouldn't "Tx window" be lowercase?

Check with the WG Editors

See above re Tx

REJECT
The REVme baseline has many of instances of "Tx window".

1313

36.2.3a

84.01

"Indicate the" should be just "The" (2x)

As it says in the comment

What, so the cell will start "indicates", lowercase?  This seems wrong

REVISE
TGbk editor: change "Indicate" to "indicates" to match other uses in the text.

1320

36.3.4.1

0.00

"EHT-LTF User Blocks" should probably have the last two words lowercase; ditto the Repetition Blocks

As it says in the comment

If it's a field name then it should be "EHT-LTF User Block field[s]" not just "EHT-LTF User Block[s]"

REJECT
According to 802.11 style guide, first letter capitalization is required for all the words in a field name. "EHT-LTF User Blocks" is a field name.

1214

9.3.1.22a.2

20.28

"Number Of LTF Symbols And 29 Midamble Periodicity subfield" -- I see no evidence that this feel has been renamed to delete the "HE-" (see e.g. page 34)

As it says in the comment

Huh?  11bk/D1.0 is showing many deletions of "HE-" (first two at 20.28)!  34.29 says the baseline has "HE-": "the number of HE-LTF symbols, indicated in the Number Of HE-LTF Symbols And Midamble Periodicity subfield"

REJECT
The Number Of LTF Symbols And Midamble Periodicity field has not been renamed/edited by 11bk nor by REVme, the comment is somewhat cryptic. Suggest to commenter to review and reassess resubmitting the comment in a future revision.

 

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: Roy Want <000009accb4611e8-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Friday, 2 February 2024 02:29
To: STDS-802-11-TGBK@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBK] ] comment resolution for first batch (207) of LB279 editorial CIDs

 

Dear Jonathan,

 

Please add the following document covering resolutions for 207 editorial CIDs (LB279)

with the view to motion this batch after the usual 10 days posting period. 

 

This covers 207 out of the 226 Editorials. The remaining editorials are related to alignment with the REVme and 11be baseline, and I'll submit the resolution to these in a second batch.

 

Thanks,

 

--Roy

__________________________

Google Android
Location & Context Team

MTV-PLYM1625-6C3A,  Cell: 650 691 3600

 

 

To unsubscribe from the STDS-802-11-TGBK list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBK&A=1

To unsubscribe from the STDS-802-11-TGBK list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBK&A=1