Re: [STDS-802-11-TGBH] Personal comments on Editorial CIDs

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

Hello,

My thoughts in red 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: Friday, 14 June 2024 21:39
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] Personal comments on Editorial CIDs

I went through and added my comments in blue below. Will we go through these in the ad hoc session at some point?

Regards,

Carol

		Page	Subclause	Line	Comment	Proposed Change	Editor’s Proposed Resolution Text	Mark H comments
	Name
3014	Smith, Graham	35	12.2.12.1	60	The paragraph at P35.58 is on PASN. It would be better to move this to Page 36 just preceeding line 20 where the PASN explanation is given.	Move paragraph to just before P36.20.	Revised. Editor to switch the order of the 3rd and 4th paragraphs in section 12.2.12.1 to group the AP-related paragraphs on PASN together.	(Paragraphs are intended to be 13 and 14, I think?)

								Agreed, but I think more should be done. I note that many paragraphs are agnostic as to which scenario/mechanism applies. Then the one at P36.50 really should be for non-PASN only, because it conflicts with the one at P36.60. So, those two should be in parallel together somewhere, that lists out all the scenario-specific points (are there any others that should go with them?) (See CID 3042 on L50 not being clear, and resolution in 11-24/0885, though, also.) Then, we have a big example of PASN, but no examples of the others (see CID 3131 suggesting to add more). And, the last paragraph is probably too important to be lost at the end like it is. Agree that the section is a hodge-podge, but to entirely restructure it really calls for a technical submission,
