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

Re: [STDS-802-11-TGBH] Editorial comment resolution for review, toward approval on Thursday

Hi Mark,

 

Thanks for your comments.  We covered your questions in the AM1 session.

For your three questions:

214 – Agree, ‘to’ is a stray word, will post 24/145r2.

205 – You are correct. No update to resolution.

9 – discussed with the group. Resolution updated in 24/40 (Overall comment tracking spreadsheet). Second sentence in the proposed resolution is deleted; first sentence now has a ‘may’ instead of ‘shall’.

       Final resolution:

Revised. The resolution does not include the second sentence as 'may' is a normative word.
Update the text as follows: Each time the non-AP STA associates with an AP in an ESS, it may provide a new IRM to the AP during association.

 

Regards,

Carol

 

From: Mark Rison <m.rison@xxxxxxxxxxx>
Date: Wednesday, January 17, 2024 at 11:10 PM
To: Carol Ansley <carol@xxxxxxxxxx>, mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>, STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-11-TGBH] Editorial comment resolution for review, toward approval on Thursday

Hello Carol,

 

Thanks for this.  My responses to your responses in red in the rightmost cell below.

 

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: Carol Ansley <carol@xxxxxxxxxx>
Sent: Wednesday, 17 January 2024 12:32
To: Mark Rison <m.rison@xxxxxxxxxxx>; mark.hamilton2152@xxxxxxxxx; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Editorial comment resolution for review, toward approval on Thursday

 

Below are my responses after going through them today.  The updates are in 24/144r5.

 

Thanks again!

 

Regards,
Carol

 

From: Mark Rison <m.rison@xxxxxxxxxxx>
Date: Wednesday, January 17, 2024 at 4:56 AM
To: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>, STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx>, Carol Ansley <carol@xxxxxxxxxx>
Subject: RE: [STDS-802-11-TGBH] Editorial comment resolution for review, toward approval on Thursday

Thanks, Carol.  I have the following comments:

 

CID

Commenter

Clause Number

Page

Line

Comment

Proposed Change

Assignee

Resolution Text

Mark RISON comment

Carol Ansley response

212

Massinissa Lalam

4.5.4.10

18

16

Added sentence could be clarified to specify which entity is providing the deviceID/IRM, something like: "Such a STA, when reconnecting to a network, can provide a device ID previously provided by the network or can use a previously  MAC address (IRM) the STA provided to the network, either of which allows the network to recognize the STA while mitigating the abilities of third parties to do tracking or traffic analysis."

As in comment

Carol Ansley

Revised.
Update the text as follows:
"Such a STA, upon reconnecting to a network, can provide a device ID previously provided by the network or can use an identifiable random MAC address(IRM) the STA previously provided to the network. Either approach allows the network to recognize the STA while mitigating the abilities of third parties to perform tracking or traffic analysis."

Need paren before "("

Actually missing space, corrected in r4

 

279

James Yee

4.5.4.10

18

16

"MAC address" should be "Identifiable Random Medium Access Address"

As suggested

Graham Smith

handled by Graham Smith.

Not a valid resolution

Removed

 

45

Lei Wang

4.5.4.10

18

17

Suggest fully spelling out IRM, i.e., identifiable random MAC address.

Suggest replacing "... previously provided MAC address (IRM)" with "... previously provided identifiable random MAC address (IRM)"

Carol Ansley

Revised.
Update the text as follows:
"Such a STA, upon reconnecting to a network, can provide a device ID previously provided by the network or can use an identifiable random MAC address (IRM) the STA previously provided to the network. Either approach allows the network to recognize the STA while mitigating the abilities of third parties to perform tracking or traffic analysis."

(This one is OK for some reason!)

Actually missing space, corrected in r4

 

68

Liuming Lu

4.5.4.10 MAC privacy enhancements

18

17

The description is confusing

Suggest to change "...can provide a previously provided device ID or can use a previously provided MAC address
(IRM),.." to "..can use a previously provided device ID or a previously provided MAC address
(IRM),"

Carol Ansley

Revised.
Update the text as follows:
"Such a STA, upon reconnecting to a network, can provide a device ID previously provided by the network or can use an identifiable random MAC address(IRM) the STA previously provided to the network. Either approach allows the network to recognize the STA while mitigating the abilities of third parties to perform tracking or traffic analysis."

Need paren before "("

Actually missing space, corrected in r4

 

87

Mark RISON

4.5.4.10

18

19

"to do" is a bit casual

Change to "to perform".  Oh, and add a space after the full stop at the end of the sentence

Carol Ansley

Revised.
Update the text as follows:
"Such a STA, upon reconnecting to a network, can provide a device ID previously provided by the network or can use an identifiable random MAC address(IRM) the STA previously provided to the network. Either approach allows the network to recognize the STA while mitigating the abilities of third parties to perform tracking or traffic analysis."

Need paren before "("

Actually missing space, corrected in r4

 

214

Massinissa Lalam

9.4.2.19.7

25

22

