HI Dan, Authors! >Thank you for the thorough review.
No problem. Ok with everything, thanks for taking my comments into consideration. Regarding this: >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? Yes, I think that should suffice! Have a good day, Saludos, Renzo On Fri, Oct 10, 2025 at 12:42 PM Dan Garcia Carrillo <[email protected]> wrote: > > 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 to [email protected] _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