3033	Stacey, Robert	37	12.2.12.2	50	"Identifiable random MAC address (IRM) operation" in the title but "IRM mechanism" elsewhere.	Change title to "Identifiable random MAC address (IRM) mechanism". At 48.28, change "IRM operation" to "IRM mechanism"	Revised. Editor to remove mechanism and operation from section titles and PICs table for better aligment with baseline text.	Editor says to remove both "mechanism" and "operation" for better alignment with baseline. Is that correct? I can live with it. But, Graham (11-24/0916) changed it to "operation". Which way is it? When I looked at sections preceding these new sections, they didn't use mechanism or operation in the sections titles, so I proposed to just remove them.
3053	Patwardhan, Gaurav	39	12.2.13	46	Typo. It should be ‘… shall be used as derived a part of.. “	as in comment	Revised. Editor to change phrase to "shall be used as derived from the PTK"	How about "The KEK, as derived from the PTK, shall be used with the negotiated key wrap algorithm." The sentence is a little longer. How about: The KEK as derived from the PTK, shall be used with the negotiated key wrap algorithm to encrypt the Encrypted Data field of the PASN Encrypted Data. Those last 2 words need to be lowercase or have "field" or something after
3060	McCann, Stephen	34	12.2.12	24	TA (Transmission Address) requires an article.	Change "TA" to "a TA" at the cited location. Change "TA" to "the TA" at P34L25.	Accept.	Suggest “its TA” would be better than “a TA” (first location). Full text: The second mechanism, referred to as the IRM mechanism, has the non-AP STA provide a random MAC address (different from the address it is currently using as its TA for its own transmissions) to the AP during association or PASN authentication and then use that MAC address as the TA for its own transmissions for identification of the STA, during its next preassociation exchanges, PASN authentication, and/or association and associated exchanges with that AP. Maybe "its TA for its own transmissions" is a bit heavy. "the TA for its transmissions"?
3061	McCann, Stephen	34	12.2.12	36	device ID requires an article.	Change "Device ID" to "The device ID" at the cited location.	Accept.	Suggest to change "IRM allows", also. And, change both to "The <xxx> feature allows…" There are 4 more CIDs for this NOTE: 3087, 3062, 3094, 3126 Can the same person resolve them together?
3062	McCann, Stephen	34	12.2.12	37	The sentence "If an AP and a non-AP STA both have both IRM and device ID activated..." has a couple of typos.	Change the cited sentence to "If an AP and a non-AP STA have both an IRM and a device ID activated...".	Accept.	(Note, see CID 3061 on same text.) It is not "has an IRM", but "has [the] IRM [feature] activated" (as well as the device ID feature). So, need different fix-up to the wording. There are 4 more CIDs for this NOTE: 3087, 3062, 3094, 3126 Can the same person resolve them together?
3062	McCann, Stephen	34	12.2.12	37			Accept.
3063	McCann, Stephen	36	12.2.12.2	8	The sentence "If an AP sets Device ID (sub)element or Device ID KDE with the Device ID Status field set to 1…" has a couple of typos.	Change the cited sentence to "In an AP, if the Device ID Status field in a Device ID (sub)element or Device ID KDE is equal to 1…."	Accept.	Suggest rejecting this. This is meant to correlate to the AP at the time when it is setting the Device ID Status field (in preparation for transmitting it), that it may also provide a new device ID in the same element. Phrasing this as a test (“equal to”) of the Device ID Status field (as if it were a received field) is confusing. The sentence is confusing as it stands. Not sure the best way to clean it up, but don't agree that rejecting the comment is the best path.
3064	McCann, Stephen	35	12.2.12.1	18	In the 802.11 baseline the usual phrase is "out of scope of this standard".	Change "out of scope for this standard" to "out of scope of this standard" and also on P38L20.	Accept.	Agree with the Accepted. However, it is worth noting to the REVme folks that there are 3 instances of “out of scope for” in the REVme baseline, also. 11me/D6.0 is out for ballot now!
3123	Lalam, Massinissa	29	9.4.2.319	44	Replace "The format of the PASN Encrypted Data element is shown in Figure 9-1072e (Device ID subelement format)." with "The format of the PASN Encrypted Data element when Subelement ID equals Device ID is shown in Figure 9-1072e (Device ID subelement format)."	As in comment	Accept.	I have a minor rewording to suggest: "The format of the Encrypted Data field when it contains a Device ID subelement is shown…" or some such. Suggest changing to reject - this comment's references are all wrong. Is it a holdover from a different revision? If we do accept then it needs to be a revise, since various "field"s are missing
3124	Lalam, Massinissa	29	9.4.2.319	63	Replace "The format of the IRM subelement is shown in Figure 9-1072f (IRM subelement format)." with "The format of the PASN Encrypted Data element when Subelement ID equals IRM is shown in Figure 9-1072f (IRM subelement format)."	As in comment	Accept.	Same suggestion as CID 3123, just above. Suggest changing to reject - this comment's references are all wrong. Is it a holdover from a different revision? If we do accept then it needs to be a revise, since various "field"s are missing and maybe equals needs to be indicates
3130	Lalam, Massinissa	51	AF	18	Consider renaming "(informative) Example opaque device identifier scheme" as "(informative) Example of an opaque device identifier scheme"	As in comment	Accept.	I’m okay with the direction (and hence the “accept in principle” conceptually), but we need specific wording – the Editor cannot just “Accept” this, as is. I meant to accept the wording in the comment. Alternatively: Revised: Editor to chance Annex title to: (informative) Example of an opaque device identifier scheme
3136	RISON, Mark	45	12.13.7	38	"a KEK and a KDK are derived" wrong verb	Change "and" to "and/or"	Accept.	I’d like to discuss. I thought “and/or” was not acceptable wording. I thought so too, but found 295 instances in the latest REVme draft.
3138	RISON, Mark	25	9.4.2.19.7	60	"with a Length field set to 1" should be "with the Length field set to 1"	As it says in the comment	Accept.	This is text from the baseline. Do we (as a TG) agree that we should fix this?
3139	RISON, Mark	31	11.10.9.1.1	50	" measurement request is Active" should be " Measurement request is Active"	As it says in the comment. Ditto at 32.25	Accept.	This is text from the baseline. Do we (as a TG) agree that we should fix this?
3140	RISON, Mark	31	11.10.9.1.1	62	"measurement request" should be "Measurement request"	As it says in the comment	Accept.	Suggest we reject. The lower-case use is the convention in the baseline for referencing these frames in a general sense (not to a specific type of measurement request), and the proposed change would also be inconsistent with the existing text in this paragraph. Ah, sorry, I thought a measurement request was a specific kind of request like a Beacon request, but no it's generic. OK to reject on this basis
3141	RISON, Mark	32	11.10.9.1.1	17	"measurement request" should be "Measurement request"	As it says in the comment	Accept.	Same as CID 3140 just above.
3150	RISON, Mark	18	4.5.4.10	16	"an identifiable" has two extraneous spaces	Delete two spaces (also in nearby words; also e.g. at 39.20)	Accept.	I accept the concern, but it seems to be some sort of wide space, not two spaces. So the resolution probably needs some clarification. Seems to depend on the tool being used. The "Accept" was to say that it will be corrected.
3160	RISON, Mark	28	9.4.2.314	37	"Indicates that the IRM has not been recog-nized" -- weird word-break	Don't hyphenate	Accept.	I’m not sure I agree with the comment. This is a line break issue with a long word. I suggest we just leave such issues to the professional (IEEE editing) at time of publication. It looks like bad formatting carried over when the text was copied from a submission. Fixing it is simple.
3163	RISON, Mark	30	9.4.2.316	12	"The Length field is defined in 9.4.3." missing (Subelements) which makes me worry a xref is going to be missed	As it says in the comment	Rejected. Comment is unclear as to the desired change.	I agree with this comment (at least as I think I understand it). This is asking for the usual “(Subelements)” to be added after the subclause number, to look like the usual cross-reference (which includes the subclause title). I think it’s just to help make sure this cross-reference gets noticed and turned into a hot link correctly, during integration (in REVmf). There are several other instances of naked section numbers and they are common in the amendments. Not comfortable fixing them in a scattershot manner. Maybe bring up in the Editors' meeting. We already have enough problems with stale xrefs, we don't want to queue up more candidates
3165	RISON, Mark	31			9.4.1.1.1 should be 9.4.1.11 (2x)	As it says in the comment	Accept.	Agree with the comment and Accepting it. But, to help the Editor (and others reviewing), I would explicitly mention that the locations are P34.1 and P34.19.
3170	RISON, Mark	43	12.13.2	32	"When PASN AKMP" missing article	As it says in the comment	Accept.	I would reject this. This style matches the baseline in this paragraph. OK Then I think they should all be fixed
3174	RISON, Mark	45	12.13.7	19	"PASN with defined key wrap" missing " AKMP"	As it says in the comment	Accept.	I agree, but I also note that this duplicates CID 3172 with a resolution in 11-24/968, so we need to help the Editor keep these aligned.
3176	RISON, Mark	46	12.13.7	14	"in PASN field" should be "in the PASN field"	As it says in the comment	Accept.	No, we need to reject this. “KEK in PASN” in the name of the field. OK Then the field name is incredibly confusing and the "in" should be "In"
3182	RISON, Mark	51	AF.2	49	"is 256" has two spaces	Delete one of them	Accept.	Similar to CID 3150. This needs to be Revised. It is actually already only one space, but it appears to a "wide" (em-dash sized) space. Replace with a normal space. Seems to depend on the tool being used. The "Accept" was to say that it will be corrected.
3205	RISON, Mark	37	12.2.12.1	49	Double full stop	Delete one of them	Accept.	I can’t find this problem. I think this is Rejected, no problem found. Agree, Reject. Hm, I agree. Having said that, at 42.7 the full stop in " {RSNE, GTK[N]. OCI" should be a comma
3206	RISON, Mark	37	12.2.12.1	48	"or any procedure" doesn't make sense	Change to "or any other procedure"	Accept.	Agree with Accept. But, I’d add a “Note to Editor, the location is actually 37.44.”
3207	RISON, Mark	39	12.2.12.2	32	"can" is the correct way to say "is able to"	As it says in the comment	Accept.	I don’t know what this is requesting (I can’t find the location/problem), so I don’t agree with “Accept”. In general, we need to be careful substituting “can” (which explicitly means the Standard supports this as an optional behavior) for “is able to” (which is a more declarative statement of what is believed to be a fact). Agree, Reject. Is this comment held over from another version? No, this is on the current text: " If a non-AP STA has previously provided an IRM to an AP in as ESS, and the non-AP STA sends an Authentication frame using that IRM as the TA to any AP in the ESS, then the AP receiving the Authentication frame is able to identify the non-AP STA before association is started or completed." "can" is not "optional behaviour" -- that's "may" -- it's "The word can is used for statements of possibility and capability." (which I've always understood as implying "based on normative text elsewhere")

On Fri, Jun 14, 2024 at 10:03 AM G Smith <gsmith@xxxxxxxxxxxxxxxxxxx> wrote:

Hi Mark,

Also

CID 3060 I agree that “its” is better

CID 3061 I would prefer “The IRM mechanism” and “The device ID mechanism” so as to be consistent.

CID 3062 I suggest “mechanisms” and sentence revised to read “If an AP and non-AP STA have both IRM and device ID mechanisms activated,…”

CID 3063, I agree should be a reject.

Thanks

Graham

From: G Smith
Sent: Friday, June 14, 2024 9:43 AM
To: mark.hamilton2152@xxxxxxxxx; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBH] Personal comments on Editorial CIDs

