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

[Yoshifumi Nishida <[e-mail]>]

Hi Brian,

Just in case,
Reliable transports only provide reliability at transport level. It doesn't
provide reliability in application protocol level.

RFC7252 has reliability mechanisms in it since it uses UDP. This means it
has abilities to check both transport and app level reliability.
This draft only provides transport level reliability and apps will need to
detect app protocol failure by themselves.
This means 7252 and this draft are not totally equivalent from the
viewpoint of applications.

I am not saying this is wrong or bad, but I believe app developer should
aware this point.
--
Yoshi

On Fri, Apr 21, 2017 at 11:15 AM, Brian Raymor <[e-mail]>
wrote:

> 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
>