Change:
message duplication, <ins> flow control, </ins> fragmentation and reassembly, demultiplex EDHOC messages from other types of messages, denial-of-service protection, <del> message correlation. </del> <ins> message correlation, see ci-edhoc. EDHOC does not require error free transport since a change in message content is detected through the transcript hashes in a subsequent integrity verification, see asym. EDHOC is designed to enable an authenticated key exchange with small messages, where the minimum message sizes are of the order illustrated in the first column of fig-sizes.  There is no maximum message size specified by the protocol; this is for example dependent on the size of authentication credentials (if they are transported, see auth-key-id). </ins> <del> The use of transport is specified in the application profile </del> <ins> The use of transport is specified in the application profile, which in particular may specify limitations in message sizes, see </ins> applicability. 3.4.1. <del> The transport needs to support the correlation between EDHOC messages and facilitate the retrieval of protocol state and security context during an EDHOC session, including an indication of a message being message_1.  The correlation may reuse existing mechanisms in the transport protocol.  For example, the CoAP Token may be used to correlate EDHOC messages 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/security context during an EDHOC session.  Transports that do not inherently provide correlation across all messages of an EDHOC session can send connection identifiers along with EDHOC messages to gain that required capability, e.g., by prepending the appropriate connection identifier (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> <ins> Correlation between EDHOC messages is needed to facilitate the retrieval of protocol state and security context during an EDHOC session.  It is also helpful for the Responder to get an indication that a received EDHOC message is the beginning of a new session, such that no existing protocol state or security context needs to be retrieved. Correlation may be based on existing mechanisms in the transport protocol, for example, the CoAP Token may be used to correlate EDHOC messages in a CoAP response and in an associated CoAP request.  The connection identifiers may also be used to correlate EDHOC messages. If correlation between consecutive messages is not provided by other means then the transport binding SHOULD mandate prepending of an appropriate connection identifier (when available from the EDHOC protocol) to the EDHOC message.  If message_1 indication is not provided by other means, then the transport binding SHOULD mandate prepending of message_1 with the CBOR simple value "true" (0xf5), as a unique dummy identifier. Transport of EDHOC in CoAP payloads is described in coap, including how to use connection identifiers and message_1 indication with CoAP. A similar construction is possible for other client-server protocols. Protocols that do not provide any correlation at all can prescribe prepending of the peer's connection identifier to all messages. Note that correlation between EDHOC messages may be obtained without transport support or connection identifiers, for example if the endpoints only accept a single instance of the protocol at a time, and execute conditionally on a correct sequence of messages. </ins> 3.5.

Discussion:
Addressing
Opening a PR with one commit as placeholder, more updates to follow.
I tried to clarify normative text in Appendix A, which led to a refactoring of section A.2. Please comment on if this is going in the right direction.
Editor's note: Remains to write about flow control.
NAME NAME NAME Are you happy with the latest changes? (Plan to merge soon)
Looks good to me, thanks!
NAME provided some comments based on PR . The specification was already before quite open for various means to provide correlation. This may lead to interoperability problems even in the case of using EDHOC over CoAP (it did in one of the recent interop tests, where one party was not using prepended identifiers). If we are now reworking this text we should try to fix this. Correlation may be provided without the use of transport (which was the reason why prepended identifiers was not used). This should be mentioned. So on the one hand, the specification is limiting the description to the case when transport provides correlation, on the other hand is it a bit loose on how to achieve correlation even over CoAP, leading to interoperability problems. It is proposed to use a formulation like "Unless correlation is provided by other means" then SHOULD use . The only candidate for well-defined way is prepended identifiers. Formulations like this: “Prepended identifiers MAY be omitted in case the transport provides such correlation.” should be omitted since it could be a problem in case of proxying between TCP and UDP. Text referring to “the integer representation” should be rephrased, since it is a representation of identifiers which sometimes may be represented as integers. A sanity check of the processing steps in the new forward / reverse message flow sections showed one missing case when error message can be sent. When working with the changes I realized some other quirks: Throughout the draft, references about correlation are made to appendix A.2 (EDHOC over CoAP) instead of section 3.4.1 which contains the general description. I think it is better to reference the section in the body (which includes a reference to the appendix) Section 3.4.1 is not only about connection identifiers so the title is misleading.

Change from "Use of Connection Identifiers for EDHOC Message Correlation" to "EDHOC Message Correlation" After making these updates, the text in Appendix H becomes essentially redundant and can be removed and the remnants distributed over 3.4.1 and A.2.
A proposal included in PR : 1c4ebe7f
Closing this as is merged.
URL Nits in Section 3.4: The wording "In addition to the transport of messages including errors" does not explain whether (bit) errors in messages need to be handled in the underlying transport. If the protocol assumes error-free transport of messages, a better wording would be "In addition to reliable transport of messages without errors", or the like. "Flow control" is not listed as requirement in Section 3.4. That could be a bug or a feature. Yet, as the protocol targets devices with low memory that may run out of buffer space, it may make sense to be explicit whether flow control is needed to deal with scarce memory. If not, it would make sense to explain how an implementation running out of send/receive buffer space would deal with that. While the document stresses in various places that the message sizes are small, and example values are also included, neither a required minimum nor a worst-case maximum is mentioned. As the underlying transport has to support fragmentation, a definition may not be required. Yet, if min/max numbers can be derived, it could be useful to better explain them in Section 3.4 in order to illustrate the requirements on the underlying transport. If min/max numbers cannot be derived, a corresponding heads-up could be added instead to emphasize that the transport protocol needs to support arbitrarily large messages. Nits in Appendix A: It is not fully clear whether the content of Appendix A, or subsets thereof, are normative requirements for an implementation. This in particular applies to the RFC2119/RFC8174 language. The relationship between Appendix A and draft-ietf-core-oscore-edhoc is quite hard to understand.
error-free. EDHOC does not require error free. EDHOC will detect errors but it might be detected later in the message flow. We will add some considerations.We will think about what to write about flow controlA min number can be derived. We will add min numbers and some considerations on large messages.We agree with the Nits.

We will improve this. Reviewer: Michael Scharf Review result: Ready with Nits This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC EMAIL if you reply to or forward this review. This document basically specifies an application protocol that is by-and-large independent of an underlying reliable transport protocol. As such, there are no apparent transport issues in the protocol design itself. Transport protocol issues are in particular discussed in Section 3.4 and Appendix A. In both there are some small nits. Nits in Section 3.4: The wording "In addition to the transport of messages including errors" does not explain whether (bit) errors in messages need to be handled in the underlying transport. If the protocol assumes error-free transport of messages, a better wording would be "In addition to reliable transport of messages without errors", or the like. "Flow control" is not listed as requirement in Section 3.4. That could be a bug or a feature. Yet, as the protocol targets devices with low memory that may run out of buffer space, it may make sense to be explicit whether flow control is needed to deal with scarce memory. If not, it would make sense to explain how an implementation running out of send/receive buffer space would deal with that. While the document stresses in various places that the message sizes are small, and example values are also included, neither a required minimum nor a worst-case maximum is mentioned. As the underlying transport has to support fragmentation, a definition may not be required. Yet, if min/max numbers can be derived, it could be useful to better explain them in Section 3.4 in order to illustrate the requirements on the underlying transport. If min/max numbers cannot be derived, a corresponding heads-up could be added instead to emphasize that the transport protocol needs to support arbitrarily large messages. Nits in Appendix A: It is not fully clear whether the content of Appendix A, or subsets thereof, are normative requirements for an implementation.

This in particular applies to the RFC2119/RFC8174 language. The relationship between Appendix A and draft-ietf-core-oscore-edhoc is quite hard to understand.