Hi Mark,

We resolved CID 3033 in 24/0916r7 as

Revised - Change title to "Identifiable random MAC address (IRM) mechanism". At 48.38, change "IRM operation" to "IRM mechanism"

In the text we refer to IRM mechanism in a lot of places.

Thanks

Graham

From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Thursday, June 13, 2024 2:02 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBH] Personal comments on Editorial CIDs

All,

I have the following (personal, not as Chair) comments on the proposed resolutions for the Editorial TGbh CIDs, as found in 11-24/0952r1 .

I’d like to see if others (including @Carol Ansley, on further review?) agree/disagree with these comments.

Thanks! Mark

CID

Name

Page

Subclause

Line

Comment

Proposed Change

Editor’s Proposed Resolution Text

Mark H comments

3014

Smith, Graham

35

12.2.12.1

60

The paragraph at P35.58 is on PASN. It would be better to move this to Page 36 just preceeding line 20 where the PASN explanation is given.

Move paragraph to just before P36.20.

Revised. Editor to switch the order of the 3rd and 4th paragraphs in section 12.2.12.1 to group the AP-related paragraphs on PASN together.

(Paragraphs are intended to be 13 and 14, I think?)

Agreed, but I think more should be done. I note that many paragraphs are agnostic as to which scenario/mechanism applies. Then the one at P36.50 really should be for non-PASN only, because it conflicts with the one at P36.60. So, those two should be in parallel together somewhere, that lists out all the scenario-specific points (are there any others that should go with them?) (See CID 3042 on L50 not being clear, and resolution in 11-24/0885, though, also.) Then, we have a big example of PASN, but no examples of the others (see CID 3131 suggesting to add more). And, the last paragraph is probably too important to be lost at the end like it is.

