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