| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
On 6/30/21, 9:09 AM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote: I suggest the following for this round, which consistently enumerates the conditions for the not-always-included things: 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. 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.
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: 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 applicable, to the Rejected Groups field of the Rejected Groups element. 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. 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 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. Dan. 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 |