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

[Yoshifumi Nishida <[e-mail]>]

Hello,
As far as I've read -08 draft, I think this point has not been addressed
yet. I hope some folks could elaborate a bit more if they think this is not
an important point for the draft.
--
Yoshi

On Fri, Apr 21, 2017 at 2:57 PM, Brian Raymor <[e-mail]>
wrote:

> I think that I understand your perceptions better. Prior to adoption of
> coap-tcp-tls and before I was active in the WG, I recall discussions
> related to the confusion over application vs transport reliability in CoAP
> especially as related to CON and NON. What was intended?
>
>
>
> Tim Carey outlined some concerns in:
>
> https://tools.ietf.org/html/draft-carey-core-std-msg-vs-tran
> s-adapt-00#section-2
>
>
>
> This topic was presented in detail at IETF 93 -
> https://www.ietf.org/proceedings/93/slides/slides-93-core-0.pdf -
> starting on slide 23.
>
>
>
> And in a related thread on the mailing list back in 2015 -
> https://www.ietf.org/mail-archive/web/core/current/msg06280.html -
> Carsten responded:
>
>
>
> > In any case, CON and NON are about message layer semantics, not about
> application semantics
>
> > -- you gave them a meaning they don't have.
>
>
>
> By IETF 94, the authors were reporting – “Most of the Confusion
> around              CON/NON was resolved”.
>
>
>
> Where relevant, I’ve added clarifications - such as the Appendix related
> to differences in Observe for reliable transports.
>
>
>
> Both Carsten and Hannes could probably offer more context if needed.
>
>
>
> *From:* Yoshifumi Nishida [mailto:[e-mail]]
> *Sent:* Friday, April 21, 2017 2:08 PM
> *To:* Brian Raymor <[e-mail]>
> *Cc:* Yoshifumi Nishida <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> *Subject:* Re: TSV-ART review of draft-ietf-core-coap-tcp-tls-07
>
>
>
> 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/coa
> p-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/rf
> c7252#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/coa
> p-tcp-tls/pull/138/files
>
>
>
> Thanks again for helping us to improve the quality of the draft,
>
>
>
> …Brian
>
>
>