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

Hi, Yoshi,

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