Change:
Detect that an EDHOC message has been received, for example by means of port number, URI, or media type (applicability). <del> Retrieve the protocol state according to the message correlation provided by the transport, see transport.  If there is no protocol state, in the case of message_1, a new protocol state is created. The Responder endpoint needs to make use of available Denial-of- Service mitigation (dos). </del> <ins> Retrieve the protocol state according to the message correlation, see ci-edhoc.  If there is no protocol state, in the case of message_1, a new protocol state is created.  The Responder endpoint needs to make use of available Denial-of-Service mitigation (dos). </ins> If the message received is an error message, then process it according to error, else process it as the expected next message

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.