Change:
There was quite a lot of overlap between 3.3.2 and 3.4. Tried to integrate 3.3.2 in 3.4 to avoid that.

Discussion:
3.3. EDHOC includes the selection of connection identifiers (C_I, C_R) <del> identifying a connection for which keys are agreed.  Connection identifiers may be used in the ongoing EDHOC protocol (see ci-edhoc) or in a subsequent application protocol, e.g., OSCORE (see ci- oscore).  The connection identifiers do not have any cryptographic purpose in EDHOC. </del> <ins> identifying a connection for which keys are agreed. Connection identifiers may be used to correlate EDHOC messages and facilitate the retrieval of protocol state during EDHOC protocol execution (see transport) or in a subsequent application protocol, e.g., OSCORE (see ci-oscore).  The connection identifiers do not have any cryptographic purpose in EDHOC. </ins> Connection identifiers in EDHOC are byte strings or integers, encoded in CBOR.  One byte connection identifiers (the integers -24 to 23 and

3.3.2. <del> Connection identifiers may be used to correlate EDHOC messages and facilitate the retrieval of protocol state during EDHOC protocol execution.  EDHOC transports that do not inherently provide correlation across all messages of an exchange can send connection identifiers along with EDHOC messages to gain that required capability, see transport.  For an example of using connection identifiers when CoAP is used as transport, see coap. 3.3.3. </del> For OSCORE, the choice of a connection identifier results in the endpoint selecting its Recipient ID, see Section 3.1 of RFC8613, for which certain uniqueness requirements apply, see Section 3.3 of

fragmentation, <del> demultiplex EDHOC messages from other types of messages, and </del> <ins> demultiplex EDHOC messages from other types of messages, denial-of-service protection, </ins> <del> denial-of-service protection. </del> <ins> message correlation. </ins> <del> Besides these common transport-oriented properties, EDHOC transport additionally needs to support the correlation between EDHOC messages, including an indication of a message being message_1.  The </del> <ins> The Initiator and the Responder need to have agreed on a transport to be used for EDHOC, see applicability. 3.4.1. The transport needs to support the correlation between EDHOC messages and facilitate the retrieval of protocol state during EDHOC protocol execution, including an indication of a message being message_1.  The </ins> correlation may reuse existing mechanisms in the transport protocol. For example, the CoAP Token may be used to correlate EDHOC messages <del> in a CoAP response and an associated CoAP request.  In the absence of correlation between a message received and a message previously sent inherent to the transport, the EDHOC connection identifiers may be added, e.g., by prepending the appropriate connection identifier </del> <ins> in a CoAP response and an associated CoAP request. Connection identifiers may be used to correlate EDHOC messages and facilitate the retrieval of protocol state during EDHOC protocol execution.  EDHOC transports that do not inherently provide correlation across all messages of an exchange can send connection identifiers along with EDHOC messages to gain that required capability, e.g., by prepending the appropriate connection identifier </ins> (when available from the EDHOC protocol) to the EDHOC message. Transport of EDHOC in CoAP payloads is described in coap, which also shows how to use connection identifiers and message_1 indication with CoAP. <del> The Initiator and the Responder need to have agreed on a transport to be used for EDHOC, see applicability. </del> 3.5. EDHOC enables public-key based authentication and supports various