> On Jan 28, 2026, at 05:00, John Mattsson <[email protected]> wrote: > > > Hi Paul, > > Thanks for the review. > > >How does one determine the length of the EDHOC Message Length field? > > This is described in the L field. > > L: The L flag bits represent the binary encoding of the size of the > EDHOC Message Length, which can range from 0 to 4 bytes. When all > three bits are set to 0, the EDHOC Message Length field is not > present. If the first two bits of the L field are set to 0 and > the last bit is set to 1, then the size of the EDHOC Message > Length field is 1 byte, and so on. Values from 5 to 7 are not > used in this specification. > > Based on your question we should probably dd a sentence about this in the > description of the “EDHOC Message Length” field. For example: > > The EDHOC Message Length field, when present, has a size of one to four > octets, as determined by the L flag bits. It is included only when the L flag > bits indicate a value greater than zero and specifies the total length of the > EDHOC message being fragmented. When fragmentation is not used, this field is > omitted.
ah yes, thank you. > > > >I think RFC4137, RFC5216, RFC6677 should probably be normative references ? > > I think making 4137 and 6677 normative make sense. I think RFC5216 should > stay informative, the EAP-EDHOC packet format is just inspired by the EAP-TLS > packet format. sure. once you push out a new version, I'll issue the IETF LC. Paul > > Cheers, > John > > > > > From: Paul Wouters <[email protected]> > Date: Tuesday, 27 January 2026 at 23:30 > To: [email protected] <[email protected]> > Cc: [email protected] <[email protected]> > Subject: AD review draft-ietf-emu-eap-edhoc-06 > > AD review draft-ietf-emu-eap-edhoc-06 > > The draft looks generally fine and clear. I have one question and > one comment > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Code | Identifier | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | R |S|M| L | EDHOC Message Length ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | EDHOC Data ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 7: EAP-EDHOC Request and Response Packet Format > 4.1. EAP-EDHOC Request Packet > > > > The EDHOC Message Length field can have a size of one to four octets > and is present only if the L flag bits represent a value greater than > 0. This field provides the total length of the EDHOC message that is > being fragmented. When there is no fragmentation, it is not present. > > EDHOC Data: > > The EDHOC data consists of the whole or a fragment of the transported > EDHOC message. > > How does one determine the length of the EDHOC Message Length field? > > > > I think RFC4137, RFC5216, RFC6677 should probably be normative references ? > > Paul
_______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
