[core] Mirja Kühlewind's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS)

[Mirja Kühlewind <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-core-coap-tcp-tls-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

1) My general concern is that, while I don't necessarily want to block
the proposed format, I would like to understand further before
publication why this approach was chosen. Similar to Ben's discuss, I
don't understand why the format was chosen so differently. You could just
use the format (plus a new length option) as defined for UPD and just
never have any retransmission or reordering but be more flexible on the
lower layer transport to use. However, if you actually prefer a new
format (to save space), than that sounds like a new version for me, while
the draft says:
"CoAP is defined in [RFC7252] with a version number of 1.  At this time,
there is no known reason to support version numbers different from 1."
However, in this case it could even have made sense to define a new
format/version that could be used for both underlying protocols and
either have a length option or a message type and IP option.
Further I also don't understand why on the other hand the TCP COAP
framing is re-used for websockets because websockets already provides
message framing and a length field.

Also inline with Ben's discuss, the use of the Block option for CAOP/TCP
is not very clear to me. The draft says:
"a UDP-to-TCP gateway may simply not have the context to convert a
      message with a Block Option into the equivalent exchange without
      any use of a Block Option (it would need to convert the entire
      blockwise exchange from start to end into a single exchange)"
However, given that the COAP/TCP and COAP/UDP format are so different,
it's anyway a more complex conversion than just sticking another
transport underneath. The argument for HOL blocking due to e.g. upgrades
is also not clear to me because you should probably better just use a
different TCP connection for that as it really seems to be a different
use case.

For me this draft looks like you are defining basically a new protocol
version and not just COAP over TCP.

Again, I don't necessarily want to block this but I would like to
understand why the proposed approach was chosen.

2) Comments from the tsv-art review needs to be addressed as well (Thanks
to Yoshi Nishida for the review!). Here is the review text for your
connivence:

"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.“

3) And inline with Yoshi's comment, I don't think this part in section
3.3 is well specified; especially I don't understand how these two thing
fit together:
"To avoid unnecessary latency, a Connection Initiator MAY send
   additional messages without waiting to receive the Connection
   Acceptor's CSM; ..."
and
   "Endpoints MUST treat a missing or invalid CSM as a connection error
   and abort the connection (see Section 5.6)."
Also how long should I wait until I abort the connection?