a.
Document 11-21/871 – Dan (HPE) – Rejected Groups in SAE
I have the following comments on this submission:
- Is the "shall" going to result in any existing devices becoming
noncompliant?
I believe this was addressed on the call.
- "Each rejected group shall be represented as an unsigned 16-bit integer using the bit ordering conventions of 9.2.2 (Conventions)."
does not belong in Clause 12, and is already covered in Clause 9
(specifically 9.4.2.246->9.4.1.42->9.2.2). The correct place is
Clause 9 because Clause 9 is for format/encoding and other clauses
are for behaviour.
Since there was additional support by other people on the call to leave this language here. So I believe this has been addressed and you accept no change will be made.
- I think "in response to rejection of a previous SAE Commit message with status code set to UNSUPPORTED_FINITE_CYCLIC_GROUP"
is unclear. Is it the previous SAE Commit message that carries that SC,
or is it the rejection of that SAE Commit message that carries that SC?
And what does “a previous” mean here? Does it mean “the immediately previous”?
Again, this text is not unclear to the many people who have implemented this protocol. The issue at hand is a different part of the paragraph. This text, from the standpoint of people who implement the standard, is fine. Of course you are free to comment on
this in the next round of balloting of this draft.
- 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
consist ofinclude 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)),
the
an
Anti-Clogging Token field
is presentshall
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)
the
a
Password identifier element shall be
presentincluded 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)). 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
applicableany,
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). If
the status code of thean
SAE Commit message with status code set tois
SAE_HASH_TO_ELEMENT
is being sent
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.
[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:
"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?
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
regards,
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