Re: [Tsv-art] [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07

[Yoshifumi Nishida <[e-mail]>]

Hi Carsten,

Great. I will take a look at it when it's published.
Thanks for the efforts!
--
Yoshi

On Mon, May 8, 2017 at 12:31 AM, Carsten Bormann <[e-mail]> wrote:

> Hi Spencer,
>
> I’m not Yoshi :-), but I just have started working on an update of
> https://lwig-wg.github.io/coap/#rfc.section.6
> with some of the new information that relates to CoAP over reliable; I
> hope that I will be able to push this during this week.
>
> Note that CoAP over TCP/TLS/WS does address application layer
> acknowledgement beyond the request-response acknowledgement semantics by
> introducing the custody option of the PING/PONG signaling messages.  This
> may be useful in compensating the decrease of information available to the
> CoAP application as a result of moving some of the transport functionality
> into TCP.
>
> Grüße, Carsten
>
>
>
> > On May 8, 2017, at 05:17, Spencer Dawkins at IETF <
> [e-mail]> wrote:
> >
> > Hi, Yoshi,
> >
> > On Sat, Apr 29, 2017 at 11:24 PM, Yoshifumi Nishida <
> [e-mail]> wrote:
> > 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.
> >
> > I've seen the subsequent e-mails in reply to yours, but it's not obvious
> to me whether you think this point was addressed after reading those
> e-mails.
> >
> > What do you think?
> >
> > Thanks,
> >
> > Spencer
> >
> > --
> > 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-
> trans-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/
> 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
> >
> >
> >
> >
> >
> > _______________________________________________
> > Tsv-art mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tsv-art
> >
> >
> > _______________________________________________
> > core mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/core
>
> _______________________________________________
> Tsv-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tsv-art
>