Dear Renzo,
Thank you for the thorough review.
Please see comments inline.
El 6/10/25 a las 16:44, Renzo Navas escribió:
Dear EMU WG,
Here is a modest review of draft-ietf-emu-eap-edhoc.
Most/all are simply recommendations to clarify (if needed) some things.
--------------------------
Section 1.1 . “CBOR Web Tokens”--> Opportunistically define the
acronym “(CWT)”.Same comment for “CWT Claims Sets” --> CCS or CCSs (I
have seen both). The acronym CCSs is later used in SS 6.1.1 without
proper definition.
[Authors] Ok, thank you. We will define the acronyms.
Section 3.1. About “L” (3 bits), L is referenced as a “flag bits” OK.
Then the phrase “L bits are set’ is OK-ish (meaning at least one is
different from zero I guess, because it could also mean all three must
be set to 1) , maybe clarify unless it is well known that for a
non-binary “flag” of multiple bits “to be set” is equivalent to be
non-zero.
[Authors] Thank you. We will clarify this.
We mean that at least one is different from zero. We well add a
clarification about this.
My real call for mild modification/clarification is on paragraph
4:“Implementations MUST NOT set the L bit in unfragmented messages.
(...) messages regardless of whether the L bit is set.” --> L is not a
bit, so we have to keep calling it “flag” or “flag bits”.. Or maybe
“bits”, but I think it is incorrect to call it “bit” in singular.
Sorry for this nitpicking, but this came up analysing section 4.1 and
the way things are defined. I think we can also gain clarity in this
section with the nomenclature being consistent, and also maybe
explicit of what means for a non-binary flag to “be set”.
[Authors] Thank you. We will call this L flag bits or L field, to
avoid misunderstandings.
Section 4.1
Identifier. I had a comment about incremental identifiers and
fragments, but in section 3.1.6 it is solved by specifying incremental
identifiers for fragments. My understanding is then that outside that
case, a non-fragmented EAP Message can carry any non used Identifier
from the run of the protocol (not necessarily incremental).Correction,
Identifier only needs to be different from the previous Req.
Identifier. From RFC3748 S4.1 “the Identifier value chosen for each
new Request need only be different from the previous Request, but need
not be unique within the conversation“
Maybe my question/takeaway is: do we want to be a little bit more
explicit on what we expect about Identifiers? (Maybe reference section
3.1.6 for the case of fragments which requires incremental?)
[Authors] Whe have the following text in section 3.1.6.
"To prevent errors in the processing of fragments, the EAP server
MUST increment the Identifier field for each fragment contained
within an EAP-Request, and the peer MUST include this Identifier
value in the fragment ACK contained within the EAP-Response.
Retransmitted fragments will contain the same Identifier value."
So, maybe with a clarification about the Identifier field in 4.1
such as "In case of fragmented messages, the identifier will follow
the indications of Section 3.1.6" would be ok?
L field( 3 bits): Determines size from 0 to 4. Case 000 is explicited.
But maybe also specify what happens with values from 5-7 (is not
specified). Shall we assume 4, or error, or other thing?
[Authors] We will add a clarificaiton. As you say, values from 5-7
are not considered in the specification.
SS 6.1.1.
Item “(1)” : These include X.509 certificates [RFC9360], C509
certificates, CWTs ([RFC9528] Section 3.5.3.1), and CCSs ([RFC8392]
Section 3.5.3.1).”
[RFC8392] Section 3.5.3.1 does not exist, I think you want to refer to
[RFC8392] Section 7.1?
[Authors] Thank you for this. Yes we will correct the reference.
---------
I am also working on the Shepherd's write up :)
Have a good day,
Renzo
Thank you.
Best regards,
-- Dan
_______________________________________________
Emu mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
Emu mailing list -- [email protected]
To unsubscribe send an email to [email protected]
