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. 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. 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”. 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?) 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? 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? --------- I am also working on the Shepherd's write up :) Have a good day, Renzo _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
