Re: [STDS-802-11-TGM] Teleconference reminder: June 14 @ 10am ET, re 21/

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

Hi Dan and All,

I’m a bit hesitant to provide my comments given the recent email exchange, but what the heck.

Some wordsmithing, comments, and questions:

Regarding the sentence:

“If the status code is set to SAE_HASH_TO_ELEMENT and any groups have been rejected during the current SAE session, a Rejected Groups element (see 9.4.2.246 (Rejected Groups element)) shall be included, otherwise it shall not be included.” from Mark Rison

“If an SAE Commit message with status code set to SAE_HASH_TO_ELEMENT is being sent and any groups have been rejected during the current SAE session, the Rejected Groups element shall be present, otherwise it shall not be present.” from Dan Harkins

Is the meaning/intent of the updated sentence :

“An SAE Commit message with status code SAE_HASH_TO_ELEMENT shall include the Rejected Groups element containing all groups rejected during the current SAE session, if no groups have been rejected the Rejected Groups element shall not be present.”

Note/question: I have removed “set to” as I don’t think its use is consistent with the style guide: “The verb “set” should only be used when describing how a field obtains a value, e.g. “The Measurement Duration field is set to the preferred or mandatory duration of the requested measurement, expressed in units of TUs.” Where the value of the field is read or referenced, (e.g., in the context of a condition), “is set to” shall not be used.”

If you agree this wording is preferred and is in line with the style guide, I suggest this “correct” wording be used throughout clause 12 as an editorial change.

Regarding the sentence:

“If an SAE Commit message with status code set to SAE_HASH_TO_ELEMENT is being sent in response to rejection of a previous SAE Commit message with status code set to UNSUPPORTED_FINITE_CYCLIC_GROUP , the group that was rejected shall be appended, after the rejected groups from previous attempts if any, to the Rejected Groups field of the Rejected Groups element.” from Mark Rison

If an SAE Commit message with status code set to SAE_HASH_TO_ELEMENT is being sent in response to rejection of a previous SAE Commit message with status code set to UNSUPPORTED_FINITE_CYCLIC_GROUP[MR1] , the group that was rejected shall be appended, after the rejected groups from previous attempts if any, to the Rejected Groups field of the Rejected Groups element (see 9.4.2.246 (Rejected Groups element)). ~~Each rejected group shall be represented as an unsigned 16-bit integer using the bit ordering conventions of 9.2.2 (Conventions).~~ from Dan Harkins

Is the meaning/intent of the updated sentence :

“An SAE Commit message with status code SAE_HASH_TO_ELEMENT sent in response to an SAE Commit message with status code UNSUPPORTED_FINITE_CYCLIC_GROUP shall include the unsupported group in the Rejected Groups element, the group shall be appended following the groups rejected during the current SAE session, if any.”

I have some confusion regarding the ordering of these requirements and why is there a need specify that the rejected group is append. It is my understanding that the Rejected Groups element is defined to contain all groups rejected during the current SAE session, which should include the specified group, hence no need to call for it to be appended. Is the “real” requirement that an SAE Commit message with status code SAE_HASH_TO_ELEMNT is sent in response to the reception of an SAE Commit message with status code UNSUPPORTED_FINITE_CYCLIC_GROUP? If so, then this should be stated and the requirement to append the group is not necessary and should be removed.

Regards,

Joseph

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Thursday, July 1, 2021 5:12 AM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] Teleconference reminder: June 14 @ 10am ET, re 21/0871 (Rejected Groups in SAE)

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

External Mail

I'm happy to spend time during a teleconf to go through the requisite

changes, since we've established that the changes are not conveyed

properly by email. I'm also happy to upload an update to 21/0871 with

the said changes (using change tracking and comments). Mr Chair, shall

I do so?

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: Harkins, Daniel <daniel.harkins@xxxxxxx>
Sent: Wednesday, 30 June 2021 20:52
To: Mark Rison <m.rison@xxxxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] Teleconference reminder: June 14 @ 10am ET, re 21/0871 (Rejected Groups in SAE)

Well I'm not going to go through your paragraph and determine exactly what changes you want since you're not willing (or able) to do it yourself. Furthermore, I am disinclined to make changes that are: 1) not accompanied with sufficient justification; and 2) are based on a "it's not clear to me" opinion from someone who doesn't implement the standard.

Dan.

"the object of life is not to be on the side of the majority, but to

escape finding oneself in the ranks of the insane." – Marcus Aurelius

On 6/30/21, 12:28 PM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote:

> So if I throw away the cruft and try to find the seed in your message it seems like all you want to change is "if applicable" to "if any" and the rest of the document is fine.

No, again, you're going on how things "seem" to you rather than just

reading what I've written.

I'm not sure how to put this any more simply. What I want is for the text to read:

An SAE Commit message shall include a Finite Cyclic Group field (see 9.4.1.42 (Finite Cyclic Group field)) indicating a group, a Scalar field (see 9.4.1.39 (Scalar field)) containing the scalar, and an FFE field containing the element (see 9.4.1.40 (FFE field)).

