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
tsv-art@ietf.org 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.