Original text:
SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a large number of variants SIGMA.  Like in IKEv2 RFC7296 and (D)TLS 1.3 RFC9147, EDHOC authenticated with signature keys is built on a <del> variant of the SIGMA protocol which provides identity protection of the Initiator (SIGMA-I) against active attackers, and like IKEv2, EDHOC implements the MAC-then-Sign variant of the SIGMA-I protocol shown in fig-sigma. </del>  The parties exchanging messages in an EDHOC session are called <del> Initiator (I) and Responder (R).  They exchange ephemeral public keys, compute a shared secret session key PRK_out, and derive symmetric application keys used to protect application data. </del>  G_X and G_Y are the ECDH ephemeral public keys of I and R, respectively. 3.1. The EDHOC protocol consists of three mandatory messages (message_1, <del> message_2, message_3) between an Initiator and a Responder, an optional fourth message (message_4), and an error message.  The roles have slightly different security properties which should be considered when the roles are assigned, see sec-prop.  All EDHOC messages are CBOR Sequences RFC8742, and are deterministically encoded. fig-flow illustrates an EDHOC message flow with the optional fourth message as well as the content of each message.  The protocol elements in the figure are introduced in overview and asym.  Message formatting and processing are specified in asym and error. </del>  Application data may be protected using the agreed application algorithms (AEAD, hash) in the selected cipher suite (see cs) and the

Reviewer comments:
Addresses
Q1: The document talks about the Initiator and Responder roles, what messages they send etc. But I can't find a definition of what the roles. I assume the Initiator initiates something, but unless I have missed it it would be good to have a few word of role definitions. URL
Yes, we will add that
Closing this as PR is merged. Reviewer: Christer Holmberg Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-lake-edhoc-18 Reviewer: Christer Holmberg Review Date: 2022-12-20 IETF LC End Date: None IESG Telechat date: Not scheduled for a telechat Summary: The document is well written, and easy to read. I do have one minor issue that I would like the authors to address. Major issues: N/A Minor issues: Q1: The document talks about the Initiator and Responder roles, what messages they send etc. But I can't find a definition of what the roles. I assume the Initiator initiates something, but unless I have missed it it would be good to have a few word of role definitions. Nits/editorial comments: N/A

Revised text:
SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a large number of variants SIGMA.  Like in IKEv2 RFC7296 and (D)TLS 1.3 RFC9147, EDHOC authenticated with signature keys is built on a  <ins> variant of the SIGMA protocol, SIGMA-I, which provides identity protection against active attacks on the party initiating the protocol.  Also like IKEv2, EDHOC implements the MAC-then-Sign variant of the SIGMA-I protocol shown in fig-sigma. </ins> The parties exchanging messages in an EDHOC session are called  <ins> Initiator (I) and Responder (R), where the Initiator sends message_1 (see overview).  They exchange ephemeral public keys, compute a shared secret session key PRK_out, and derive symmetric application keys used to protect application data. </ins> G_X and G_Y are the ECDH ephemeral public keys of I and R, respectively. 3.1. The EDHOC protocol consists of three mandatory messages (message_1,  <ins> message_2, message_3), an optional fourth message (message_4), and an error message, between an Initiator (I) and a Responder (R).  The odd messages are sent by I, the even by R.  Both I and R can send error messages.  The roles have slightly different security properties which should be considered when the roles are assigned, see sec-prop. All EDHOC messages are CBOR Sequences RFC8742, and are deterministically encoded. fig-flow illustrates an EDHOC message flow with the optional fourth message as well as the content of each message.  The protocol elements in the figure are introduced in overview and asym.  Message formatting and processing are specified in asym and error. </ins> Application data may be protected using the agreed application algorithms (AEAD, hash) in the selected cipher suite (see cs) and the