If the SAE Commit message is in response to an Anti-Clogging Token field request (see 12.4.7.6 (Status codes)), an Anti-Clogging Token field shall be included (see 9.4.1.38 (Anti-Clogging Token field)). When the PWE is derived using the hash-to-element method, the Anti-Clogging Token field is encapsulated in an Anti-Clogging Token Container element; otherwise, the Anti-Clogging Token field is included in the frame outside of an element as described in Table 9-41 (Presence of fields and elements in Authentication frames).

If a password identifier is used in generation of the password element (PWE) a Password identifier element shall be included and the identifier shall be encoded as a UTF-8 string in the Identifier portion of the element (see 9.4.2.216 (Password Identifier element)), otherwise it shall not be included.

If the status code is set to SAE_HASH_TO_ELEMENT and any groups have been rejected during the current SAE session, a Rejected Groups element (see 9.4.2.246 (Rejected Groups element)) shall be included, otherwise it shall not be included.

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: Harkins, Daniel <daniel.harkins@xxxxxxx>
Sent: Wednesday, 30 June 2021 20:16
To: Mark Rison <m.rison@xxxxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] Teleconference reminder: June 14 @ 10am ET, re 21/0871 (Rejected Groups in SAE)

As that line goes in Cool Hand Luke, "what we have here is a failure to communicate."

So if I throw away the cruft and try to find the seed in your message it seems like all you want to change is "if applicable" to "if any" and the rest of the document is fine.

Please provide a coherent case for making that change.

Dan.

"the object of life is not to be on the side of the majority, but to

escape finding oneself in the ranks of the insane." – Marcus Aurelius

On 6/30/21, 12:07 PM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote:

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

I suggest the following for this round, which consistently enumerates the conditions

for the not-always-included things:

Again, the previous text, whose construction you seem to be feverishly working to match, is discussing how to generate this present new request, the message currently being worked assembled, based on the immediate response you just got. The new text which is the final sentence I'm adding is not about construction of a new request based on the immediate response. In fact, the behavior depends on potentially many previous responses you had gotten. And the way you know, presently, what to do is whether "any groups have been rejected during the current SAE session." That's the key. That's why your text not satisfactory. Let me try, again, to describe it.

Alice Bob

group 19 --->

<--- reject, bad group

group 20, 19 rejected --->

<--- reject, anti-clogging token

And here we are! Now your text is somewhat unclear about what to do. The SAE Commit message with status set to SAE_HASH_TO_ELEMENT is being sent in response to an anti-clogging token. But your text says "a previous SAE Commit message." But this current SAE Commit message is not being sent in response to a previous one, it's being sent in response to the most recent one, the anti-clogging token request.

I'm confused. Your 21/0871r1 also has this "a previous SAE Commit message"

which you are now objecting to:

Well if you read what I wrote you wouldn't be confused. I am not objecting outright to the phrase "a previous SAE Commit message". That phrase exists in the paragraph now and there is no problem with it because it is, as I say above, "discussing how to generate this present new request, the message currently being worked assembled, based on the immediate response you just got." That's fine. But you seem to be driven for sentence symmetry or "consistency" or something and if a particular phrase was used before then it has to be crammed somehow into subsequent sentences. You want to use that phrase when discussing this new behavior which is _not necessarily_ bound by the immediate response we just got. Just because a previous sentence says "a previous SAE Commit message" doesn't mean that subsequent sentences must.

I do not understand what you are talking about. Instead of vague

hypotheticals involving how things "seem" to you and what you

think "drives" me, please address my specific proposal, which,

again, is:

The only change I am proposing in this sentence is to change "if applicable" to

"if any".

OK, then I will take that statement to mean that all the other editorial changes you had wanted in your previous emails to have been resolved.

I do not understand what you are talking about. That statement means what it

says, namely that the only change I am proposing in the sentence in question is

to change "if applicable" to "if any". Again, my specific proposal is:

I agree "rejection of a previous SAE Commit" message is "somewhat unclear".

I think I pointed this out before, but I had understood from your response then

that you were not disposed to address this in this round. I'm more than happy

to address it in this round if you've changed your mind. What do you think

would make that sentence from 21/0871r1 clearer?

It's clear. That is my contention. That final sentence that is being added in 11-21/087r1 is fine and needs no additional edits.

I'm sorry, I do not follow you. We are not talking about the final sentence

in 21/0871. We are talking about the final sentence in my proposal.

Yesterday, you objected on the basis that my text was "somewhat unclear" because

it " says "a previous SAE Commit message."", which indeed it does:

However, yours in 21/0871r1 does too, in the third-from-last sentence:

Would you be kind enough to clarify why it's "somewhat unclear" when I

present it, but "clear" and "fine and needs no additional edits" when you present it?

Just to make sure there's no doubt, here again is my specific proposal:

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

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