| 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/16/21, 2:51 AM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote: [snip] - I suggest the wording could be made more straightforward and consistent as follows: 12.4.7.4 Encoding and decoding of SAE Commit messages An SAE Commit message shall
[The first change has been made in 21/0871r1 but I can't work out how to edit it in this email!] Yes, this edit in email thing seems to be part of the problem. That said, I think what you're asking is that the final sentence go from: I was and still am asking for the other changes shown in red, too (where not already incorporated in 21/0871), modulo the discussion re the final sentence, below. Well it seems the changes in red get lost in email, sigh. I will note that many of these have already been addressed in r1 which is on mentor and has been for a while. Maybe
we can clear the slate of red and blue email changes based on r0 which we have been debating and proceed with the latest-and-greatest. Maybe send a new email based on r1 if I have violated a capitalization rule or some such trifle.
"If the status code of the SAE Commit message is SAE_HASH_TO_ELEMENT and if any groups have been rejected during the current SAE session, the Rejected
Groups element shall be present, otherwise it shall not be present." to" "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." Correct? So this is "consistent" in the sense that it now talks about "a Commit Message with status code FOO being sent" as a previous sentence does.
But that sentence is using that construction to refer to the current message being a response to an immediately previous attempt. This text just says that if there had been any previous rejections, regardless of what your current response is for (again, it
could be an anti-clogging token), then you include the Rejected Groups element. So I think the text in the submission is still better and more clear. If you have an additional suggestion for this sentence to increase clarity I'd like to hear it. Probably better
to just send the whole sentence instead of attempting this highlight/crossout thing in email. How would you feel about: "If the status code of the SAE Commit message being sent is SAE_HASH_TO_ELEMENT and any groups have been rejected during the current SAE session, the
Rejected Groups element shall be present, otherwise it shall not be present." Can you live with that? 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. One does not send messages
in response to previous messages. What we need the message to look like is: token, group 20, 19 rejected --->
And that is exactly what my text says one should do! This message is being sent in response to an anti-clogging token rejection so the text that says if this message is being
sent in response to an anti-clogging token rejection to include the token. Also, since there have been rejections during the current SAE session the rejected groups element is there. So the text is not symmetric and each sentence is not constructed identically. So what. It makes sense and that's what matters. Your text, which having a "consistency" in
sentence construction throughout the paragraph is confusing and will likely result in more people doing the wrong thing.
Again, the issue is that someone was including an empty Rejected Groups element so I am attempting to retain description of the correct behavior (see the handshake above)
while mandating that if no bad group rejections have been received "during the current SAE session" then you don't include the Rejected Groups element.
regards, 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 |