Replace "When IRM recommendation subelement is included in a Beacon request, it indicates the requesting STA asks the responding STA to include an IRM in RA field in the Probe Request frame." with "When included in a Beacon request, it indicates the requesting STA asks the responding STA to include an IRM in RA field in the Probe Request frame." to keep consitency with previous paragraph.

As in comment

Carol Ansley

Revised.

Not a valid resolution

Corrected: Revised. Update this clause as discussed in 24/0145r1.

 

I think the second "to" is spurious in "The Measurement ID subelement is optionally included in a Beacon request to request that the responding STA to include a Measurement ID element in the Probe Request frames it transmits" (I'm never quite sure whether it's a subjunctive or an imperative, but it's certainly not an infinitive)

33

Graham Smith

9.4.2.19.7

25

33

"The measurement ID in measurement ID element exchanged".  Think a definite article missing

Add "the" before "measurment ID as follows: "The measurement ID in the measurement ID element exchanged..."

Carol Ansley

Accepted.

Should be "Measurement ID element" (uppercase)

Agree, corrected

 

34

Graham Smith

9.4.2.19.7

25

38

"an IRM recommendation subelement shall be not present in the same Beacon request".  Reads awkward aslo a note, so should not use "shall"..  Should be "an IRM recommendation subelement is not present in the same Beacon request"

Change cited text to "an IRM recommendation subelement is not present in the same Beacon request"

Carol Ansley

Revised.
Update the text as follows:
When a Measurement ID subelement is present in a Beacon request, an IRM recommendation subelement is not present in the same Beacon request and vice versa.

Should be "IRM Recommendation subelement" (uppercase)

Agree, corrected

 

102

Mark RISON

9.4.2.311

26

22

Move the sentence to after the sentence where it's not reserved

As it says in the comment

Carol Ansley

Revised.
Move the sentence ending with "is reserved." to the end of section 9.4.2.311.

(they're subclauses, not sections)

Agree, corrected.

 

260

Peter Yee

9.6.35.1

27

54

Needs a hyphen

Change "single octet" to "single-octet".

Carol Ansley

Rejected. This comment is not compliant with the IEEE 802.11 Style Guide.

Well, it's the proposed change that isn't, actually

Agree, corrected.

 

7

Chaoming Luo

9.6.35.2

28

18

A better wording is needed.

Change to "and provided an IRM that conflicts with an IRM that the AP stored for another STA."

Graham Smith

 

Not a valid resolution

Removed

 

19

Tomoko Adachi

11.10.9.1.1

29

20

"PHYRXSTART. indication primitive" There is ann extra space between PHYRXSTART. and indication.

Correct it to read "PHYRXSTART.indication primitive".

Carol Ansley

Accepted.

Should be PHY-RXSTART.indication (hyphen)

Agree, corrected.

 

205

Jerome Henry

12.2.12

30

23

"use" is here again unclear, use for what

Suggest clarify "use as TA for its own transmissions" (maybe add and RA/DA for the frames it receives)

Carol Ansley

Accepted.

The disposition of the "maybe add" in the proposed change is not clear

Changed to revised and added text

So "(maybe add and RA/DA for the frames it receives)" has been declined?

25

Jay Yang

12.2.12.1

31

29

"Identity frame" should be " a frame containing device ID "

(see resolution on CID247)change the whole sentence to "When an AP with dot11DeviceIDActivated equal to true receives a frame containing device ID from a non-AP STA &#65292;and the received device ID is recognized, the AP shall perform one of the following actions"

Carol Ansley

Revised.
Update the text as follows:
When an AP  with dot11DeviceIDActivated equal to true receives a frame containing a device ID from a non-AP STA and the received device ID is recognized, the AP shall perform one of the following actions:

"is recognised" by whom?  Suggest "… and it recognises the device ID, it shall …"

Agree, corrected.

 

75

Henry Ptasinski

12.2.12.1

32

53

Since "device ID" is defined in clause 3 as "device identification", this sentence is saying "a device identification that can be sent over the air without exposing the underlying device identification", which is either a circular reference or requires definition of "underlying device identification" as something different from "device identification".

Define "network-assigned device identifier (NADI)" and use that instead of "device ID", and clarify what is meant by "underlying".

Carol Ansley

Revised.
Update the text as follows:
For purposes of creating a device ID that can be sent over the air without exposing the underlying device
identity, …

Should be "For the purpose of" per CID 141

Agree, corrected.

 

9

Chaoming Luo

12.2.12.2

33

23

Normative word should be used.

Change the first two sentences to: Each time the non-AP STA associates with an AP in an ESS, it shall provide a new IRM to the AP during the RSN association to be shared with all the APs in the ESS. The non-AP STA shall then use that IRM as its TA the next time it requests association to any AP in that same ESS.

Carol Ansley

Revised. The resolution does not include the second sentence as 'may' is a normative word.
Update the text as follows:
Each time the non-AP STA associates with an AP in an ESS, it shall provide a new IRM to the AP during the RSN association to be shared with all the APs in the ESS.

I find "the to be shared" confusing.  Maybe new sentence "This IRM is shared with all the APs in the ESS."?  Also is "the RSN association" necessary; why not just "during association"?

Updated text in resolution

Each time the non-AP STA associates with an AP in an ESS, it shall provide a new IRM to the AP during association. That IRM may be shared with all the APs in the ESS.

 

"may" so not required to share it with all the APs?

157

Mark RISON

12.2.12.2

33

53

"then the AP shall include an IRM KDE in message 3 of the 4-way handshake or, if using FILS authentication, the AP shall include an IRM element in the Association Response frame or if using PASN authentication, the AP shall include an IRM element in the second PASN frame. " -- too many ors and not enough commas

As it says in the comment

Carol Ansley

Revised.
Update the text as follows:
If a non-AP STA indicates support for the IRM mechanism in an Association Request frame and the AP indicates support for the IRM mechanism in the corresponding Association Response frame, then the AP shall support the following options:
- the AP shall include an IRM KDE in message 3 of the 4-way handshake
- the AP shall include an IRM element in the Association Response frame if using FILS authentication
- the AP shall include an IRM element in the second PASN frame if using PASN authentication.

First bullet needs an "if" too (at least original text suggested you did exactly one of the three)

Updated text to clarify:

then the AP shall support the following options:

- the AP shall include an IRM KDE in message 3 of the 4-way handshake if executing a 4-way handshake

- the AP shall include an IRM element in the Association Response frame if using FILS authentication

- the AP shall include an IRM element in the second PASN frame if using PASN authentication.

158

Mark RISON

12.2.12.2

33

59

"he IRM Status field of the IRM KDE or IRM element is set to 0 to indicate that the AP recognizes the IRM" should be "he IRM Status field of the IRM KDE or IRM element is set to indicate Recognized".  Similarly next sentence

As it says in the comment

Carol Ansley

Revised.
Update the text as follows:
…, the IRM Status field of the IRM KDE or IRM element is set to 0 to indicate Recognized and the IRM field is not present.
…, the IRM Status field of the IRM KDE or IRM element is
set to 1 to indicate Not Recognized and the IRM field is not present.

No, "set to 0 to indicate Recognized" is duplication of Clause 9 -- just "set to indicate Recognized" is be

tter

Agree, changed.

 

78

Henry Ptasinski

12.2.12.2

34

20

"ought" does not appear in the IEEE SA Standards Style Manual

Change "ought to be used" to "should only be used". Change "ought to change" to "should change"

Carol Ansley

Accepted.

Is this a NOTE?  If so should cannot be used so we use ought to instead

Agree, changed to Reject.

160

Mark RISON

12.2.12.2

34

24

"ANQP response frame" -- shouldn't that be "ANQP Response frame" or "ANQP response"?

Ask Stephen McCANN

Carol Ansley

Revised.
Update the text as follows:
The Neighbor Report ANQP-element in an ANQP response provides zero or more distinct neighbor
reports about neighboring APs if the IRM carried in an ANQP neighbor report query frame is detected

"ANQP neighbor report query frame" certainly wrong case.  Check with Stephen McCANN re "ANQP response".  Also shouldn't it be "Neighbor reports"?

Spoke with Stephan, et al.  Group recommended to delete.

 

172

Mark RISON

12.7.6.1

36

TGme has reformulated this to put an end to the combinatorial explosion

Align with 11me

Carol Ansley

Reject. This text is modeled on REVme D4.1. Commentor did not provide any update.

See 21/0772

The new style isn’t in our baseline yet.  Once the baseline is updated, then this draft will follow it.

173

Mark RISON

12.7.6.3

37

4

I thinik TGme has reformulated this for clarity

Align with 11me

Carol Ansley

Reject. This text is modeled on REVme D4.1. Commentor did not provide any update.

See 21/0772

The new style isn’t in our baseline yet.  Once the baseline is updated, then this draft will follow it.

21

Tomoko Adachi

C.3

41

53

"This attribute, when true at a non-AP STA, indicates that the STA might send an IRM." It seems better to say as "This attribute, when true at a non-AP STA, indicates that the STA implementation is capable of transmitting an IRM."

As in comment.

Carol Ansley

Accepted.

Why is this one "at a non-AP STA" but CID 20 not so restricted?

Because the IRM element is only sent by a STA while the Device ID element (in the other CID) can be sent by an AP or a STA.

 

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: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Tuesday, 16 January 2024 23:38
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBH] Editorial comment resolution for review, toward approval on Thursday

 

All interested in 802.11bh:

 

Please review the proposed resolutions to Editorial comments on LB282, as captured in doc: https://mentor.ieee.org/802.11/dcn/24/11-24-0144-02-00bh-editorial-comment-resolution-spreadsheet.xlsx.  If you have any concerns, please discuss with Carol Ansley, or send an email to this reflector.

 

My intention is to finalize any discussion on these CIDs during the Thursday AM1 meeting, in preparation for a motion to finalize the resolutions during the Thursday PM1 meeting.

 

Thanks for your help and attention.

 

Mark

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

 

 

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