3033

Stacey, Robert

37

12.2.12.2

50

"Identifiable random MAC address (IRM) operation" in the title but "IRM mechanism" elsewhere.

Change title to "Identifiable random MAC address (IRM) mechanism". At 48.28, change "IRM operation" to "IRM mechanism"

Revised. Editor to remove mechanism and operation from section titles and PICs table for better aligment with baseline text.

Editor says to remove both "mechanism" and "operation" for better alignment with baseline. Is that correct? I can live with it. But, Graham (11-24/0916) changed it to "operation". Which way is it?

3053

Patwardhan, Gaurav

39

12.2.13

46

Typo. It should be ‘… shall be used as derived a part of.. “

as in comment

Revised. Editor to change phrase to "shall be used as derived from the PTK"

How about "The KEK, as derived from the PTK, shall be used with the negotiated key wrap algorithm."

3060

McCann, Stephen

34

12.2.12

24

TA (Transmission Address) requires an article.

Change "TA" to "a TA" at the cited location. Change "TA" to "the TA" at P34L25.

Accept.

Suggest “its TA” would be better than “a TA” (first location).

3061

McCann, Stephen

34

12.2.12

36

device ID requires an article.

Change "Device ID" to "The device ID" at the cited location.

Accept.

Suggest to change "IRM allows", also. And, change both to "The <xxx> feature allows…"

3062

McCann, Stephen

34

12.2.12

37

The sentence "If an AP and a non-AP STA both have both IRM and device ID activated..." has a couple of typos.

Change the cited sentence to "If an AP and a non-AP STA have both
an IRM and a device ID activated...".

Accept.

(Note, see CID 3061 on same text.) It is not "has an IRM", but "has [the] IRM [feature] activated" (as well as the device ID feature). So, need different fix-up to the wording.

3063

McCann, Stephen

36

12.2.12.2

8

The sentence "If an AP sets Device ID (sub)element or Device ID KDE with the Device ID Status field set to 1…" has a couple of typos.

Change the cited sentence to "In an AP, if the Device ID Status field in a Device ID (sub)element or Device ID KDE is equal to 1…."

Accept.

Suggest rejecting this. This is meant to correlate to the AP at the time when it is setting the Device ID Status field (in preparation for transmitting it), that it may also provide a new device ID in the same element. Phrasing this as a test (“equal to”) of the Device ID Status field (as if it were a received field) is confusing.

3064

McCann, Stephen

35

12.2.12.1

18

In the 802.11 baseline the usual phrase is "out of scope of this standard".

Change "out of scope for this standard" to "out of scope of this standard" and also on P38L20.

Accept.

Agree with the Accepted. However, it is worth noting to the REVme folks that there are 3 instances of “out of scope for” in the REVme baseline, also.

3123

Lalam, Massinissa

29

9.4.2.319

44

Replace "The format of the PASN Encrypted Data element is shown in Figure 9-1072e (Device ID subelement format)." with "The format of the PASN Encrypted Data element when Subelement ID equals Device ID is shown in Figure 9-1072e (Device ID subelement format)."

As in comment

Accept.

I have a minor rewording to suggest: "The format of the Encrypted Data field when it contains a Device ID subelement is shown…" or some such.

3124

Lalam, Massinissa

29

9.4.2.319

63

Replace "The format of the IRM subelement is shown in Figure 9-1072f (IRM subelement format)." with "The format of the PASN Encrypted Data element when Subelement ID equals IRM is shown in Figure 9-1072f (IRM subelement format)."

