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 <
spencerdawkins(_dot_)ietf(_at_)gmail(_dot_)com> wrote:
Hi, Yoshi,
On Sat, Apr 29, 2017 at 11:24 PM, Yoshifumi Nishida <
nishida(_at_)sfc(_dot_)wide(_dot_)ad(_dot_)jp> 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 <
Brian(_dot_)Raymor(_at_)microsoft(_dot_)com> 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:nishida(_at_)sfc(_dot_)wide(_dot_)ad(_dot_)jp]
Sent: Friday, April 21, 2017 2:08 PM
To: Brian Raymor <Brian(_dot_)Raymor(_at_)microsoft(_dot_)com>
Cc: Yoshifumi Nishida <nishida(_at_)sfc(_dot_)wide(_dot_)ad(_dot_)jp>;
tsv-art(_at_)ietf(_dot_)org;
draft-ietf-core-coap-tcp-tls(_at_)ietf(_dot_)org; core(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org
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 <
Brian(_dot_)Raymor(_at_)microsoft(_dot_)com> 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
Tsv-art(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/tsv-art
_______________________________________________
core mailing list
core(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
Tsv-art mailing list
Tsv-art(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/tsv-art