Re: [core] [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07
Carsten Bormann <cabo@tzi.org> Mon, 08 May 2017 07:31 UTC
Return-Path: <cabo@tzi.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31C9120726; Mon, 8 May 2017 00:31:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zn_fK4q7mr91; Mon, 8 May 2017 00:31:10 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB481252BA; Mon, 8 May 2017 00:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v487V3UJ006405; Mon, 8 May 2017 09:31:03 +0200 (CEST)
Received: from [172.20.10.9] (ip-109-43-3-45.web.vodafone.de [109.43.3.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wLvLZ4KZKzDGnc; Mon, 8 May 2017 09:31:02 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [core] [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAKKJt-em-dLP9qyhTOZ00x4oOGuXVLdbbNaVVKH3kLw=6JZ_dw@mail.gmail.com>
Date: Mon, 08 May 2017 09:31:00 +0200
Cc: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, "tsv-art@ietf.org" <tsv-art@ietf.org>, "draft-ietf-core-coap-tcp-tls@ietf.org" <draft-ietf-core-coap-tcp-tls@ietf.org>, "core@ietf.org" <core@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
X-Mao-Original-Outgoing-Id: 515921460.808467-f6d599a9985d35a22970a1c6d17b9be2
Content-Transfer-Encoding: quoted-printable
Message-Id: <4F24893A-C088-45EB-97CE-126231933918@tzi.org>
References: <CAO249ye7KNdcbQfmOfik7QYFiXS9zcTE5n19pngHLgeur2XFpg@mail.gmail.com> <BY2PR21MB0084E781B2831EBC6A5F4E88831B0@BY2PR21MB0084.namprd21.prod.outlook.com> <CAO249ydcc7k2i5=OSSvvtzU2B1Qa62b3RR3iY0wBfQ2pOYQrkQ@mail.gmail.com> <BY2PR21MB00849DB795086F08F6D7A98A831A0@BY2PR21MB0084.namprd21.prod.outlook.com> <CAO249yeS8sZaJcADuz+bYAJa-CXs4v291Fm=adRouO1R=svPDw@mail.gmail.com> <BY2PR21MB008453149ADC1A998FEA56D3831A0@BY2PR21MB0084.namprd21.prod.outlook.com> <CAO249ydRLFpG=yHYvaZvPBiQuW5x=4HZqCZyTAb2HHeDuP+wAA@mail.gmail.com> <CAKKJt-em-dLP9qyhTOZ00x4oOGuXVLdbbNaVVKH3kLw=6JZ_dw@mail.gmail.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/_z_ACzoO-8I6doChoDyosMT5BFs>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 May 2017 07:31:14 -0000
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.ietf@gmail.com> wrote: > > 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-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@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/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@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core
- Re: TSV-ART review of draft-ietf-core-coap-tcp-tl… Carsten Bormann
- TSV-ART review of draft-ietf-core-coap-tcp-tls-07 Yoshifumi Nishida
- Re: [Tsv-art] TSV-ART review of draft-ietf-core-c… Yoshifumi Nishida
- RE: TSV-ART review of draft-ietf-core-coap-tcp-tl… Brian Raymor
- Re: [core] TSV-ART review of draft-ietf-core-coap… weigengyu
- Re: TSV-ART review of draft-ietf-core-coap-tcp-tl… Yoshifumi Nishida
- RE: TSV-ART review of draft-ietf-core-coap-tcp-tl… Brian Raymor
- RE: TSV-ART review of draft-ietf-core-coap-tcp-tl… Brian Raymor
- Re: TSV-ART review of draft-ietf-core-coap-tcp-tl… Yoshifumi Nishida
- Re: TSV-ART review of draft-ietf-core-coap-tcp-tl… Yoshifumi Nishida
- Re: [core] TSV-ART review of draft-ietf-core-coap… weigengyu
- Re: [core] TSV-ART review of draft-ietf-core-coap… Carsten Bormann
- Re: [core] TSV-ART review of draft-ietf-core-coap… weigengyu
- Re: [core] TSV-ART review of draft-ietf-core-coap… Yoshifumi Nishida
- Re: [Tsv-art] TSV-ART review of draft-ietf-core-c… Spencer Dawkins at IETF
- Re: [core] [Tsv-art] TSV-ART review of draft-ietf… weigengyu
- Re: [core] [Tsv-art] TSV-ART review of draft-ietf… Carsten Bormann
- Re: [Tsv-art] TSV-ART review of draft-ietf-core-c… Yoshifumi Nishida
- Re: [Tsv-art] [core] TSV-ART review of draft-ietf… Yoshifumi Nishida
- Re: [core] [Tsv-art] TSV-ART review of draft-ietf… weigengyu