As in comment

Accept.

Same suggestion as CID 3123, just above.

3130

Lalam, Massinissa

51

AF

18

Consider renaming "(informative) Example opaque device identifier scheme" as "(informative) Example of an opaque device identifier scheme"

As in comment

Accept.

I’m okay with the direction (and hence the “accept in principle” conceptually), but we need specific wording – the Editor cannot just “Accept” this, as is.

3136

RISON, Mark

45

12.13.7

38

"a KEK and a KDK are derived" wrong verb

Change "and" to "and/or"

Accept.

I’d like to discuss. I thought “and/or” was not acceptable wording.

3138

RISON, Mark

25

9.4.2.19.7

60

"with a Length field set to 1" should be "with the Length field set to 1"

As it says in the comment

Accept.

This is text from the baseline. Do we (as a TG) agree that we should fix this?

3139

RISON, Mark

31

11.10.9.1.1

50

" measurement request is Active" should be " Measurement request is Active"

As it says in the comment. Ditto at 32.25

Accept.

This is text from the baseline. Do we (as a TG) agree that we should fix this?

3140

RISON, Mark

31

11.10.9.1.1

62

"measurement request" should be "Measurement request"

As it says in the comment

Accept.

Suggest we reject. The lower-case use is the convention in the baseline for referencing these frames in a general sense (not to a specific type of measurement request), and the proposed change would also be inconsistent with the existing text in this paragraph.

3141

RISON, Mark

32

11.10.9.1.1

17

"measurement request" should be "Measurement request"

As it says in the comment

Accept.

Same as CID 3140 just above.

3150

RISON, Mark

18

4.5.4.10

16

"an identifiable" has two extraneous spaces

Delete two spaces (also in nearby words; also e.g. at 39.20)

Accept.

I accept the concern, but it seems to be some sort of wide space, not two spaces. So the resolution probably needs some clarification.

3160

RISON, Mark

28

9.4.2.314

37

"Indicates that the IRM has not been recog-
nized" -- weird word-break

Don't hyphenate

Accept.

I’m not sure I agree with the comment. This is a line break issue with a long word. I suggest we just leave such issues to the professional (IEEE editing) at time of publication.

3163

RISON, Mark

30

9.4.2.316

12

"The Length field is defined in 9.4.3." missing (Subelements) which makes me worry a xref is going to be missed

As it says in the comment

Rejected. Comment is unclear as to the desired change.

I agree with this comment (at least as I think I understand it). This is asking for the usual “(Subelements)” to be added after the subclause number, to look like the usual cross-reference (which includes the subclause title). I think it’s just to help make sure this cross-reference gets noticed and turned into a hot link correctly, during integration (in REVmf).

3165

RISON, Mark

31

9.4.1.1.1 should be 9.4.1.11 (2x)

As it says in the comment

Accept.

Agree with the comment and Accepting it. But, to help the Editor (and others reviewing), I would explicitly mention that the locations are P34.1 and P34.19.

3170

RISON, Mark

43

12.13.2

32

"When PASN AKMP" missing article

As it says in the comment

Accept.

I would reject this. This style matches the baseline in this paragraph.

3174

RISON, Mark

45

12.13.7

19

"PASN with defined key wrap" missing " AKMP"

As it says in the comment

Accept.

I agree, but I also note that this duplicates CID 3172 with a resolution in 11-24/968, so we need to help the Editor keep these aligned.

3176

RISON, Mark

46

12.13.7

14

"in PASN field" should be "in the PASN field"

As it says in the comment

Accept.

No, we need to reject this. “KEK in PASN” in the name of the field.

3182

RISON, Mark

51

AF.2

49

"is 256" has two spaces

Delete one of them

Accept.

Similar to CID 3150. This needs to be Revised. It is actually already only one space, but it appears to a "wide" (em-dash sized) space. Replace with a normal space.

3205

RISON, Mark

37

12.2.12.1

49

Double full stop

Delete one of them

Accept.

I can’t find this problem. I think this is Rejected, no problem found.

3206

RISON, Mark

37

12.2.12.1

48

"or any procedure" doesn't make sense

Change to "or any other procedure"

Accept.

Agree with Accept. But, I’d add a “Note to Editor, the location is actually 37.44.”

3207

RISON, Mark

39

12.2.12.2

32

"can" is the correct way to say "is able to"

As it says in the comment

Accept.

I don’t know what this is requesting (I can’t find the location/problem), so I don’t agree with “Accept”. In general, we need to be careful substituting “can” (which explicitly means the Standard supports this as an optional behavior) for “is able to” (which is a more declarative statement of what is believed to be a fact).

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

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