Last Call Review of draft-ietf-core-coap-tcp-tls-07

Request Review of draft-ietf-core-coap-tcp-tls
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2017-04-09
Requested 2017-03-26
Authors Carsten Bormann, Simon Lemay, Hannes Tschofenig, Klaus Hartke, Bill Silverajan, Brian Raymor
Draft last updated 2017-04-11
Completed reviews Genart Last Call review of -07 by Meral Shirazipour (diff)
Artart Last Call review of -07 by Mark Nottingham (diff)
Tsvart Last Call review of -07 by Yoshifumi Nishida (diff)
Tsvart Telechat review of -07 by Yoshifumi Nishida (diff)
Assignment Reviewer Yoshifumi Nishida
State Completed
Review review-ietf-core-coap-tcp-tls-07-tsvart-lc-nishida-2017-04-11
Reviewed rev. 07 (document currently at 11)
Review result Almost Ready
Review completed: 2017-04-11


Document: draft-ietf-core-coap-tcp-tls-07
Reviewer: Yoshifumi Nishida

I've reviewed this document as part of TSV-ART'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 for their
information and to allow them to address any issues raised.When done at the
time of IETF Last Call, the authors should consider this review together
with any other last-call comments they receive. Please always CC if you reply to or forward this review.

Summary: This document is well-written. It is almost ready to be published
as a PS draft once the following points are addressed.

1: It is not clear how the protocol reacts the errors from transport layers
(e.g. connection failure).
   The protocol will just inform apps of the events and the app will decide
what to do or the protocol itself will do something?

2: There will be situations where the app layer is freezing while the
transport layer is still working. Since transport layers cannot detect this
type of failures, there should be some mechanisms for it somewhere in the
protocol or in the app layer.  The doc needs to address this point. For
example, what will happen when a PONG message is not returned for a certain
amount of time?

3: Since this draft defines new SZX value, I think the doc needs to update
RFC7959. This point should be clarified more in the doc.