RE: TSV-ART review of draft-ietf-core-coap-tcp-tls-07

[Brian Raymor <[e-mail]>]

Hi Yoshi,



> OK. I also think we should state that the protocol should notify the failure events to applications.

> Since errors can happen not only in TCP, but also TLS and websocket level, mentioning only TCP close or reset might not

> be enough.



After reviewing with the authors, an additional clarification was appended to 3.4 Connection Health - https://github.com/core-wg/coap-tcp-tls/pull/140/files



The opinion of the authors (and Gengyu WEI’s recent response - https://www.ietf.org/mail-archive/web/core/current/msg08622.html) is that RFC6455 covers the WebSocket case and does not need to be repeated here.



> When we use 7252, I think applications basically don't need to implement timeouts or retry mechanisms as the protocol

> provides such things.



RFC7252 provides timeouts and retries because it's implementing a TCP-like reliability mechanism over UDP - https://tools.ietf.org/html/rfc7252#section-2.1



> However, when we use this one, it seems applications will need to have such mechanisms. Isn't it a bit confusing? I am thinking that

> there need to be some guidance here.

> BTW, PONG is one example.



For coap-tcp-tls, there are multiple early implementations. This has never been reported as a source of confusion.



>> My sense is that we should treat this as an update to RFC7959 based on the original language:

> I don't have a strong opinion here. Updating 7959 is fine for me if it's clearer to CoAP people.



I've merged the change - https://github.com/core-wg/coap-tcp-tls/pull/138/files


Thanks again for helping us to improve the quality of the draft,

…Brian