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

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



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