Skip to main content

Last Call Review of draft-ietf-lake-edhoc-18
review-ietf-lake-edhoc-18-tsvart-lc-scharf-2022-12-23-00

Request Review of draft-ietf-lake-edhoc
Requested revision No specific revision (document currently at 23)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2022-12-31
Requested 2022-12-05
Requested by Stephen Farrell
Authors Göran Selander , John Preuß Mattsson , Francesca Palombini
I-D last updated 2022-12-23
Completed reviews Secdir Last Call review of -20 by Radia Perlman (diff)
Secdir Last Call review of -18 by Radia Perlman (diff)
Genart Last Call review of -18 by Christer Holmberg (diff)
Intdir Last Call review of -18 by Donald E. Eastlake 3rd (diff)
Tsvart Last Call review of -18 by Michael Scharf (diff)
Assignment Reviewer Michael Scharf
State Completed
Request Last Call review on draft-ietf-lake-edhoc by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/wQ_j5CRStwi2rtvi0SCGVV4UVOw
Reviewed revision 18 (document currently at 23)
Result Ready w/nits
Completed 2022-12-23
review-ietf-lake-edhoc-18-tsvart-lc-scharf-2022-12-23-00
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.