From nobody Mon May 1 22:33:48 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39B9129B2A for ; Mon, 1 May 2017 22:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 PjUSKesUGXPq for ; Mon, 1 May 2017 22:33:43 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id A02F4129B36 for ; Mon, 1 May 2017 22:31:29 -0700 (PDT) Received: from WeiGengyuPC (unknown [114.255.40.42]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id E53B719F36A; Tue, 2 May 2017 13:31:27 +0800 (HKT) Message-ID: From: "weigengyu" To: "Yoshifumi Nishida" , "Brian Raymor" Cc: , "Yoshifumi Nishida" , , , References: In-Reply-To: Date: Tue, 2 May 2017 13:31:27 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01D2C348.6680E2B0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [Tsv-art] [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 05:33:46 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_0018_01D2C348.6680E2B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all,=20 Transfering CoAP defined in -08 draft for reliable transmission = facilities is as important as CoAP over CON/NON message.=20 In -08 draft, it is just clear how to make a new message for tranfering = over TCP,=20 or other reliable facilities in the scenario (I) CoAP/UDP ---> (C2C) = Proxy ----> CoAP over TCP.=20 But in -08 draft it is unclear how to work for the scenario (II) = CoAP/TCP ---> (C2C) Proxy ----> CoAP over UDP.=20 The problem is when the C2C Proxy have got a message form the CoAP/TCP = side,=20 how the Proxy make a decision to delivery CON or NON message carrying = CoAP over UDP?=20 Even for the scenario (I), the problem is the same when delivering the = CoAP response. In these scenarios a key problem is that should the CoAP semantics be = End-to-End or Hop-by-Hop when a C2C proxy is existed.=20 Regards,=20 Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications From: Yoshifumi Nishida=20 Sent: Sunday, April 30, 2017 12:24 PM To: Brian Raymor=20 Cc: tsv-art@ietf.org ; Yoshifumi Nishida ; = draft-ietf-core-coap-tcp-tls@ietf.org ; core@ietf.org ; ietf@ietf.org=20 Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 Hello,=20 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 = 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#se= ction-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.=20 By IETF 94, the authors were reporting =E2=80=93 =E2=80=9CMost of the = Confusion around CON/NON was resolved=E2=80=9D.=20 Where relevant, I=E2=80=99ve 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]=20 Sent: Friday, April 21, 2017 2:08 PM To: Brian Raymor Cc: Yoshifumi Nishida ; 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.=20 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.=20 This means 7252 and this draft are not totally equivalent from the = viewpoint of applications.=20 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 = wrote: Hi Yoshi, > OK. I also think we should state that the protocol should notify = the failure events to applications.=20 > Since errors can happen not only in TCP, but also TLS and = websocket level, mentioning only TCP close or reset might not=20 > 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=E2=80=99s 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.=20 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.=20 >> 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, =E2=80=A6Brian -------------------------------------------------------------------------= ------- _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_0018_01D2C348.6680E2B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,
 
Transfering CoAP defined in -08 draft for reliable transmission = facilities=20 is as important as CoAP over CON/NON message.
In -08 draft, it is just clear how to make a new message for = tranfering=20 over TCP,
or other reliable facilities in the scenario (I) CoAP/UDP ---> = (C2C)=20 Proxy ----> CoAP over TCP.
But in -08 draft it is unclear how to work for the scenario (II) = CoAP/TCP=20 ---> (C2C) Proxy ----> CoAP over UDP.
 
The problem is when the C2C Proxy have got a message form the = CoAP/TCP=20 side,
how the Proxy make a decision to delivery CON or NON message = carrying CoAP=20 over UDP?
Even for the scenario (I), the problem is the same when delivering = the CoAP=20 response.
 
In these scenarios a key problem is that should the CoAP semantics = be=20 End-to-End or Hop-by-Hop when a C2C proxy is existed.
 
Regards,
 
Gengyu=20 WEI
Network Technology Center
School of Computer
Beijing = University of=20 Posts and Telecommunications
 
Sent: Sunday, April 30, 2017 12:24 PM
Cc: tsv-art@ietf.org ; Yoshifumi=20 Nishida ; draft-ietf-core-coa= p-tcp-tls@ietf.org=20 ; core@ietf.org ; ietf@ietf.org =
Subject: Re: [core] TSV-ART review of=20 draft-ietf-core-coap-tcp-tls-07
 
Hello,=20
As far as I've read -08 draft, I think this point has not been = addressed=20 yet. I hope some folks could elaborate a bit more if they think this is = not an=20 important point for the draft.
--
Yoshi
 
On Fri, Apr 21, 2017 at 2:57 PM, Brian Raymor = <Brian.Raymor@microsoft.com> wrote:

I think = that I=20 understand your perceptions better. Prior to adoption of coap-tcp-tls = and=20 before I was active in the WG, I recall discussions related to the = confusion=20 over application vs transport reliability in CoAP especially as = related to CON=20 and NON. What was intended?

 

Tim Carey = outlined=20 some concerns in:

https://tools.ietf.org/html/draft-carey-core-std-msg= -vs-trans-adapt-00#section-2

 

This = topic was=20 presented in detail at IETF 93 - https://www.ietf.org/proceedings/93/slides/slides-93= -core-0.pdf=20 - starting on slide 23.

 

And in a = related=20 thread on the mailing list back in 2015 - https://www.ietf.org/mail-archive/web/core/current/m= sg06280.html=20 - Carsten responded:

 

> In = any case,=20 CON and NON are about message layer semantics, not about application=20 semantics

> -- = you gave=20 them a meaning they don't have.

 

By IETF = 94, the=20 authors were reporting =E2=80=93 =E2=80=9CMost of the Confusion=20 = around           &= nbsp; =20 CON/NON was resolved=E2=80=9D.

 

Where = relevant,=20 I=E2=80=99ve added clarifications - such as the Appendix related to = differences in=20 Observe for reliable transports.

 

Both = Carsten and=20 Hannes could probably offer more context if = needed.

 

From: = Yoshifumi Nishida=20 [mailto:nishida@sfc.wide.ad.jp]
Sent: = Friday, April=20 21, 2017 2:08 PM
To: Brian Raymor <Brian.Raymor@microsoft.com>
Cc: = Yoshifumi=20 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:=20 Re: TSV-ART review of=20 draft-ietf-core-coap-tcp-tls-07

 

Hi Brian,

 

Just in case,

Reliable transports only provide reliability at = transport=20 level. It doesn't provide reliability in application protocol level.=20

 

RFC7252 has reliability mechanisms in it since it = uses UDP.=20 This means it has abilities to check both transport and app level=20 reliability.

This draft only provides transport level = reliability and=20 apps will need to detect app protocol failure by themselves.=20

This means 7252 and this draft are not totally = equivalent=20 from the viewpoint of applications.

 

I am not saying this is wrong or bad, but I = believe app=20 developer should aware this point.

--

Yoshi

 

On Fri, Apr 21, 2017 at 11:15 AM, Brian Raymor = <Brian.Raymor@microsoft.com> = wrote:

Hi=20 Yoshi,

 

>=20 OK. I also think we should state that the protocol should notify the = failure=20 events to applications.

>=20 Since errors can happen not only in TCP, but also TLS and websocket = level,=20 mentioning only TCP close or reset might not

>=20 be enough.

 

After=20 reviewing with the authors, an additional clarification was appended = to 3.4=20 Connection Health - https://github.com/core-wg/coap-tcp-tls/pull/140/fil= es

 

The=20 opinion of the authors (and Gengyu WEI=E2=80=99s recent response - = https://www.ietf.org/mail-archive/web/core/current/m= sg08622.html)=20 is that RFC6455 covers the WebSocket case and does not need to be = repeated=20 here.

 

>=20 When we use 7252, I think applications basically don't need to = implement=20 timeouts or retry mechanisms as the protocol

>=20 provides such things.

 

RFC7252=20 provides timeouts and retries because it's implementing a TCP-like=20 reliability mechanism over UDP - https://tools.ietf.org/html/rfc7252#section-2.1<= U>

 

>=20 However, when we use this one, it seems applications will need to = have such=20 mechanisms. Isn't it a bit confusing? I am thinking = that

>=20 there need to be some guidance here.

>=20 BTW, PONG is one example.

 

For=20 coap-tcp-tls, there are multiple early implementations. This has = never been=20 reported as a source of confusion.

 

>>=20 My sense is that we should treat this as an update to RFC7959 based = on the=20 original language:

>=20 I don't have a strong opinion here. Updating 7959 is fine for me if = it's=20 clearer to CoAP people.

 

I've=20 merged the change - https://github.com/core-wg/coap-tcp-tls/pull/138/fil= es

 

Thanks = again for=20 helping us to improve the quality of the = draft,

 

=E2=80=A6Brian

 

<= /DIV>
 

_______________________________________________
core mailing=20 list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
------=_NextPart_000_0018_01D2C348.6680E2B0-- From nobody Mon May 1 23:04:47 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D9D127241; Mon, 1 May 2017 23:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 YGyYAkrUqBNa; Mon, 1 May 2017 23:04:30 -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 8483E12944F; Mon, 1 May 2017 23:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v4261NeX011017; Tue, 2 May 2017 08:01:23 +0200 (CEST) Received: from [192.168.217.124] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (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 3wH9dt6zcNzDHJm; Tue, 2 May 2017 08:01:22 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann X-Priority: 3 In-Reply-To: Date: Tue, 2 May 2017 08:01:22 +0200 Cc: Yoshifumi Nishida , Brian Raymor , tsv-art@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org, ietf@ietf.org X-Mao-Original-Outgoing-Id: 515397682.389267-2ea9c47a5b4bedb8e9e5a58c0f6ad50b Content-Transfer-Encoding: quoted-printable Message-Id: <76EDF265-DC6F-41DE-B4F4-6BB7F948DC05@tzi.org> References: To: weigengyu X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Tsv-art] [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 06:04:32 -0000 On May 2, 2017, at 07:31, weigengyu wrote: >=20 > The problem is when the C2C Proxy have got a message form the CoAP/TCP = side,=20 > how the Proxy make a decision to delivery CON or NON message carrying = CoAP over UDP?=20 The question is not very different from the UDP to UDP proxying case. If a request came in via a UDP CON (which is the equivalent of using a = reliable transport protocol), should the proxy use CON or NON for the = forwarded request? I=E2=80=99d say, in both cases, CON should be the default way of = forwarding the reliable request. But there may be specific cases where a NON may be appropriate =E2=80=94 = CoAP does not provide the client with a way to control the proxy here. Is that a problem? Tell me more about your use case. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon May 1 23:14:36 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4653D126DFF for ; Mon, 1 May 2017 23:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.237 X-Spam-Level: * X-Spam-Status: No, score=1.237 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no 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 4idj_OYlYVok for ; Mon, 1 May 2017 23:14:27 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9BC129467 for ; Mon, 1 May 2017 23:11:37 -0700 (PDT) Received: from WeiGengyuPC (unknown [114.255.40.42]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id B08E519F380; Tue, 2 May 2017 14:11:34 +0800 (HKT) Message-ID: From: "weigengyu" To: "Carsten Bormann" Cc: "Yoshifumi Nishida" , "Brian Raymor" , , , , References: <76EDF265-DC6F-41DE-B4F4-6BB7F948DC05@tzi.org> In-Reply-To: <76EDF265-DC6F-41DE-B4F4-6BB7F948DC05@tzi.org> Date: Tue, 2 May 2017 14:11:33 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [Tsv-art] [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 06:14:28 -0000 Hi， > The question is not very different from the UDP to UDP proxying case. Something is different. > If a request came in via a UDP CON (which is the equivalent of using a > reliable transport protocol), > should the proxy use CON or NON for the forwarded request? If it keeps the semantics end-to-end, the proxy just forwards the message. If it has the semantics hop-by-hop, the proxy can decide what type of message to transfer. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Carsten Bormann Sent: Tuesday, May 02, 2017 2:01 PM To: weigengyu Cc: Yoshifumi Nishida ; Brian Raymor ; tsv-art@ietf.org ; draft-ietf-core-coap-tcp-tls@ietf.org ; core@ietf.org ; ietf@ietf.org Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 On May 2, 2017, at 07:31, weigengyu wrote: > > The problem is when the C2C Proxy have got a message form the CoAP/TCP > side, > how the Proxy make a decision to delivery CON or NON message carrying CoAP > over UDP? The question is not very different from the UDP to UDP proxying case. If a request came in via a UDP CON (which is the equivalent of using a reliable transport protocol), should the proxy use CON or NON for the forwarded request? I’d say, in both cases, CON should be the default way of forwarding the reliable request. But there may be specific cases where a NON may be appropriate — CoAP does not provide the client with a way to control the proxy here. Is that a problem? Tell me more about your use case. Grüße, Carsten From nobody Sat May 6 22:49:09 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06215126D73; Sat, 6 May 2017 22:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 7XuLe0mPvBF8; Sat, 6 May 2017 22:48:50 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57280126C25; Sat, 6 May 2017 22:48:49 -0700 (PDT) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2F4E829C87A; Sun, 7 May 2017 14:48:46 +0900 (JST) Received: by mail-oi0-f52.google.com with SMTP id w10so22692923oif.0; Sat, 06 May 2017 22:48:46 -0700 (PDT) X-Gm-Message-State: AN3rC/6MOFFxyEd6rZxayELgqHrYrxxPGiyoC0OeWB+FFogtOlz49oIl 6k3efAmegnfEloGT1lacFbWx5F6r7w== X-Received: by 10.157.55.163 with SMTP id x32mr18153638otb.72.1494136124712; Sat, 06 May 2017 22:48:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.4.55 with HTTP; Sat, 6 May 2017 22:48:44 -0700 (PDT) In-Reply-To: References: <76EDF265-DC6F-41DE-B4F4-6BB7F948DC05@tzi.org> From: Yoshifumi Nishida Date: Sat, 6 May 2017 22:48:44 -0700 X-Gmail-Original-Message-ID: Message-ID: To: weigengyu Cc: Carsten Bormann , Yoshifumi Nishida , Brian Raymor , tsv-art@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary=001a114095e8f5cd0e054ee8ac2b Archived-At: Subject: Re: [Tsv-art] [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 05:48:53 -0000 --001a114095e8f5cd0e054ee8ac2b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, May 1, 2017 at 11:11 PM, weigengyu wrote: > Hi=EF=BC=8C > > The question is not very different from the UDP to UDP proxying case. >> > Something is different. > > If a request came in via a UDP CON (which is the equivalent of using a >> reliable transport protocol), >> should the proxy use CON or NON for the forwarded request? >> > If it keeps the semantics end-to-end, the proxy just forwards the messag= e. > If it has the semantics hop-by-hop, the proxy can decide what type of > message to transfer. My interpretation for 5.2.3 in RFC7252 is CoAP layer can ignore the preference of applications and alter the message type by its decisions. It seems to me proxies can choose message types as they want. -- Yoshi > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Carsten Bormann > Sent: Tuesday, May 02, 2017 2:01 PM > To: weigengyu > Cc: Yoshifumi Nishida ; Brian Raymor ; tsv-art@ietf.org ; > draft-ietf-core-coap-tcp-tls@ietf.org ; core@ietf.org ; ietf@ietf.org > Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 > > On May 2, 2017, at 07:31, weigengyu wrote: > >> >> The problem is when the C2C Proxy have got a message form the CoAP/TCP >> side, >> how the Proxy make a decision to delivery CON or NON message carrying >> CoAP over UDP? >> > > The question is not very different from the UDP to UDP proxying case. > If a request came in via a UDP CON (which is the equivalent of using a > reliable transport protocol), should the proxy use CON or NON for the > forwarded request? > > I=E2=80=99d say, in both cases, CON should be the default way of forwardi= ng the > reliable request. > But there may be specific cases where a NON may be appropriate =E2=80=94 = CoAP does > not provide the client with a way to control the proxy here. > > Is that a problem? Tell me more about your use case. > > Gr=C3=BC=C3=9Fe, Carsten > > --001a114095e8f5cd0e054ee8ac2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, May 1, 2017 at 11:11 PM, weigengyu <weigengyu@bupt.edu.cn&= gt; wrote:
Hi=EF=BC=8C

The question is not very different from the UDP to UDP proxying case.
 Something is different.

If a request came in via a UDP CON (which is the equivalent of using a reli= able transport protocol),
should the proxy use CON or NON for the forwarded request?
 If it keeps the semantics end-to-end,=C2=A0 the proxy just forwards the mes= sage.
If it has the semantics hop-by-hop, the proxy can decide what type of messa= ge to transfer.

My interpretation for 5.2.3= in RFC7252 is CoAP layer can ignore the preference of applications and alt= er the message type by its decisions. It seems to me proxies can choose mes= sage types as they want.
--
Yoshi =C2=A0 =C2=A0





Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
 -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Carsten Bormann
Sent: Tuesday, May 02, 2017 2:01 PM
To: weigengyu
Cc: Yoshifumi Nishida ; Brian Raymor ; tsv-art@ietf.org ; draft-ietf-core-coap-tcp-tls@ietf.org ; core@ietf= .org ; ietf@ietf.org=
Subject: Re: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07<= br>
On May 2, 2017, at 07:31, weigengyu <weigengyu@bupt.edu.cn> wrote:

The problem is when the C2C Proxy have got a message form the CoAP/TCP side= ,
how the Proxy make a decision to delivery CON or NON message carrying CoAP = over UDP?

The question is not very different from the UDP to UDP proxying case.
If a request came in via a UDP CON (which is the equivalent of using a reli= able transport protocol), should the proxy use CON or NON for the forwarded= request?

I=E2=80=99d say, in both cases, CON should be the default way of forwarding= the reliable request.
But there may be specific cases where a NON may be appropriate =E2=80=94 Co= AP does not provide the client with a way to control the proxy here.

Is that a problem?=C2=A0 Tell me more about your use case.

Gr=C3=BC=C3=9Fe, Carsten


--001a114095e8f5cd0e054ee8ac2b-- From nobody Sun May 7 20:18:14 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4668112025C; Sun, 7 May 2017 20:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 WVbUQ80mJ8Ua; Sun, 7 May 2017 20:17:56 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC48F126CD6; Sun, 7 May 2017 20:17:56 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id p143so8559489yba.2; Sun, 07 May 2017 20:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RXrwk9tjsQVQVx3ZiCsrWvjUljNWtkOCV+vRd08ULJ0=; b=tkYl8Re/NymyBwUfn+Z+IKxeAZYFGUdoLLYxM8oXRNT3/ZL6pk9iVqwq27hJbQQQGX hBInDkiJuFf7d0gV2kzXf56NkufGuccX6cuM2bjApd7oLDqm9+DOTawjMdXchL38AXw+ Zm6tCNuiSOUrG3uaooDSy06oNAMduoviNAEu3xemcJdpMQ5QH47RnQpRs4FMge2QjrFV jv3DRPj5O7/Rl27x3oDRQX1FZnqhK6EiPIlk7+w/TX8UzPE/7wFsV3+xyORfGe1GSR/Y vgL16zNKy9veHkHlyUEB2ZS1BhbBD4YVhYsZhmr7pwJ5O7UwkvwPXISotexyU5UeIRju xUJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RXrwk9tjsQVQVx3ZiCsrWvjUljNWtkOCV+vRd08ULJ0=; b=Khig0Rvt208YQaKd3UqjM3dWeSVc/+OQeqmwzkXtzO0+CG+WLR+o70CoUw1cDtgSbX c1dztHpICgO6AEy74bLSXHB9egSfMqZNdOs9/yHZ27NvPPPml9owhg2NnJVTuJAZ5fNo Ew1GRVqvL/SdxcipIjhQydbreNCF1gzeOHpCgbvJV8Isn/05GATxJYZGnF95QKodkQUE 8bhN13pVN+LvIuQSKOnbjh6NOUptHsPO3PUbJ6v+GSTkh3kyXN9FxgM8vscwF5tvfoQM cwqk+9wF9/CNVIQIlo4O5XfB8uHLyhwVMZbGsWax+zgVooQywERUss3rOdRDU3R8ckJE KS3g== X-Gm-Message-State: AODbwcCIoxPfZqPsZcpo3q9t6D+R9Fe8byBc6cVkgcr6kHWPqq8n3ZjF A71kIvq5zmJxBAVz80nN4Lt2u5GsaQ== X-Received: by 10.37.177.32 with SMTP id g32mr8970365ybj.82.1494213475927; Sun, 07 May 2017 20:17:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.161.198 with HTTP; Sun, 7 May 2017 20:17:55 -0700 (PDT) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Sun, 7 May 2017 22:17:55 -0500 Message-ID: To: Yoshifumi Nishida Cc: Brian Raymor , "tsv-art@ietf.org" , "draft-ietf-core-coap-tcp-tls@ietf.org" , "core@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary=f403045e5564738dfc054efaafc2 Archived-At: Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 03:17:59 -0000 --f403045e5564738dfc054efaafc2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Yoshi, On Sat, Apr 29, 2017 at 11:24 PM, Yoshifumi Nishida 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 n= ot > 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 > 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 Co= AP >> 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 =E2=80=93 =E2=80=9CMost of the Co= nfusion >> around CON/NON was resolved=E2=80=9D. >> >> >> >> Where relevant, I=E2=80=99ve 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 >> *Cc:* Yoshifumi Nishida ; 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 i= t >> 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=E2=80=99s 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 o= n >> 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, >> >> >> >> =E2=80=A6Brian >> >> >> > > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art > > --f403045e5564738dfc054efaafc2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Yoshi,

On Sat, Apr 29, 2017 at 11:24 PM, Yoshifumi Nishida <nishid= a@sfc.wide.ad.jp> wrote:
Hello,
As far as I've read -08 draft, I think this p= oint has not been addressed yet. I hope some folks could elaborate a bit mo= re if they think this is not an important point for the draft.
<= /blockquote>

I've seen the subsequent e-mails in rep= ly to yours, but it's not obvious to me whether you think this point wa= s addressed after reading those e-mails.

What do y= ou think?

Thanks,

Spencer=
=C2=A0
--
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 reca= ll discussions related to the confusion over application vs transport reliability in CoAP especially as related to CON and NON. Wha= t was intended?

=C2=A0

Tim Carey outlined some concerns in:<= /span>

https://tools.i= etf.org/html/draft-carey-core-std-msg-vs-trans-adapt-00#section-2=

=C2=A0

This topic was presented in detail at IETF 93 - https://www.ietf.org/proceedings/93/slides/slides-9= 3-core-0.pdf - starting on slide 23.

=C2=A0

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:

=C2=A0

> In any case, CON and NON are about message lay= er semantics, not about application semantics

> -- you gave them a meaning they don't have= .

=C2=A0

By IETF 94, the authors were reporting =E2=80=93 = =E2=80=9CMost of the Confusion around=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CON/NON was resolved=E2=80=9D.

=C2=A0

Where relevant, I=E2=80=99ve added clarifications -= such as the Appendix related to differences in Observe for reliable transp= orts.

=C2=A0

Both Carsten and Hannes could probably offer more c= ontext if needed.

= =C2=A0

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<= u>

=C2=A0

Hi Brian,

=C2=A0

Just in case,

Reliable transports only provide reliability at tran= sport level. It doesn't provide reliability in application protocol lev= el.=C2=A0

=C2=A0

RFC7252 has reliability mechanisms in it since it us= es UDP. This means it has abilities to check both transport and app level r= eliability.

This draft only provides transport level reliability= and apps will need to detect app protocol failure by themselves.=C2=A0<= /u>

This means 7252 and this draft are not totally equiv= alent from the viewpoint of applications.=C2=A0

=C2=A0

I am not saying this is wrong or bad, but I believe = app developer should aware this point.

--

Yoshi

=C2=A0

On Fri, Apr 21, 2017 at 11:15 AM, Brian Raymor <<= a href=3D"mailto:Brian.Raymor@microsoft.com" target=3D"_blank">Brian.Raymor= @microsoft.com> wrote:

Hi Yoshi,

=C2=A0

> OK. I = also think we should state that the protocol should notify the failure even= ts to applications.=C2=A0

> Since = errors can happen not only in TCP, but also TLS and websocket level, mentio= ning only TCP close or reset might not

> be eno= ugh.

=C2=A0

After revie= wing with the authors, an additional clarification was appended to 3.4 Conn= ection Health - https://github.com/core-wg/coap-tcp-tls/pull/140/files

=C2=A0

The opinion= of the authors (and Gengyu WEI=E2=80=99s recent response - https://www.ietf.org/mail-archive/web/core/current/msg08622.html<= /a>) is that RFC6455 covers the WebSocket case and does not need to be repe= ated here.

=C2=A0

> When w= e use 7252, I think applications basically don't need to implement time= outs or retry mechanisms as the protocol

> provid= es such things.

=C2=A0

RFC7252 pro= vides timeouts and retries because it's implementing a TCP-like reliabi= lity mechanism over UDP - https://tools.ietf.org/html/rfc7252#section-2.1

=C2=A0

> Howeve= r, when we use this one, it seems applications will need to have such mecha= nisms. Isn't it a bit confusing? I am thinking that

> there = need to be some guidance here.

> BTW, P= ONG is one example.

=C2=A0

For coap-tc= p-tls, there are multiple early implementations. This has never been report= ed as a source of confusion.

=C2=A0

>> My= sense is that we should treat this as an update to RFC7959 based on the or= iginal language:

> I don&= #39;t have a strong opinion here. Updating 7959 is fine for me if it's = clearer to CoAP people.

=C2=A0

I've me= rged the change - https://github.com/core-wg/coap-tcp-tls/pull/138/files

=C2=A0

Thanks again for helping us to improve the quality = of the draft,

=C2=A0

=E2=80=A6Brian

=C2=A0



_______________________________________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art<= br>

--f403045e5564738dfc054efaafc2-- From nobody Sun May 7 21:52:35 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857031205F0 for ; Sun, 7 May 2017 21:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 LzNolU0-TJrY for ; Sun, 7 May 2017 21:52:23 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 22A35126CBF for ; Sun, 7 May 2017 21:52:22 -0700 (PDT) Received: from WeiGengyuPC (unknown [114.246.133.86]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 0815F19F382; Mon, 8 May 2017 12:52:21 +0800 (HKT) Message-ID: <08549A3D9D2643EA99EE576FBF1E8C29@WeiGengyuPC> From: "weigengyu" To: "Spencer Dawkins at IETF" , "Yoshifumi Nishida" Cc: , , , References: In-Reply-To: Date: Mon, 8 May 2017 12:52:20 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01D2C7F9.EE8C4540" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [Tsv-art] [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 04:52:27 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_0032_01D2C7F9.EE8C4540 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi,=20 A question related.=20 It needs clarifying the CoAP End-to-End Semancetics for the following = scenarios:=20 1. CoAP EP1/UDP ----> CoAP to CoAP Proxy ----> CoAP EP2/UDP 2. CoAP EP1/UDP ----> CoAP to CoAP Proxy ----> CoAP EP2/TCP The CoAP semantics including request/response and messages is defined in = RFC7252.=20 How the CoAP end-to-end semantics keep in a way among three cases.=20 The CoAP end-to-end semancetics is required to keep=20 (1) between CoAP EP1 and CoAP EP2,=20 (2) or between CoAP EP1 and C2C proxy, and between C2C Proxy and CoAP = EP2,=20 in another wors, the CoAP is hop-by-hop.=20 (3) or both (1) and (2). =20 For (1), the proxy needs just to forward the message what received.=20 For (2), the proxy needs to make a CoAP message by its decisions. For (3), the proxy needs to have functions of (1) and (2) and to = distinguish (1) from (2).=20 I wonder which is required? What needs to support? =20 Regards, Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications From: Spencer Dawkins at IETF=20 Sent: Monday, May 08, 2017 11:17 AM To: Yoshifumi Nishida=20 Cc: tsv-art@ietf.org ; draft-ietf-core-coap-tcp-tls@ietf.org ; = core@ietf.org ; ietf@ietf.org=20 Subject: Re: [core] [Tsv-art] TSV-ART review of = draft-ietf-core-coap-tcp-tls-07 Hi, Yoshi,=20 On Sat, Apr 29, 2017 at 11:24 PM, Yoshifumi Nishida = wrote: Hello,=20 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 = 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#se= ction-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.=20 By IETF 94, the authors were reporting =E2=80=93 =E2=80=9CMost of = the Confusion around CON/NON was resolved=E2=80=9D.=20 Where relevant, I=E2=80=99ve 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]=20 Sent: Friday, April 21, 2017 2:08 PM To: Brian Raymor Cc: Yoshifumi Nishida ; 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.=20 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.=20 This means 7252 and this draft are not totally equivalent from the = viewpoint of applications.=20 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 = wrote: Hi Yoshi, > OK. I also think we should state that the protocol should notify = the failure events to applications.=20 > Since errors can happen not only in TCP, but also TLS and = websocket level, mentioning only TCP close or reset might not=20 > 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=E2=80=99s 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.=20 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.=20 >> 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, =E2=80=A6Brian _______________________________________________ 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 ------=_NextPart_000_0032_01D2C7F9.EE8C4540 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
 
A question related.
It needs clarifying the CoAP End-to-End Semancetics for the = following=20 scenarios:
 
1. CoAP EP1/UDP  ----> CoAP to CoAP Proxy  ----> = CoAP=20 EP2/UDP
2. CoAP EP1/UDP  ----> CoAP to CoAP Proxy  ----> = CoAP=20 EP2/TCP
 
The CoAP semantics including request/response and messages is = defined in=20 RFC7252.
How the CoAP end-to-end semantics keep in a way among three cases. =
 
The CoAP end-to-end semancetics is required to keep
  (1) between CoAP EP1 and CoAP EP2,
  (2) or between CoAP EP1 and C2C proxy, and between C2C Proxy = and=20 CoAP EP2,
       in another wors, the CoAP is=20 hop-by-hop.
  (3) or both (1) and (2).  
 
For (1), the proxy needs just to forward the message what received. =
For (2), the proxy needs to make a CoAP message by its = decisions.
For (3), the proxy needs to have functions of (1) and (2) and to=20 distinguish (1) from (2).
 
I wonder which is required? What needs to support? 
 
Regards,
 
Gengyu=20 WEI
Network Technology Center
School of Computer
Beijing = University of=20 Posts and Telecommunications
 
From: Spencer Dawkins at = IETF
Sent: Monday, May 08, 2017 11:17 AM
Cc: tsv-art@ietf.org ; draft-ietf-core-coa= p-tcp-tls@ietf.org=20 ; core@ietf.org ; ietf@ietf.org =
Subject: Re: [core] [Tsv-art] TSV-ART review of=20 draft-ietf-core-coap-tcp-tls-07
 
Hi, Yoshi,=20
 
On Sat, Apr 29, 2017 at 11:24 PM, Yoshifumi = Nishida <nishida@sfc.wide.ad.jp> wrote:
Hello,=20
As far as I've read -08 draft, I think this point has not been = addressed=20 yet. I hope some folks could elaborate a bit more if they think this = is not an=20 important point for the draft.
 
I've seen the subsequent e-mails in reply to yours, but it's not = obvious to=20 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=20 understand your perceptions better. Prior to adoption of = coap-tcp-tls and=20 before I was active in the WG, I recall discussions related to the = confusion=20 over application vs transport reliability in CoAP especially as = related to=20 CON and NON. What was intended?

 

Tim = Carey=20 outlined some concerns in:

https://tools.ietf.org/html/draft-carey-core-std-msg= -vs-trans-adapt-00#section-2

 

This = topic was=20 presented in detail at IETF 93 - https://www.ietf.org/proceedings/93/slides/slides-93= -core-0.pdf=20 - starting on slide 23.

 

And in = a related=20 thread on the mailing list back in 2015 - https://www.ietf.org/mail-archive/web/core/current/m= sg06280.html=20 - Carsten responded:

 

> In = any case,=20 CON and NON are about message layer semantics, not about application = semantics

> -- = you gave=20 them a meaning they don't have.

 

By IETF = 94, the=20 authors were reporting =E2=80=93 =E2=80=9CMost of the Confusion=20 = around           &= nbsp; =20 CON/NON was resolved=E2=80=9D.

 

Where = relevant,=20 I=E2=80=99ve added clarifications - such as the Appendix related to = differences in=20 Observe for reliable transports.

 

Both = Carsten and=20 Hannes could probably offer more context if = needed.

 

From: = Yoshifumi=20 Nishida [mailto:nishida@sfc.wide.ad.jp]
Sent: = Friday,=20 April 21, 2017 2:08 PM
To: Brian Raymor <Brian.Raymor@microsoft.com>
Cc: = Yoshifumi=20 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=20 draft-ietf-core-coap-tcp-tls-07

 

Hi Brian,

 

Just in case,

Reliable transports only provide reliability at = transport=20 level. It doesn't provide reliability in application protocol level. =

 

RFC7252 has reliability mechanisms in it since = it uses=20 UDP. This means it has abilities to check both transport and app = level=20 reliability.

This draft only provides transport level = reliability and=20 apps will need to detect app protocol failure by themselves.=20

This means 7252 and this draft are not totally = equivalent=20 from the viewpoint of applications.

 

I am not saying this is wrong or bad, but I = believe app=20 developer should aware this point.

--

Yoshi

 

On Fri, Apr 21, 2017 at 11:15 AM, Brian Raymor = <Brian.Raymor@microsoft.com> = wrote:

Hi=20 Yoshi,

 

>=20 OK. I also think we should state that the protocol should notify = the=20 failure events to applications.

>=20 Since errors can happen not only in TCP, but also TLS and = websocket level,=20 mentioning only TCP close or reset might not

>=20 be enough.

 

After=20 reviewing with the authors, an additional clarification was = appended to=20 3.4 Connection Health - https://github.com/core-wg/coap-tcp-tls/pull/140/fil= es

 

The=20 opinion of the authors (and Gengyu WEI=E2=80=99s recent response - = https://www.ietf.org/mail-archive/web/core/current/m= sg08622.html)=20 is that RFC6455 covers the WebSocket case and does not need to be = repeated=20 here.

 

>=20 When we use 7252, I think applications basically don't need to = implement=20 timeouts or retry mechanisms as the protocol

>=20 provides such things.

 

RFC7252=20 provides timeouts and retries because it's implementing a TCP-like = reliability mechanism over UDP - https://tools.ietf.org/html/rfc7252#section-2.1<= U>

 

>=20 However, when we use this one, it seems applications will need to = have=20 such mechanisms. Isn't it a bit confusing? I am thinking=20 that

>=20 there need to be some guidance here.

>=20 BTW, PONG is one example.

 

For=20 coap-tcp-tls, there are multiple early implementations. This has = never=20 been reported as a source of confusion.

 

>>=20 My sense is that we should treat this as an update to RFC7959 = based on the=20 original language:

>=20 I don't have a strong opinion here. Updating 7959 is fine for me = if it's=20 clearer to CoAP people.

 

I've=20 merged the change - https://github.com/core-wg/coap-tcp-tls/pull/138/fil= es

 

Thanks again=20 for helping us to improve the quality of the=20 draft,

 

=E2=80=A6Brian

 

<= /DIV>
=
 

_______________________________________________
Tsv-art=20 mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art
 

_______________________________________________
core mailing=20 list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
------=_NextPart_000_0032_01D2C7F9.EE8C4540-- From nobody Mon May 8 00:31:35 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@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\)) From: Carsten Bormann In-Reply-To: Date: Mon, 8 May 2017 09:31:00 +0200 Cc: Yoshifumi Nishida , "tsv-art@ietf.org" , "draft-ietf-core-coap-tcp-tls@ietf.org" , "core@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: To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Tsv-art] [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 07:31:14 -0000 Hi Spencer,=20 I=E2=80=99m 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=C3=BC=C3=9Fe, Carsten > On May 8, 2017, at 05:17, Spencer Dawkins at IETF = wrote: >=20 > Hi, Yoshi, >=20 > On Sat, Apr 29, 2017 at 11:24 PM, Yoshifumi Nishida = 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. >=20 > 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. >=20 > What do you think? >=20 > Thanks, >=20 > Spencer > =20 > -- > Yoshi >=20 > On Fri, Apr 21, 2017 at 2:57 PM, Brian Raymor = 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? >=20 > =20 >=20 > Tim Carey outlined some concerns in: >=20 > = https://tools.ietf.org/html/draft-carey-core-std-msg-vs-trans-adapt-00#sec= tion-2 >=20 > =20 >=20 > 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. >=20 > =20 >=20 > 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: >=20 > =20 >=20 > > In any case, CON and NON are about message layer semantics, not = about application semantics >=20 > > -- you gave them a meaning they don't have. >=20 > =20 >=20 > By IETF 94, the authors were reporting =E2=80=93 =E2=80=9CMost of the = Confusion around CON/NON was resolved=E2=80=9D. >=20 > =20 >=20 > Where relevant, I=E2=80=99ve added clarifications - such as the = Appendix related to differences in Observe for reliable transports. >=20 > =20 >=20 > Both Carsten and Hannes could probably offer more context if needed. >=20 > =20 >=20 > From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp]=20 > Sent: Friday, April 21, 2017 2:08 PM > To: Brian Raymor > Cc: Yoshifumi Nishida ; 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 >=20 > =20 >=20 > Hi Brian, >=20 > =20 >=20 > Just in case, >=20 > Reliable transports only provide reliability at transport level. It = doesn't provide reliability in application protocol level.=20 >=20 > =20 >=20 > RFC7252 has reliability mechanisms in it since it uses UDP. This means = it has abilities to check both transport and app level reliability. >=20 > This draft only provides transport level reliability and apps will = need to detect app protocol failure by themselves.=20 >=20 > This means 7252 and this draft are not totally equivalent from the = viewpoint of applications.=20 >=20 > =20 >=20 > I am not saying this is wrong or bad, but I believe app developer = should aware this point. >=20 > -- >=20 > Yoshi >=20 > =20 >=20 > On Fri, Apr 21, 2017 at 11:15 AM, Brian Raymor = wrote: >=20 > Hi Yoshi, >=20 > =20 >=20 > > OK. I also think we should state that the protocol should notify the = failure events to applications.=20 >=20 > > Since errors can happen not only in TCP, but also TLS and websocket = level, mentioning only TCP close or reset might not >=20 > > be enough. >=20 > =20 >=20 > 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 >=20 > =20 >=20 > The opinion of the authors (and Gengyu WEI=E2=80=99s 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. >=20 > =20 >=20 > > When we use 7252, I think applications basically don't need to = implement timeouts or retry mechanisms as the protocol >=20 > > provides such things.=20 >=20 > =20 >=20 > 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 >=20 > =20 >=20 > > 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 >=20 > > there need to be some guidance here. >=20 > > BTW, PONG is one example. >=20 > =20 >=20 > For coap-tcp-tls, there are multiple early implementations. This has = never been reported as a source of confusion. >=20 > =20 >=20 > >> My sense is that we should treat this as an update to RFC7959 based = on the original language: >=20 > > I don't have a strong opinion here. Updating 7959 is fine for me if = it's clearer to CoAP people. >=20 > =20 >=20 > I've merged the change - = https://github.com/core-wg/coap-tcp-tls/pull/138/files >=20 > =20 >=20 > Thanks again for helping us to improve the quality of the draft, >=20 > =20 >=20 > =E2=80=A6Brian >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon May 8 00:48:56 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FA6120724; Mon, 8 May 2017 00:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 pXjefL2CpjAs; Mon, 8 May 2017 00:48:50 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924EB1200C1; Mon, 8 May 2017 00:48:50 -0700 (PDT) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 9B4AB29CD87; Mon, 8 May 2017 16:48:47 +0900 (JST) Received: by mail-oi0-f49.google.com with SMTP id b204so41445558oii.1; Mon, 08 May 2017 00:48:47 -0700 (PDT) X-Gm-Message-State: AN3rC/4HAnIyCgJbKJcGZJtmk7S5g5AFtRKistuTTpqWqXW6FqvjjKSf Ko3VCg8D/C5kWFKuNHtX1M442V+YmA== X-Received: by 10.202.91.214 with SMTP id p205mr20485392oib.216.1494229726232; Mon, 08 May 2017 00:48:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.4.55 with HTTP; Mon, 8 May 2017 00:48:45 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Mon, 8 May 2017 00:48:45 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Spencer Dawkins at IETF Cc: Yoshifumi Nishida , Brian Raymor , "tsv-art@ietf.org" , "draft-ietf-core-coap-tcp-tls@ietf.org" , "core@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary=001a113d551c0b88f1054efe7898 Archived-At: Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 07:48:54 -0000 --001a113d551c0b88f1054efe7898 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Spencer, I still expect to see some more comments on this point (my review point 2:) I basically would like to see more explanations about how to avoid protocol deadlock or some clarifications that this won't be an issue. -- Yoshi On Sun, May 7, 2017 at 8:17 PM, 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 > > 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 C= oAP >>> 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 =E2=80=93 =E2=80=9CMost of the C= onfusion >>> around CON/NON was resolved=E2=80=9D. >>> >>> >>> >>> Where relevant, I=E2=80=99ve added clarifications - such as the Appendi= x 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 >>> *Cc:* Yoshifumi Nishida ; 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 shoul= d >>> 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=E2=80=99s 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/r= f >>> c7252#section-2.1 >>> >>> >>> >>> > However, when we use this one, it seems applications will need to hav= e >>> 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, >>> >>> >>> >>> =E2=80=A6Brian >>> >>> >>> >> >> >> _______________________________________________ >> Tsv-art mailing list >> Tsv-art@ietf.org >> https://www.ietf.org/mailman/listinfo/tsv-art >> >> > --001a113d551c0b88f1054efe7898 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Spencer,

I still expect to see some = more comments on this point (my review point 2:)
I basically woul= d like to see more explanations about how to avoid protocol deadlock or som= e clarifications that this won't be an issue.
--
Yo= shi

On = Sun, May 7, 2017 at 8:17 PM, Spencer Dawkins at IETF <= spencerd= awkins.ietf@gmail.com> wrote:
Hi, Yoshi,

On Sat, Apr 29, 2017 at 11:24 PM, Yoshifumi N= ishida <nishida@sfc.wide.ad.jp> wrote:
Hello,
As far as I've read -08 d= raft, I think this point has not been addressed yet. I hope some folks coul= d elaborate a bit more if they think this is not an important point for the= draft.

I've seen th= e subsequent e-mails in reply to yours, but it's not obvious to me whet= her you think this point was addressed after reading those e-mails.

What do you think?

Thanks,
=

Spencer
=C2=A0
--
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 reca= ll discussions related to the confusion over application vs transport reliability in CoAP especially as related to CON and NON. Wha= t was intended?

=C2=A0

Tim Carey outlined some concerns in:<= /span>

https://tools.i= etf.org/html/draft-carey-core-std-msg-vs-trans-adapt-00#section-2=

=C2=A0

This topic was presented in detail at IETF 93 - https://www.ietf.org/proceedings/93/slides/slides-9= 3-core-0.pdf - starting on slide 23.

=C2=A0

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:

=C2=A0

> In any case, CON and NON are about message lay= er semantics, not about application semantics

> -- you gave them a meaning they don't have= .

=C2=A0

By IETF 94, the authors were reporting =E2=80=93 = =E2=80=9CMost of the Confusion around=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CON/NON was resolved=E2=80=9D.

=C2=A0

Where relevant, I=E2=80=99ve added clarifications -= such as the Appendix related to differences in Observe for reliable transp= orts.

=C2=A0

Both Carsten and Hannes could probably offer more c= ontext if needed.

=C2=A0

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<= u>

<= div class=3D"m_-2388476382627849178m_-7965682870498344231m_-185370657942848= 524m_7105224061284585916h5">

=C2=A0

Hi Brian,

=C2=A0

Just in case,

Reliable transports only provide reliability at tran= sport level. It doesn't provide reliability in application protocol lev= el.=C2=A0

=C2=A0

RFC7252 has reliability mechanisms in it since it us= es UDP. This means it has abilities to check both transport and app level r= eliability.

This draft only provides transport level reliability= and apps will need to detect app protocol failure by themselves.=C2=A0<= /u>

This means 7252 and this draft are not totally equiv= alent from the viewpoint of applications.=C2=A0

=C2=A0

I am not saying this is wrong or bad, but I believe = app developer should aware this point.

--

Yoshi

=C2=A0

On Fri, Apr 21, 2017 at 11:15 AM, Brian Raymor <<= a href=3D"mailto:Brian.Raymor@microsoft.com" target=3D"_blank">Brian.Raymor= @microsoft.com> wrote:

Hi Yoshi,

=C2=A0

> OK. I also think we should state that the protocol should n= otify the failure events to applications.=C2=A0

> Since errors can happen not only in TCP, but also TLS and w= ebsocket level, mentioning only TCP close or reset might not

> be enough.

=C2=A0

After reviewing with the authors, an additional clarification wa= s appended to 3.4 Connection Health - https://github.com/core-wg/coap-tcp-tls/pull/140/files

=C2=A0

The opinion of the authors (and Gengyu WEI=E2=80=99s recent resp= onse - https://www.ietf.org/mail-archive/web/core/current/msg08622.html<= /a>) is that RFC6455 covers the WebSocket case and does not need to be repe= ated here.

=C2=A0

> When we use 7252, I think applications basically don't = need to implement timeouts or retry mechanisms as the protocol

> provides such things.

=C2=A0

RFC7252 provides timeouts and retries because it's implement= ing a TCP-like reliability mechanism over UDP - https://tools.ietf.org/html/rfc7252#section-2.1

=C2=A0

> However, when we use this one, it seems applications will n= eed to have such mechanisms. Isn't it a bit confusing? I am thinking th= at

> there need to be some guidance here.

> BTW, PONG is one example.

=C2=A0

For coap-tcp-tls, there are multiple early implementations. This= has never been reported as a source of confusion.

=C2=A0

>> My sense is that we should treat this as an update to R= FC7959 based on the original language:

> I don't have a strong opinion here. Updating 7959 is fi= ne for me if it's clearer to CoAP people.

=C2=A0

I've merged the change - https://github.com/core-wg/coap-tcp-tls/pull/138/files

=C2=A0

Thanks again for helping us to improve the quality = of the draft,

=C2=A0

=E2=80=A6Brian

=C2=A0



_____________________________________= __________
Tsv-art mailing list
Tsv-art@ietf.org<= br> https://www.ietf.org/mailman/listinfo/tsv-art<= br>


--001a113d551c0b88f1054efe7898-- From nobody Mon May 8 00:49:44 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B3A120724; Mon, 8 May 2017 00:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 N0D_dl3i6jgI; Mon, 8 May 2017 00:49:13 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A126F1293E1; Mon, 8 May 2017 00:49:09 -0700 (PDT) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E67E729CD95; Mon, 8 May 2017 16:49:07 +0900 (JST) Received: by mail-oi0-f51.google.com with SMTP id b204so41452538oii.1; Mon, 08 May 2017 00:49:07 -0700 (PDT) X-Gm-Message-State: AN3rC/4+48eTdK132t8p//hRWfZFPE3yVQsVEvpzkOyPEmTkapWImpYf IwkVha6XiMVsEih98fdLpbUyL+P/Lw== X-Received: by 10.157.17.29 with SMTP id g29mr12212497ote.86.1494229746695; Mon, 08 May 2017 00:49:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.4.55 with HTTP; Mon, 8 May 2017 00:49:05 -0700 (PDT) In-Reply-To: <4F24893A-C088-45EB-97CE-126231933918@tzi.org> References: <4F24893A-C088-45EB-97CE-126231933918@tzi.org> From: Yoshifumi Nishida Date: Mon, 8 May 2017 00:49:05 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Carsten Bormann Cc: Spencer Dawkins at IETF , "tsv-art@ietf.org" , Yoshifumi Nishida , "draft-ietf-core-coap-tcp-tls@ietf.org" , "core@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary=001a1141dfb043d382054efe7925 Archived-At: Subject: Re: [Tsv-art] [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 07:49:26 -0000 --001a1141dfb043d382054efe7925 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 wrote: > Hi Spencer, > > I=E2=80=99m not Yoshi :-), but I just have started working on an update o= f > 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 th= e > CoAP application as a result of moving some of the transport functionalit= y > into TCP. > > Gr=C3=BC=C3=9Fe, 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 addresse= d > yet. I hope some folks could elaborate a bit more if they think this is n= ot > an important point for the draft. > > > > I've seen the subsequent e-mails in reply to yours, but it's not obviou= s > 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 CoA= P > 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 =E2=80=93 =E2=80=9CMost of the C= onfusion around > CON/NON was resolved=E2=80=9D. > > > > > > > > Where relevant, I=E2=80=99ve added clarifications - such as the Appendi= x 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 > > Cc: Yoshifumi Nishida ; 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 shoul= d > 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=E2=80=99s 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 hav= e > 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, > > > > > > > > =E2=80=A6Brian > > > > > > > > > > > > _______________________________________________ > > 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 > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art > --001a1141dfb043d382054efe7925 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carsten,

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

On Mon, May 8, 2017 at 12:31 AM, Carsten Bormann <= ;cabo@tzi.org> wrote:
Hi Spencer,

I=E2=80=99m not Yoshi :-), but I just have started working on an update of<= br> https://lwig-wg.github.io/coap/#rfc.section.6<= br> 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 acknowledgeme= nt beyond the request-response acknowledgement semantics by introducing the= custody option of the PING/PONG signaling messages.=C2=A0 This may be usef= ul in compensating the decrease of information available to the CoAP applic= ation as a result of moving some of the transport functionality into TCP.
Gr=C3=BC=C3=9Fe, 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 add= ressed 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 n= ot obvious to me whether you think this point was addressed after reading t= hose 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 o= f coap-tcp-tls and before I was active in the WG, I recall discussions rela= ted to the confusion over application vs transport reliability in CoAP espe= cially as related to CON and NON. What was intended?
>
>
>
> Tim Carey outlined some concerns in:
>
> https://tools.i= etf.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 a= bout application semantics
>
> > -- you gave them a meaning they don't have.
>
>
>
> By IETF 94, the authors were reporting =E2=80=93 =E2=80=9CMost of the = Confusion around=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CON/NON wa= s resolved=E2=80=9D.
>
>
>
> Where relevant, I=E2=80=99ve added clarifications - such as the Append= ix 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 <Bri= an.Raymor@microsoft.com>
> Cc: Yoshifumi Nishida <ni= shida@sfc.wide.ad.jp>; tsv-art@i= etf.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 do= esn'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 nee= d to detect app protocol failure by themselves.
>
> This means 7252 and this draft are not totally equivalent from the vie= wpoint of applications.
>
>
>
> I am not saying this is wrong or bad, but I believe app developer shou= ld 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 websock= et level, mentioning only TCP close or reset might not
>
> > be enough.
>
>
>
> After reviewing with the authors, an additional clarification was appe= nded to 3.4 Connection Health - https://github= .com/core-wg/coap-tcp-tls/pull/140/files
>
>
>
> The opinion of the authors (and Gengyu WEI=E2=80=99s recent response -= https://www.ietf.org/mail-arch= ive/web/core/current/msg08622.html) is that RFC6455 covers the Web= Socket case and does not need to be repeated here.
>
>
>
> > When we use 7252, I think applications basically don't need t= o 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://too= ls.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 n= ever 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://gith= ub.com/core-wg/coap-tcp-tls/pull/138/files
>
>
>
> Thanks again for helping us to improve the quality of the draft,
>
>
>
> =E2=80=A6Brian
>
>
>
>
>
> _______________________________________________
> 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
____________________________= ___________________
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art<= br>

--001a1141dfb043d382054efe7925-- From nobody Mon May 8 02:39:24 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3F4129413 for ; Mon, 8 May 2017 02:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 oiM6ncP0RHKD for ; Mon, 8 May 2017 02:39:18 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3F3128C84 for ; Mon, 8 May 2017 02:39:18 -0700 (PDT) Received: from WeiGengyuPC (unknown [114.246.133.86]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id CD78719F374; Mon, 8 May 2017 17:39:16 +0800 (HKT) Message-ID: <8CB7E4B806F74B8294BA4441076E8EE0@WeiGengyuPC> From: "weigengyu" To: "Yoshifumi Nishida" , "Carsten Bormann" Cc: , "Yoshifumi Nishida" , , "Spencer Dawkins at IETF" , , References: <4F24893A-C088-45EB-97CE-126231933918@tzi.org> In-Reply-To: Date: Mon, 8 May 2017 17:39:16 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01D2C822.03E94C30" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [Tsv-art] [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 09:39:22 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_0031_01D2C822.03E94C30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi,=20 The clairification raised is my question.=20 We did implement the protocol as the senarios described. The problems were we met, not be thought out.=20 I wish there will be an answer.=20 Regards,=20 Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications From: Yoshifumi Nishida=20 Sent: Monday, May 08, 2017 3:49 PM To: Carsten Bormann=20 Cc: ietf@ietf.org ; Yoshifumi Nishida ; = draft-ietf-core-coap-tcp-tls@ietf.org ; Spencer Dawkins at IETF ; = core@ietf.org ; tsv-art@ietf.org=20 Subject: Re: [core] [Tsv-art] TSV-ART review of = draft-ietf-core-coap-tcp-tls-07 Hi Carsten,=20 Great. I will take a look at it when it's published. Thanks for the efforts! -- Yoshi=20 On Mon, May 8, 2017 at 12:31 AM, Carsten Bormann wrote: Hi Spencer, I=E2=80=99m 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=C3=BC=C3=9Fe, Carsten > On May 8, 2017, at 05:17, Spencer Dawkins at IETF = wrote: > > Hi, Yoshi, > > On Sat, Apr 29, 2017 at 11:24 PM, Yoshifumi Nishida = 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 = 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#se= ction-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 =E2=80=93 =E2=80=9CMost of = the Confusion around CON/NON was resolved=E2=80=9D. > > > > Where relevant, I=E2=80=99ve 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 > Cc: Yoshifumi Nishida ; 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 = 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=E2=80=99s 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, > > > > =E2=80=A6Brian > > > > > > _______________________________________________ > 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 _______________________________________________ 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 ------=_NextPart_000_0031_01D2C822.03E94C30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
 
The clairification raised is my question.
 
We did implement the protocol as the senarios described.
The problems were we met, not be thought out.
 
I wish there will be an answer.
 
Regards,
 
Gengyu=20 WEI
Network Technology Center
School of Computer
Beijing = University of=20 Posts and Telecommunications
 
Sent: Monday, May 08, 2017 3:49 PM
Cc: ietf@ietf.org ; Yoshifumi Nishida ; draft-ietf-core-coa= p-tcp-tls@ietf.org=20 ; Spencer Dawkins at = IETF ; core@ietf.org ; = tsv-art@ietf.org=20
Subject: Re: [core] [Tsv-art] TSV-ART review of=20 draft-ietf-core-coap-tcp-tls-07
 
Hi Carsten,=20
 
Great. I will take a look at it when it's published.
Thanks for the efforts!
--
Yoshi=20
 
On Mon, May 8, 2017 at 12:31 AM, Carsten = Bormann <cabo@tzi.org> wrote:
Hi=20 Spencer,

I=E2=80=99m not Yoshi :-), but I just have started = working on an=20 update of
https://lwig-wg.github.io/coap/#rfc.section.6with=20 some of the new information that relates to CoAP over reliable; I hope = that I=20 will be able to push this during this week.

Note that CoAP over = TCP/TLS/WS does address application layer acknowledgement beyond the=20 request-response acknowledgement semantics by introducing the custody = option=20 of the PING/PONG signaling messages.  This may be useful in = compensating=20 the decrease of information available to the CoAP application as a = result of=20 moving some of the transport functionality into = TCP.

Gr=C3=BC=C3=9Fe, Carsten



> On May 8, 2017, at 05:17, Spencer = Dawkins at=20 IETF <spencerdawkins.ietf@gmail.c= om>=20 wrote:
>
> Hi, Yoshi,
>
> On Sat, Apr 29, 2017 = at=20 11:24 PM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp>=20 wrote:
> Hello,
> As far as I've read -08 draft, I think = this=20 point has not been addressed yet. I hope some folks could elaborate a = bit more=20 if they think this is not an important point for the = draft.
>
>=20 I've seen the subsequent e-mails in reply to yours, but it's not = obvious to me=20 whether you think this point was addressed after reading those=20 e-mails.
>
> What do you think?
>
>=20 Thanks,
>
> Spencer
>
> --
>=20 Yoshi
>
> On Fri, Apr 21, 2017 at 2:57 PM, Brian Raymor = <Brian.Raymor@microsoft.com= >=20 wrote:
> I think that I understand your perceptions better. = Prior to=20 adoption of coap-tcp-tls and before I was active in the WG, I recall=20 discussions related to the confusion over application vs transport = reliability=20 in CoAP especially as related to CON and NON. What was=20 intended?
>
>
>
> Tim Carey outlined some = concerns=20 in:
>
> https://tools.ietf.org/html/draft-carey-core-std-msg= -vs-trans-adapt-00#section-2
>
>
>
>=20 This topic was presented in detail at IETF 93 - https://www.ietf.org/proceedings/93/slides/slides-93-core-0.pdf=20 - starting on slide 23.
>
>
>
> And in a = related=20 thread on the mailing list back in 2015 - https://www.ietf.org/mail-archive/web/core/current/<= WBR>msg06280.html=20 - Carsten responded:
>
>
>
> > In any case, = CON and=20 NON are about message layer semantics, not about application=20 semantics
>
> > -- you gave them a meaning they don't=20 have.
>
>
>
> By IETF 94, the authors were = reporting =E2=80=93=20 =E2=80=9CMost of the Confusion=20 = around           &= nbsp; =20 CON/NON was resolved=E2=80=9D.
>
>
>
> Where = relevant, I=E2=80=99ve=20 added clarifications - such as the Appendix related to differences in = Observe=20 for reliable transports.
>
>
>
> Both Carsten = and=20 Hannes could probably offer more context if=20 needed.
>
>
>
> From: Yoshifumi Nishida = [mailto:nishida@sfc.wide.ad.jp]>=20 Sent: Friday, April 21, 2017 2:08 PM
> To: Brian Raymor <Brian.Raymor@microsoft.com= >
>=20 Cc: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>; = tsv-art@ietf.org; draft-ietf-core-coa= p-tcp-tls@ietf.org;=20 core@ietf.org; ietf@ietf.org
> Subject: Re: = TSV-ART=20 review of = draft-ietf-core-coap-tcp-tls-07
>
>
>
>=20 Hi Brian,
>
>
>
> Just in = case,
>
>=20 Reliable transports only provide reliability at transport level. It = doesn't=20 provide reliability in application protocol=20 level.
>
>
>
> RFC7252 has reliability = mechanisms in=20 it since it uses UDP. This means it has abilities to check both = transport and=20 app level reliability.
>
> This draft only provides = transport=20 level reliability and apps will need to detect app protocol failure by = themselves.
>
> This means 7252 and this draft are not = totally=20 equivalent from the viewpoint of = applications.
>
>
>
>=20 I am not saying this is wrong or bad, but I believe app developer = should aware=20 this point.
>
> --
>
>=20 Yoshi
>
>
>
> On Fri, Apr 21, 2017 at 11:15 = AM, Brian=20 Raymor <Brian.Raymor@microsoft.com= >=20 wrote:
>
> Hi Yoshi,
>
>
>
> > = OK. I=20 also think we should state that the protocol should notify the failure = events=20 to applications.
>
> > Since errors can happen not only = in TCP,=20 but also TLS and websocket level, mentioning only TCP close or reset = might=20 not
>
> > be enough.
>
>
>
> = After=20 reviewing with the authors, an additional clarification was appended = to 3.4=20 Connection Health - https://github.com/core-wg/coap-tcp-tls/pull/140/fil= es
>
>
>
>=20 The opinion of the authors (and Gengyu WEI=E2=80=99s recent response - = https://www.ietf.org/mail-archive/web/core/current/<= WBR>msg08622.html)=20 is that RFC6455 covers the WebSocket case and does not need to be = repeated=20 here.
>
>
>
> > When we use 7252, I think=20 applications basically don't need to implement timeouts or retry = mechanisms as=20 the protocol
>
> > provides such=20 things.
>
>
>
> RFC7252 provides timeouts and = retries=20 because it's implementing a TCP-like reliability mechanism over UDP - = https://tools.ietf.org/html/rfc7252#section-2.1<= BR>>
>
>
>=20 > However, when we use this one, it seems applications will need to = have=20 such mechanisms. Isn't it a bit confusing? I am thinking = that
>
>=20 > there need to be some guidance here.
>
> > BTW, = PONG is=20 one example.
>
>
>
> For coap-tcp-tls, there = are=20 multiple early implementations. This has never been reported as a = source of=20 confusion.
>
>
>
> >> My sense is that = we should=20 treat this as an update to RFC7959 based on the original=20 language:
>
> > I don't have a strong opinion here. = Updating=20 7959 is fine for me if it's clearer to CoAP=20 people.
>
>
>
> I've merged the change - https://github.com/core-wg/coap-tcp-tls/pull/138/fil= es
>
>
>
>=20 Thanks again for helping us to improve the quality of the=20 draft,
>
>
>
>=20 =E2=80=A6Brian
>
>
>
>
>
>=20 _______________________________________________
> Tsv-art = mailing=20 list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art>
>
>=20 _______________________________________________
> core = mailing=20 list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
_______________________________________________
Tsv-ar= t=20 mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art
 

_______________________________________________
core mailing=20 list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
------=_NextPart_000_0031_01D2C822.03E94C30-- From nobody Mon May 8 08:50:03 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0C8127275 for ; Mon, 8 May 2017 08:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 b6JWQlK_SFp9 for ; Mon, 8 May 2017 08:50:00 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CCAF126B6E for ; Mon, 8 May 2017 08:50:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=bgT0uzBl05UxVECchfwDHoTvG3HZsOOTh5izaSXETlQR3LRsG0De/GLVM1A0Fk/rxhqy10Di+VZHXgh8ZJqRv59cf/OPjLo5l3eksuw7fTpyhrdBvDScAKObe189DlpyywEtLYDsc3x0+iLA2ywFS7rXwfCbtvej7cs16lQB4w8=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 11620 invoked from network); 8 May 2017 17:49:57 +0200 Received: from p5dec259c.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.37.156) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 8 May 2017 17:49:57 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <48bfa3a1-e53c-6b31-69b0-2645ddd5937f@isi.edu> Date: Mon, 8 May 2017 17:49:56 +0200 Cc: "tsv-art@ietf.org" , Spencer Dawkins at IETF Content-Transfer-Encoding: quoted-printable Message-Id: <5AB999EB-EB4D-46D0-A9B8-20B0E1817896@kuehlewind.net> References: <48bfa3a1-e53c-6b31-69b0-2645ddd5937f@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170508154957.11614.64833@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Tsv-art] TSV-ART Telechat review of draft-ietf-6man-rfc1981bis-04 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 15:50:02 -0000 Hi Joe, given I=E2=80=99ve seen no additional discussion on this thread, did you = check/can you check if the latest version (-06) addresses your comments? Thanks! Mirja > Am 15.02.2017 um 22:51 schrieb Joe Touch : >=20 > Document: draft-ietf-6man-rfc1981bis-04 > Reviewer: Joe Touch > Review Date: February 15, 2017 > IETF LC End Date: March 3, 2017 > IESG Telechat date: February 28, 2017 >=20 > Review result: significant issues >=20 > NOTE: some of this review is informed by tracking some of the issues = raised by others on the IETF list, notably Gorry Fairhurst. >=20 > Major issues: >=20 > 1) the current text is insufficiently realistic about the (in)ability = of this mechanism to operate in current networks, regardless of the = support for generating ICMPs at routers or PMTUD support at endpoints, = due to ICMP filtering for security reasons. [this comment is already = being addressed by consensus text] >=20 > 2) the current text is insufficiently clear on on the difference = between the path MTU, which determines the largest supported IPv6 = fragment, vs. the effective MTU to receive (EMTU_R), which determines = the largest IP packet that can transit between the source and = destination. The document should be more explicit throughput about its = goal being to manage or avoid IPv6 source fragmentation rather than = about source to destination packet maximums, and in specific in clearly = referring to maximum fragments or atomic packets rather than maximum = packets. >=20 > E.g.: see the following text, which is incorrect in its current form: > Nodes not implementing Path MTU Discovery use the IPv6 minimum link > MTU defined in [ > I-D.ietf-6man-rfc2460bis > ] as the maximum packet size. >=20 > The value used by either Path MTU Discovery or its default represents = the path MTU, which is the largest IPv6 *fragment* (or atomic packet, = see RFC6864) that can be supported on the path between the endpoints. = The maximum IP packet size is limited by the effective MTU to receive = (EMTU_R) [RFC1122], which is at least 1500 bytes for IPv6 and not = necessarily related to the link MTUs. The text should also clearly = indicate that there is no ICMP mechanism for determining larger EMTU_R = support. >=20 > E.g., the following text is also incorrect in its current form: > The value sent in the TCP MSS option is independent of the PMTU. > This MSS option value is used by the other end of the connection, > which may be using an unrelated PMTU value.=20 >=20 > The first sentence is correct because TCP MSS is related to EMTU_R = (and needs to account for headers, as per RFC6691), and EMTU_R is not = directly related to the PMTU (except that it would never be smaller than = the PMTU). The MSS option is calculated from EMTU_R, not PMTU. >=20 > In addition, it should be noted that ICMPv6 PTB messages are NOT sent = when source fragmentation is enabled. >=20 > 3. need verification of current support for some features, esp. = regarding TCP and NFS interactions > See Gorry's note of 2/14/17 >=20 > 4. the concept of a single path MTU value between two IP addresses = does not account for multipath routing, e.g., ECMP (as currently = deployed, noted in RFC7690, which should be cited) or BANANA (and its = solutions in development) See Fred Templin's posts on this on 2/15/17 >=20 > Minor issues: >=20 > - some of the updates and/or current text could be updated to reflect = current terminology or practice. See Gorry Fairhursts's post of 2/14/17 >=20 > - fragmentation, while considered harmful and costly, is absolutely = necessary to support tunnels even in the presence of PMTUD. The text on = this issue should reflect this reality. >=20 > - the requirement that transports be notified of PTB messages might = usefully cite the corresponding IPv4, TCP, and UDP sections of RFC1122 >=20 > - section 5.4 should cite and include context from RFC6691, especially = including a discussion of the impact of variable IP EHs on the = interaction between TCP MSS and ICMP PTB >=20 > -- >=20 >=20 >=20 >=20 From nobody Tue May 9 00:18:06 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575881270A0 for ; Tue, 9 May 2017 00:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Us5ZL0pXnEjj for ; Tue, 9 May 2017 00:18:03 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F6D126E3A for ; Tue, 9 May 2017 00:18:03 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id m123so89476492wma.0 for ; Tue, 09 May 2017 00:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=7QuWpOTyj/YLn65Ucela2Xpseu+vWYjhmq8z6333P2A=; b=fldQtqHyn+mKRGZDO9OAhEViC68eJOAz4F7gUj917b5IKRiFWR1frmk0BAj8Ve5NrA Hj0RHf/IhsXGiO7C/67hHHCDUrcWv0K6zit63nMZgaqFQlDija6tZiHCUZDQYrA+jGeJ FIiWiFyD9T6os4pSiPbCTpkD7ufLZ0zewIhKb9CDMt8wwrcnXHA7Lat40ZTm9jvWxYr6 PbFYl1UKK6cLuUQiq61i7PXshRPwOiVzZOW6fPVt5OJj5Xl8L3K9edxyRwVXTZFGAndG /gb800UlEKNP/laIsGBosluM9ucmj5k4Qtp46vTg0c/b1sPz0dgo0T1bFkbqLXHwVo63 RwUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=7QuWpOTyj/YLn65Ucela2Xpseu+vWYjhmq8z6333P2A=; b=em3ULEXGic76KN3PYCIHXCRbqeTNuJMDppgkge8rOq6sXyVuvJGUSmZcgrsoutHGz3 ljg7q/wG4J7v5ax2ducdbKNFu3tZH6y8tCAMIXPqixN3Dsk0mOzM+nIFZ7hBTLtlN909 NHtfpKjdETkMYGk3aWil9ExL10cFYZApZmW3+ywRbFsRJFt9dr7yBStVqKmaiJV+WuoK Mc9P69XKpnxGS+GnTP0sdpxFzdRnaZG4kYVII4b87YqBvJev1q2z8EuTkpY/vgVEq1SW zCkwyQ4sm8akOX46VvnJMfoHhvS6hyO4wTmui9WFCYs5qQBdFSkQVYo5vBb+88Z7xW2D 9cPw== X-Gm-Message-State: AODbwcAjqJ6wLFLooC7LGx6Bb4eP4dBTvoO4zW6tVp7bPYd/87tOHCci 7gm5q/9jBDlLTjDNQUIR+A== X-Received: by 10.28.49.195 with SMTP id x186mr11591464wmx.71.1494314281709; Tue, 09 May 2017 00:18:01 -0700 (PDT) Received: from mn-mn0F-2.local ([2a01:598:a0c5:cbf5:719b:98c5:a858:b4d]) by smtp.googlemail.com with ESMTPSA id 137sm12007278wmi.19.2017.05.09.00.18.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 00:18:01 -0700 (PDT) From: Martin Stiemerling To: tsv-art@ietf.org Message-ID: <9745cacf-c1d3-0d2b-a4cb-c02dab350529@gmail.com> Date: Tue, 9 May 2017 09:18:00 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 05/09 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 07:18:05 -0000 Dear TSVers, I did work through all documents that are in IETF LC, IESG processing or being requested for publication as of 05/09, 09:00 am CEST. Please find below all documents checked and what to do with these documents. Documents that require TSV attention: draft-ietf-core-coap-tcp-tls-08 earlier version has been already by Yoshifumi. Please just check the changes -- thanks! Documents that do not require TSV attention: draft-nottingham-rfc5988bis-05 draft-ietf-pals-vpls-pim-snooping-05 draft-ietf-tls-ecdhe-psk-aead-03 draft-ietf-nfsv4-xattrs-05 draft-ietf-netmod-yang-model-classification-06 draft-ietf-calext-caldav-attachments-02 draft-ietf-nfsv4-versioning-09 draft-ietf-nfsv4-umask-03 draft-ietf-mpls-tp-aps-updates-03 draft-ietf-idr-shutdown-08 draft-ietf-oauth-native-apps-10 draft-ietf-bmwg-vswitch-opnfv-03 draft-ietf-mpls-tp-shared-ring-protection-05 Thanks to all reviewers Martin From nobody Wed May 10 10:20:19 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5871296CD for ; Wed, 10 May 2017 10:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 w_aJlHscae86 for ; Wed, 10 May 2017 10:20:16 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027101294EF for ; Wed, 10 May 2017 10:20:15 -0700 (PDT) Received: from [128.9.184.236] ([128.9.184.236]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v4AHK5SH026041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 10 May 2017 10:20:05 -0700 (PDT) To: "Mirja Kuehlewind (IETF)" Cc: "tsv-art@ietf.org" , Spencer Dawkins at IETF References: <48bfa3a1-e53c-6b31-69b0-2645ddd5937f@isi.edu> <5AB999EB-EB4D-46D0-A9B8-20B0E1817896@kuehlewind.net> From: Joe Touch Message-ID: <5a6e1b02-7274-6a60-882a-a88980b08b24@isi.edu> Date: Wed, 10 May 2017 10:20:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <5AB999EB-EB4D-46D0-A9B8-20B0E1817896@kuehlewind.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-MailScanner-ID: v4AHK5SH026041 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Tsv-art] TSV-ART Telechat review of draft-ietf-6man-rfc1981bis-04 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 17:20:18 -0000 Will do. Joe On 5/8/2017 8:49 AM, Mirja Kuehlewind (IETF) wrote: > Hi Joe, > > given I’ve seen no additional discussion on this thread, did you check/can you check if the latest version (-06) addresses your comments? > > Thanks! > Mirja > > >> Am 15.02.2017 um 22:51 schrieb Joe Touch : >> >> Document: draft-ietf-6man-rfc1981bis-04 >> Reviewer: Joe Touch >> Review Date: February 15, 2017 >> IETF LC End Date: March 3, 2017 >> IESG Telechat date: February 28, 2017 >> >> Review result: significant issues >> >> NOTE: some of this review is informed by tracking some of the issues raised by others on the IETF list, notably Gorry Fairhurst. >> >> Major issues: >> >> 1) the current text is insufficiently realistic about the (in)ability of this mechanism to operate in current networks, regardless of the support for generating ICMPs at routers or PMTUD support at endpoints, due to ICMP filtering for security reasons. [this comment is already being addressed by consensus text] >> >> 2) the current text is insufficiently clear on on the difference between the path MTU, which determines the largest supported IPv6 fragment, vs. the effective MTU to receive (EMTU_R), which determines the largest IP packet that can transit between the source and destination. The document should be more explicit throughput about its goal being to manage or avoid IPv6 source fragmentation rather than about source to destination packet maximums, and in specific in clearly referring to maximum fragments or atomic packets rather than maximum packets. >> >> E.g.: see the following text, which is incorrect in its current form: >> Nodes not implementing Path MTU Discovery use the IPv6 minimum link >> MTU defined in [ >> I-D.ietf-6man-rfc2460bis >> ] as the maximum packet size. >> >> The value used by either Path MTU Discovery or its default represents the path MTU, which is the largest IPv6 *fragment* (or atomic packet, see RFC6864) that can be supported on the path between the endpoints. The maximum IP packet size is limited by the effective MTU to receive (EMTU_R) [RFC1122], which is at least 1500 bytes for IPv6 and not necessarily related to the link MTUs. The text should also clearly indicate that there is no ICMP mechanism for determining larger EMTU_R support. >> >> E.g., the following text is also incorrect in its current form: >> The value sent in the TCP MSS option is independent of the PMTU. >> This MSS option value is used by the other end of the connection, >> which may be using an unrelated PMTU value. >> >> The first sentence is correct because TCP MSS is related to EMTU_R (and needs to account for headers, as per RFC6691), and EMTU_R is not directly related to the PMTU (except that it would never be smaller than the PMTU). The MSS option is calculated from EMTU_R, not PMTU. >> >> In addition, it should be noted that ICMPv6 PTB messages are NOT sent when source fragmentation is enabled. >> >> 3. need verification of current support for some features, esp. regarding TCP and NFS interactions >> See Gorry's note of 2/14/17 >> >> 4. the concept of a single path MTU value between two IP addresses does not account for multipath routing, e.g., ECMP (as currently deployed, noted in RFC7690, which should be cited) or BANANA (and its solutions in development) See Fred Templin's posts on this on 2/15/17 >> >> Minor issues: >> >> - some of the updates and/or current text could be updated to reflect current terminology or practice. See Gorry Fairhursts's post of 2/14/17 >> >> - fragmentation, while considered harmful and costly, is absolutely necessary to support tunnels even in the presence of PMTUD. The text on this issue should reflect this reality. >> >> - the requirement that transports be notified of PTB messages might usefully cite the corresponding IPv4, TCP, and UDP sections of RFC1122 >> >> - section 5.4 should cite and include context from RFC6691, especially including a discussion of the impact of variable IP EHs on the interaction between TCP MSS and ICMP PTB >> >> -- >> >> >> >> From nobody Wed May 10 11:19:33 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206D2129481 for ; Wed, 10 May 2017 11:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 82WXt_zFvG7k for ; Wed, 10 May 2017 11:19:30 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB82126D74 for ; Wed, 10 May 2017 11:19:30 -0700 (PDT) Received: from [128.9.184.236] ([128.9.184.236]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v4AIJEAV017163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 10 May 2017 11:19:14 -0700 (PDT) From: Joe Touch To: "Mirja Kuehlewind (IETF)" Cc: "tsv-art@ietf.org" , Spencer Dawkins at IETF References: <48bfa3a1-e53c-6b31-69b0-2645ddd5937f@isi.edu> <5AB999EB-EB4D-46D0-A9B8-20B0E1817896@kuehlewind.net> <5a6e1b02-7274-6a60-882a-a88980b08b24@isi.edu> Message-ID: Date: Wed, 10 May 2017 11:19:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <5a6e1b02-7274-6a60-882a-a88980b08b24@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-MailScanner-ID: v4AIJEAV017163 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Tsv-art] TSV-ART Telechat review of draft-ietf-6man-rfc1981bis-04 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 18:19:32 -0000 Hi, Mirja, 06 addressed all my comments. I am coordinating with Bob and others off-list on pending DISCUSS issues. Joe On 5/10/2017 10:20 AM, Joe Touch wrote: > Will do. > > Joe > > > On 5/8/2017 8:49 AM, Mirja Kuehlewind (IETF) wrote: >> Hi Joe, >> >> given I’ve seen no additional discussion on this thread, did you check/can you check if the latest version (-06) addresses your comments? >> >> Thanks! >> Mirja >> >> >>> Am 15.02.2017 um 22:51 schrieb Joe Touch : >>> >>> Document: draft-ietf-6man-rfc1981bis-04 >>> Reviewer: Joe Touch >>> Review Date: February 15, 2017 >>> IETF LC End Date: March 3, 2017 >>> IESG Telechat date: February 28, 2017 >>> >>> Review result: significant issues >>> >>> NOTE: some of this review is informed by tracking some of the issues raised by others on the IETF list, notably Gorry Fairhurst. >>> >>> Major issues: >>> >>> 1) the current text is insufficiently realistic about the (in)ability of this mechanism to operate in current networks, regardless of the support for generating ICMPs at routers or PMTUD support at endpoints, due to ICMP filtering for security reasons. [this comment is already being addressed by consensus text] >>> >>> 2) the current text is insufficiently clear on on the difference between the path MTU, which determines the largest supported IPv6 fragment, vs. the effective MTU to receive (EMTU_R), which determines the largest IP packet that can transit between the source and destination. The document should be more explicit throughput about its goal being to manage or avoid IPv6 source fragmentation rather than about source to destination packet maximums, and in specific in clearly referring to maximum fragments or atomic packets rather than maximum packets. >>> >>> E.g.: see the following text, which is incorrect in its current form: >>> Nodes not implementing Path MTU Discovery use the IPv6 minimum link >>> MTU defined in [ >>> I-D.ietf-6man-rfc2460bis >>> ] as the maximum packet size. >>> >>> The value used by either Path MTU Discovery or its default represents the path MTU, which is the largest IPv6 *fragment* (or atomic packet, see RFC6864) that can be supported on the path between the endpoints. The maximum IP packet size is limited by the effective MTU to receive (EMTU_R) [RFC1122], which is at least 1500 bytes for IPv6 and not necessarily related to the link MTUs. The text should also clearly indicate that there is no ICMP mechanism for determining larger EMTU_R support. >>> >>> E.g., the following text is also incorrect in its current form: >>> The value sent in the TCP MSS option is independent of the PMTU. >>> This MSS option value is used by the other end of the connection, >>> which may be using an unrelated PMTU value. >>> >>> The first sentence is correct because TCP MSS is related to EMTU_R (and needs to account for headers, as per RFC6691), and EMTU_R is not directly related to the PMTU (except that it would never be smaller than the PMTU). The MSS option is calculated from EMTU_R, not PMTU. >>> >>> In addition, it should be noted that ICMPv6 PTB messages are NOT sent when source fragmentation is enabled. >>> >>> 3. need verification of current support for some features, esp. regarding TCP and NFS interactions >>> See Gorry's note of 2/14/17 >>> >>> 4. the concept of a single path MTU value between two IP addresses does not account for multipath routing, e.g., ECMP (as currently deployed, noted in RFC7690, which should be cited) or BANANA (and its solutions in development) See Fred Templin's posts on this on 2/15/17 >>> >>> Minor issues: >>> >>> - some of the updates and/or current text could be updated to reflect current terminology or practice. See Gorry Fairhursts's post of 2/14/17 >>> >>> - fragmentation, while considered harmful and costly, is absolutely necessary to support tunnels even in the presence of PMTUD. The text on this issue should reflect this reality. >>> >>> - the requirement that transports be notified of PTB messages might usefully cite the corresponding IPv4, TCP, and UDP sections of RFC1122 >>> >>> - section 5.4 should cite and include context from RFC6691, especially including a discussion of the impact of variable IP EHs on the interaction between TCP MSS and ICMP PTB >>> >>> -- >>> >>> >>> >>> > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art From nobody Tue May 23 02:05:12 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE222128CF0; Tue, 23 May 2017 02:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BiAAMxk66bjp; Tue, 23 May 2017 02:05:04 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40C28128B44; Tue, 23 May 2017 02:05:04 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id 123so16810018wmg.1; Tue, 23 May 2017 02:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=ZEYZ4/fyPNKcNzkVePKybSLiRKJRLYYQs60a1TqndIA=; b=t5YRK4mFarA/7QRHcduxvTToCm5xYiiVAyEUfoffjgw5wRBc78NbPbq+n2IKFsIST7 HPVwjB1aZN6yGTfUYZPBWF6pZOnfiutoP3QpuDSWZcq4oOYvrHRUIml870YZpnfnHkpe nEKGVFPVeY7HvsLOnPU0AgOugY/RRSmVAPkDDLt1JQma55hggblo1x+HzfWaFmGGdbIP PX7/x0ZWBoia4/trWfMbvOy75nGsuWLBcrwc4bfQDCBifv/FDs+Iqp6gtyew11sVAKbR E35/VIW9fPA2WbRcoWOI799gpfJMfVEbW3MjdfIFDVpnRMwSGf6agED8FcyemJfH7VFW nb3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=ZEYZ4/fyPNKcNzkVePKybSLiRKJRLYYQs60a1TqndIA=; b=EKsy0Jsa4FuaupKb5IQzqUtntYhN543hjx2WBCyBcx9nLyFq0YxVRwhb1lPQ8Wjzr6 eFvXCfuF6/Tmz91KCNz4wEDtHSjB7xdZaXveC7OSWjeVLDhtno+cSo/F+VBTGX79uW1z obgbUYoroo8bPgZM5UEOystbQUhjEFYOPfRBKCh/E/UTh+mjXVBRH4MuVb1V+EwvaPs9 rO2Gg9SgsZLldTKBfl1mcAEm7AMY6bBXpOsJMyJ39zTHttaPm+lWf+f5/OtshamcgpWz mpJ63Du1iA0pHtJoCbj60A8dCV9ShEjD1F+RuQntupTxjSi9I8Voq8NC3S7hi330ynXX f/HA== X-Gm-Message-State: AODbwcDqykbYJ63f/DHQykm0dmzlshiQhUKcU4zE4rCgGdBU0RRiM66T NBPYVmvAjJlLxRpl X-Received: by 10.28.230.200 with SMTP id e69mr1482529wmi.70.1495530302298; Tue, 23 May 2017 02:05:02 -0700 (PDT) Received: from mn-mn0F-2.local (p57870C10.dip0.t-ipconnect.de. [87.135.12.16]) by smtp.googlemail.com with ESMTPSA id a24sm232992wra.17.2017.05.23.02.05.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2017 02:05:01 -0700 (PDT) To: anima@ietf.org Cc: tsv-art@ietf.org From: Martin Stiemerling Message-ID: <6b290c47-5ab1-78e4-9f54-fa4f0679143b@gmail.com> Date: Tue, 23 May 2017 11:05:05 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Tsv-art] TSV-ART review of draft-ietf-anima-grasp-11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 09:05:07 -0000 Hi all, Please find below my review of draft-ietf-anima-grasp-11. The comments below are about -11 of the draft, as I did work on this version and did unfortunately not have time to go through -12. I've reviewed this document as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@… if you reply to or forward this review. Summary: This draft has serious issues, described in the review, and needs to be rethought. General comments: * The title is partially misleading as this document is setting requirements for the protocol and is additionally defining the protocol. This is made obvious in the abstract, but nonetheless, the title is misleading * Document structure: I am not sure why the requirements are listed in Section 2. The are never ever used in the document to motivate any design decision or reference to. So what is the purpose of having these requirements here? Couldn’t and shouldn’t they be listed in a separate document? * Security: There is no security proposed or discussed for GRASP in this document. There are solely statements about generic security, such as in Section 1 „a secure and strongly authenticated environment“ or Section 3.5.2.1. "Messages MUST be authenticated and encryption MUST be implemented“. So how must they be authenticated and encrypted and why? What is the standard set of protocols to be used for this and what is the minimal set of crypto algorithms to be implemented to make this work? ************************************************************ This document is always using the escape hatch when it comes to security in any respect! ************************************************************ * Usage of UDP: This document is not discussing any of the aspects in RFC 8085. Every usage of UDP is required by IETF consensus to review RFC 8085 and to address at least the applicable subset of issues listed in RFC 8085 (or the predecessor RFC 5405). * Starting with UDP and switching to TCP for the data transfer looks like the right do. However, UDP should be really only used to discover other devices, but not piggy back further protocol mechanics. However, this document is not really specific on how to make use of TCP, for instance, how long are TCP connections kept open or closed down after a protocol exchange (persistent vs temporary connections). What happens if a TCP connection is shutdown by one end or is forcefully closed, e.g., by a reset? * There is no versioning support in GRASP. Why are we still developing protocols that do not have versioning support in it? * IPv4/IPv6 simultaneous use: I believe the email describing the -12 update of the draft says that IPv4 and IPv6 should not be mixed, so I can skip over this. Detailed comments: * Section 2.1: These are not protocol requirements but system requirements. It would be really good to separate them in the list of requirements. * Section 2.1, Requirement D2: What is this requirements saying? Is it „it should just work whatever?“ * Section 2.1, Requirement D7: What is the rest of the network in the first bullet point? All anima devices or every single element of the network? * Section 2.2, Requirement SN7: I am not sure if any of these points in this requirement related to any part of the GRAPS protocol. If so, you can for sure add forward references or backward references in the protocol specification. * Section 2.3, T1 & T2 are good, but how is this fulfilled by the protocol? * Section 3.2, end of page 12, „appropriate global-scope address“: so GRASP is not intended to run networks that use private RFC 1918 addresses? * Section 3.2, head of page 13: the discussion about interfaces. I am not sure that calling GRASP interfaces just interfaces helps. Why not calling interfaces interfaces and GRASP interfaces if the are used? or active interfaces, etc? * Section 3.3: This section is again bringing up a number of requirements. Wrong place in the document? * Section 3.3, page 14: the unsolicited flooding mode sounds really bad. Has this aspect looked at in terms of how many GRAPS nodes are expected to live on in a single link-local multicast domain (hoping that non link-local multicast is excluded per se). * Section 3.3: last bullet on page 14 and first bullet on page 15: what is this saying other than it is complicated? Aren’t there any tangible details to this? * Section 3.4: " An instance of GRASP is expected to run as a separate core module, providing an API (such as [I-D.liu-anima-grasp-api]) to interface to various ASAs. These ASAs may operate without special privilege, unless they need it for other reasons (such as configuring IP addresses or manipulating routing tables).“ This is implementation specific and does not belong in a protocol specification. * Section 3.5.1, page 17: „virtualized over the ACP“ — what does this mean and how it is done? * Section 3.5.1, page 17: „If there is no ACP, one“ there are two options listed for this case, but which is used when? * Section 3.5.1, page 17: „strong authentication“ — what is strong authentication and what needs to be supported by a minimal, but interoperable implementation? This is extremely underspecified. * Section 3.5.1, page 17: "Network interfaces could be at different security levels,“ what is a security level in the context of this document and specifically here. * Section 3.5.1, page 17: "discovery messages MUST be secured, with one exception mentioned in“ — how secured? This is extremely underspecified. * Section 3.5.2 s/GRAPS subject/GRAPS are subject/ * Section 3.5.2.1., page 17: "As mentioned in Section 3.3“ this isn’t mentioned in this place or I cannot correlate it. * Section 3.5.2.1., page 17 " implemented. TLS [RFC5246] and DTLS [RFC6347] based on a Public Key Infrastructure (PKI) [RFC5280] are RECOMMENDED for this purpose. Further details are out of scope for this document.“ How bad is this that TLS and DTLS are RECOMMENDED but the usage is not specified? * Section 3.5.2.2: Are there any measures in the protocol to ensure that datagrams have really been sent on the same link? I haven’t seen any measures. * Section 3.5.2.3.: " by TLS. A separate instance of GRASP is used, with its own copy of all GRASP data structures. This instance is nicknamed SONN - Secure Only Neighbor Negotiation.“ I am not sure why this document is trying to mandate how implementers are organizing their implementation and how instances are named? * Section 3.5.2.3, page 19, end of bullet list: "Further details are out of scope for this document.“ What further details? Is the WG not sure what the missing details are? * Section 3.5.3.: "They MUST NOT be fragmented, and therefore MUST NOT exceed the link MTU size.“ How should the protocol ensure that such datagrams are not fragmented and do not exceed the MTU? * Section 3.5.3.: " Use of an unreliable transport protocol is therefore NOT RECOMMENDED.“ — very good guidance — thank you! :-) * Section 3.5.3., end of page 19: * Section 3.5.4.4: "Since the relay device is unaware of the timeout set by the original initiator it SHOULD set a timeout at least equal to GRASP_DEF_TIMEOUT milliseconds.“ The timeout set by the initiator seems to be important, so why is this value not communicated by the initiator within GRASP? * Section 3.5.5: It is unclear to me if the messages here are expected to be sent over TCP or nor? This is not clear. * Section 3.5.5, page 24 and also Section 3.5.6.1: " request is sent (see Section 3.8.6). If no reply message of any kind is received within a reasonable timeout, the negotiation request MAY be repeated, with a newly generated Session ID (Section 3.7). An exponential backoff SHOULD be used for subsequent repetitions.“ What is a reasonable time out? And why is this need if TCP is used? TCP provides reliable data transfer… * Section 3.5.5, page 24: " about different objectives. Thus, GRASP is expected to be used in a multi-threaded mode. Certain negotiation objectives may have restrictions on multi-threading, for example to avoid over-allocating resources. „ Again, talking about the implementation. This is not a protocol specification, isn’t it? * Section 3.5.6.2 (and other places in the document): What is the GRASP core? * Section 3.5.6.2, page 26: „ the result is zero. Also, it MUST limit the total rate at which it relays Flood Synchronization messages to a reasonable value, in order to mitigate possible denial of service attacks. It MUST cache the „ What is a reasonable value? * Message encoding: What is the encoding to be supported for "reason = text ;optional error message“ Is there are any minimal standard to be supported, such as 7 bit ASCII or UTF-8 or whatever? Best regards, Martin Stiemerling From nobody Tue May 23 13:53:47 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42059127A91; Tue, 23 May 2017 13:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZoWa1-yhxgMk; Tue, 23 May 2017 13:53:42 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C1D127B31; Tue, 23 May 2017 13:53:42 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id w69so29903592pfk.1; Tue, 23 May 2017 13:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=c9LkRER2mErkUCIUScL+fZ7GY4oBfAAIidoUydezW9M=; b=E/jjW/PMNQMFPX9qIzLOHN0Sw/xUHgV/0f9bJVIEtW19HUH2UUaYJACvD0WgA1cTFi JQioe6oiTNoMntLLSTE9FGwTZlRLZeF26LeEbK0v1nFgKb984pV6jLHVtoiV39ZuK2gP JGckztcrwUqTrZyDKLqwboioCkYgSOnrdhGTahpMML0QFTUps/E4W4uCsNu22SKTdR10 4kotR/yqpKjmEoYjS4Iov7N5FlECA1MXZeemOp/jSFfzcp33vimH5h+YRs+ogflrXqc5 Cxpv8s2FiownpKEGORHAe/BGRfBMufJEisnnAPIiOt44ilYaYz3jycM+IireGOYRgOV6 +XWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=c9LkRER2mErkUCIUScL+fZ7GY4oBfAAIidoUydezW9M=; b=tlNGpIWxFyD+kLUOAeB4C4ZdDuXtABaDyVAldNBoYbhypRFa0u8y4g74eN0V0fbrUZ SFcfD3EsSCAh1nsSZvlhtVAbh08m+SUpqYq9fxH7icuXwyXt9zYFlZFME56NIrypbRRN iKoHYCAUhKgsuEvL8tfOSVOaw1fgBqNOCR1XVZxA6zYdONn1QFzrd9q4awaddRzwsrHS nb0+woQ1hSv57CqFF/QEjqimEVarHETsUAWpvkU1XBewGZGh8Sp3jrfZ8DxO0lg2uNLw s3lgzSI4CUsE+CXgmh9k3HZ0YK5ufiEmjYkhMDk12KAe7/BF+/QgL0bCbvplnI0YZoVm +COA== X-Gm-Message-State: AODbwcCr0kSPSmErfg/ZlBS9+A7brpy3bI8h0wclYcpmcqbXjV+vsfmb J6vjVqhl79hvPA== X-Received: by 10.84.173.195 with SMTP id p61mr38570121plb.83.1495572822015; Tue, 23 May 2017 13:53:42 -0700 (PDT) Received: from [10.100.103.42] (210-55-57-56.adsl.xtra.co.nz. [210.55.57.56]) by smtp.gmail.com with ESMTPSA id g86sm3124135pfe.116.2017.05.23.13.53.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2017 13:53:41 -0700 (PDT) From: Brian E Carpenter To: Martin Stiemerling , anima@ietf.org Cc: tsv-art@ietf.org References: <6b290c47-5ab1-78e4-9f54-fa4f0679143b@gmail.com> Organization: University of Auckland Message-ID: <192f8891-5509-5201-1335-33bc7a04b7eb@gmail.com> Date: Wed, 24 May 2017 08:53:40 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <6b290c47-5ab1-78e4-9f54-fa4f0679143b@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Tsv-art] [Anima] TSV-ART review of draft-ietf-anima-grasp-11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 20:53:45 -0000 Martin, Thanks for the thorough review. First reactions: On 23/05/2017 21:05, Martin Stiemerling wrote: > Hi all, >=20 > Please find below my review of draft-ietf-anima-grasp-11. > The comments below are about -11 of the draft, as I did work on this=20 > version and did unfortunately not have time to go through -12. >=20 >=20 > I've reviewed this document as part of the transport area review team's= =20 > ongoing effort to review key IETF documents. These comments were writte= n=20 > primarily for the transport area directors, but are copied to the=20 > document's authors for their information and to allow them to address=20 > any issues raised. When done at the time of IETF Last Call, the authors= =20 > should consider this review together with any other last-call comments = > they receive. Please always CC tsv-art@=E2=80=A6 if you reply to or for= ward this=20 > review. >=20 > Summary: > This draft has serious issues, described in the review, and needs to be= =20 > rethought. >=20 >=20 > General comments: > * The title is partially misleading as this document is setting=20 > requirements for the protocol and is additionally defining the protocol= =2E=20 > This is made obvious in the abstract, but nonetheless, the title is=20 > misleading I really don't see that. It's very general title. >=20 > * Document structure: I am not sure why the requirements are listed in = > Section 2. The are never ever used in the document to motivate any=20 > design decision or reference to. So what is the purpose of having these= =20 > requirements here? Couldn=E2=80=99t and shouldn=E2=80=99t they be liste= d in a separate=20 > document? We had specific instructions from our original AD not to do separate requirements analysis. We've also asked the WG a couple of times whether to move the requirements to an Appendix and never got a Yes on that. >=20 > * Security: There is no security proposed or discussed for GRASP in thi= s=20 > document. There are solely statements about generic security, such as i= n=20 > Section 1 =E2=80=9Ea secure and strongly authenticated environment=E2=80= =9C or Section=20 > 3.5.2.1. "Messages MUST be authenticated and encryption MUST be=20 > implemented=E2=80=9C. So how must they be authenticated and encrypted a= nd why?=20 > What is the standard set of protocols to be used for this and what is=20 > the minimal set of crypto algorithms to be implemented to make this wor= k? We're on version 12 now but I'm at a loss to know what is unclear about the statement in https://tools.ietf.org/html/draft-ietf-anima-grasp-12#section-3.5.1 (and the ACP is now a normative reference). > ************************************************************ > This document is always using the escape hatch when it comes to securit= y=20 > in any respect! > ************************************************************ It isn't an escape hatch, it's an explicit statement: "Required External Security Mechanism" =20 > * Usage of UDP: This document is not discussing any of the aspects in=20 > RFC 8085. Every usage of UDP is required by IETF consensus to review RF= C=20 > 8085 and to address at least the applicable subset of issues listed in = > RFC 8085 (or the predecessor RFC 5405). The somewhat weak language about unicast UDP has gone in version 12: https://tools.ietf.org/html/draft-ietf-anima-grasp-12#section-3.5.3 We now say "Use of an unreliable transport protocol is therefore NOT RECOMMENDED." As far as multicast goes, https://tools.ietf.org/html/rfc8085#section-4.1 is new work but at a quick glance I don't think there is any concern. We use link-local multicast with precautions against excessive rates or loops. RFC8085 seems to be worrying about completely different types of usage. Of course we can add a statement about that. >=20 > * Starting with UDP and switching to TCP for the data transfer looks=20 > like the right do. However, UDP should be really only used to discover = > other devices, but not piggy back further protocol mechanics. However, = > this document is not really specific on how to make use of TCP, for=20 > instance, how long are TCP connections kept open or closed down after a= =20 > protocol exchange (persistent vs temporary connections).=20 They can all be temporary. We can add that. > What happens if=20 > a TCP connection is shutdown by one end or is forcefully closed, e.g., = > by a reset? What's to say? The operation fails, and then it's up to the user (the autonomic service agent) what to do next. If that isn't quite obvious, we can certainly add it. >=20 > * There is no versioning support in GRASP. Why are we still developing = > protocols that do not have versioning support in it? Because the protocol is indefinitely extensible by adding message types and options. We really don't see any need for a version number. The M_INVALID message was added so that old and new code can discover what works and what doesn't. >=20 > * IPv4/IPv6 simultaneous use: I believe the email describing the -12=20 > update of the draft says that IPv4 and IPv6 should not be mixed, so I=20 > can skip over this. >=20 > Detailed comments: >=20 > * Section 2.1: These are not protocol requirements but system=20 > requirements. It would be really good to separate them in the list of=20 > requirements. >=20 > * Section 2.1, Requirement D2: What is this requirements saying? Is it= =20 > =E2=80=9Eit should just work whatever?=E2=80=9C Yes. There should be no uncaught exceptions. That's a pretty general rule in autonomic systems, so it must also be true in the protocol itself. >=20 > * Section 2.1, Requirement D7: What is the rest of the network in the=20 > first bullet point? All anima devices or every single element of the=20 > network? All autonomic devices; this could be clarified. >=20 > * Section 2.2, Requirement SN7: I am not sure if any of these points in= =20 > this requirement related to any part of the GRAPS protocol. If so, you = > can for sure add forward references or backward references in the=20 > protocol specification. That's hard to do. It's really saying (computer science hat on) that GRAS= P needs to be powerful enough to express all kinds of semantics that you might need. >=20 > * Section 2.3, T1 & T2 are good, but how is this fulfilled by the proto= col? T1 is in practice fulfilled by the choice of CBOR and its ability to expr= ess almost any kind of data structure. T2, by the ability to add message type= s and options in future. (But getting back to our original instructions fro= m Benoit, do we really need to map requirements:features ?) > * Section 3.2, end of page 12, =E2=80=9Eappropriate global-scope addres= s=E2=80=9C: so=20 > GRASP is not intended to run networks that use private RFC 1918 address= es? Well, we tend to think in IPv6 terms, where anything that isn't link-loca= l has global scope. And we *really* hope that GRASP itself will always run = over IPv6 even if it's managing an IPv4 data plane. But you're right, it shoul= d be phrased to cover the RFC1918 case. >=20 > * Section 3.2, head of page 13: the discussion about interfaces. I am=20 > not sure that calling GRASP interfaces just interfaces helps. Why not=20 > calling interfaces interfaces and GRASP interfaces if the are used? or = > active interfaces, etc? That's been tweaked in the -12 draft already. >=20 > * Section 3.3: This section is again bringing up a number of=20 > requirements. Wrong place in the document? Sorry, I don't see any requirements there; it describes decisions IMHO. >=20 > * Section 3.3, page 14: the unsolicited flooding mode sounds really bad= =2E=20 > Has this aspect looked at in terms of how many GRAPS nodes are expected= =20 > to live on in a single link-local multicast domain (hoping that non=20 > link-local multicast is excluded per se). It is a trade-off, but we have use cases (such as distributing Intent to every autonomic node, a low frequency operation) where flooding really= does look like a necessary tool. =20 > * Section 3.3: last bullet on page 14 and first bullet on page 15: what= =20 > is this saying other than it is complicated? Aren=E2=80=99t there any t= angible=20 > details to this? I don't really understand your point there. =20 > * Section 3.4: > " An instance of GRASP is expected to run as a separate core module, > providing an API (such as [I-D.liu-anima-grasp-api]) to interface t= o > various ASAs. These ASAs may operate without special privilege, > unless they need it for other reasons (such as configuring IP > addresses or manipulating routing tables).=E2=80=9C > This is implementation specific and does not belong in a protocol=20 > specification. Disagree. I think an implementer needs to keep this in mind. > * Section 3.5.1, page 17: =E2=80=9Evirtualized over the ACP=E2=80=9C =E2= =80=94 what does this=20 > mean and how it is done? See the ACP draft. >=20 > * Section 3.5.1, page 17: =E2=80=9EIf there is no ACP, one=E2=80=9C the= re are two=20 > options listed for this case, but which is used when? I think section 3.5.2 covers this clearly. >=20 > * Section 3.5.1, page 17: =E2=80=9Estrong authentication=E2=80=9C =E2=80= =94 what is strong=20 > authentication and what needs to be supported by a minimal, but=20 > interoperable implementation? This is extremely underspecified. See the ACP draft or in 3.5.2. =20 > * Section 3.5.1, page 17: "Network interfaces could be at different=20 > security levels,=E2=80=9C what is a security level in the context of th= is=20 > document and specifically here. OK will clarify >=20 > * Section 3.5.1, page 17: "discovery messages MUST be secured, with one= =20 > exception mentioned in=E2=80=9C =E2=80=94 how secured? This is extremel= y underspecified. See the ACP draft or in 3.5.2. >=20 > * Section 3.5.2 s/GRAPS subject/GRAPS are subject/ OK >=20 > * Section 3.5.2.1., page 17: "As mentioned in Section 3.3=E2=80=9C this= isn=E2=80=99t=20 > mentioned in this place or I cannot correlate it. Will check >=20 > * Section 3.5.2.1., page 17 > " implemented. TLS [RFC5246] and DTLS [RFC6347] based on a Public Ke= y > Infrastructure (PKI) [RFC5280] are RECOMMENDED for this purpose. > Further details are out of scope for this document.=E2=80=9C > How bad is this that TLS and DTLS are RECOMMENDED but the usage is not = > specified? Because we decided it was out of scope for now.=20 >=20 > * Section 3.5.2.2: Are there any measures in the protocol to ensure tha= t=20 > datagrams have really been sent on the same link? I haven=E2=80=99t see= n any=20 > measures. As far as I can tell that's an implementation detail that depends on the socket API. >=20 > * Section 3.5.2.3.: > " by TLS. A separate instance of GRASP is used, with its own copy of= > all GRASP data structures. This instance is nicknamed SONN - Secur= e > Only Neighbor Negotiation.=E2=80=9C > I am not sure why this document is trying to mandate how implementers=20 > are organizing their implementation and how instances are named? Because this is how we can specify a minimal amount of security during th= e bootstrap process that depends on GRASP. > * Section 3.5.2.3, page 19, end of bullet list: "Further details are ou= t=20 > of scope for this document.=E2=80=9C What further details? Is the WG no= t sure=20 > what the missing details are? Again, implementation details that are very likely o/s dependent. > * Section 3.5.3.: > "They MUST NOT be fragmented, and therefore MUST > NOT exceed the link MTU size.=E2=80=9C > How should the protocol ensure that such datagrams are not fragmented=20 > and do not exceed the MTU? By magic? I think this needs rephrasing. >=20 > * Section 3.5.3.: " Use of an unreliable transport protocol is therefor= e=20 > NOT RECOMMENDED.=E2=80=9C =E2=80=94 very good guidance =E2=80=94 thank = you! :-) >=20 > * Section 3.5.3., end of page 19: >=20 > * Section 3.5.4.4: > "Since the relay device is unaware of the timeout set by the original > initiator it SHOULD set a timeout at least equal to GRASP_DEF_TIMEO= UT > milliseconds.=E2=80=9C >=20 > The timeout set by the initiator seems to be important, so why is this = > value not communicated by the initiator within GRASP? As I replied to Mirja, we do need a little more work on this text. >=20 > * Section 3.5.5: It is unclear to me if the messages here are expected = > to be sent over TCP or nor? This is not clear. Will clarify >=20 > * Section 3.5.5, page 24 and also Section 3.5.6.1: > " request is sent (see Section 3.8.6). If no reply message of any ki= nd > is received within a reasonable timeout, the negotiation request MA= Y > be repeated, with a newly generated Session ID (Section 3.7). An > exponential backoff SHOULD be used for subsequent repetitions.=E2=80= =9C > What is a reasonable time out? And why is this need if TCP is used? TCP= =20 > provides reliable data transfer=E2=80=A6 Right, but the other end might die. >=20 > * Section 3.5.5, page 24: > " about different objectives. Thus, GRASP is expected to be used in = a > multi-threaded mode. Certain negotiation objectives may have > restrictions on multi-threading, for example to avoid over-allocati= ng > resources. > =E2=80=9E > Again, talking about the implementation. This is not a protocol=20 > specification, isn=E2=80=99t it? Again, an area where implementers need to pay attention. >=20 > * Section 3.5.6.2 (and other places in the document): What is the GRASP= =20 > core? Maybe need to mention that in the terminology section. >=20 > * Section 3.5.6.2, page 26: > =E2=80=9E the result is zero. Also, it MUST limit the total rate at = which it > relays Flood Synchronization messages to a reasonable value, in ord= er > to mitigate possible denial of service attacks. It MUST cache the > =E2=80=9E > What is a reasonable value? I'm not sure we can put a number on it. It is surely technology-dependent= =2E >=20 > * Message encoding: What is the encoding to be supported for "reason =3D= =20 > text ;optional error message=E2=80=9C Is there are any minimal standar= d to be=20 > supported, such as 7 bit ASCII or UTF-8 or whatever? It is intended to be UTF-8, if that isn't clear it needs to be written. Regards, Brian (in a rush, on vacation) >=20 > Best regards, >=20 > Martin Stiemerling >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Thu May 25 11:35:03 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACAD129C26; Thu, 25 May 2017 11:35:00 -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_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 yLZMELkblO7b; Thu, 25 May 2017 11:34:59 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86FF3129418; Thu, 25 May 2017 11:34:59 -0700 (PDT) Received: from [128.9.184.77] ([128.9.184.77]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v4PIYKLQ006586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 May 2017 11:34:21 -0700 (PDT) To: Brian E Carpenter , Martin Stiemerling , anima@ietf.org Cc: tsv-art@ietf.org References: <6b290c47-5ab1-78e4-9f54-fa4f0679143b@gmail.com> <192f8891-5509-5201-1335-33bc7a04b7eb@gmail.com> From: Joe Touch Message-ID: <5e92dd05-074f-fde7-9281-10eaea4b0169@isi.edu> Date: Thu, 25 May 2017 11:34:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <192f8891-5509-5201-1335-33bc7a04b7eb@gmail.com> Content-Type: multipart/alternative; boundary="------------F1329C1C042427F7A5661688" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Tsv-art] [Anima] TSV-ART review of draft-ietf-anima-grasp-11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 18:35:01 -0000 This is a multi-part message in MIME format. --------------F1329C1C042427F7A5661688 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, Brian, On 5/23/2017 1:53 PM, Brian E Carpenter wrote: >> * There is no versioning support in GRASP. Why are we still developing >> protocols that do not have versioning support in it? > Because the protocol is indefinitely extensible by adding message types > and options. We really don't see any need for a version number. The > M_INVALID message was added so Version support is recommended by IANA (see RFC7506, Sec 7.5). Extensibility is a separate issue and doesn't replace the benefit of version support. The goal is to avoid needing to assign a new port number for GRASPv2 in the future. IMO, all messages (including NOOP) should start with a version number, and I'd suggest at least 2 bits (if not 4). Joe --------------F1329C1C042427F7A5661688 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi, Brian,

On 5/23/2017 1:53 PM, Brian E Carpenter wrote:
* There is no versioning support in GRASP. Why are we still developing 
protocols that do not have versioning support in it?

Because the protocol is indefinitely extensible by adding message types
and options. We really don't see any need for a version number. The
M_INVALID message was added so
Version support is recommended by IANA (see RFC7506, Sec 7.5).

Extensibility is a separate issue and doesn't replace the benefit of version support.

The goal is to avoid needing to assign a new port number for GRASPv2 in the future.

IMO, all messages (including NOOP) should start with a version number, and I'd suggest at least 2 bits (if not 4).

Joe
--------------F1329C1C042427F7A5661688-- From nobody Thu May 25 12:37:25 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9E512E85E; Thu, 25 May 2017 12:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 ACdlr2DiRxIE; Thu, 25 May 2017 12:37:16 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5C8129422; Thu, 25 May 2017 12:37:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id ABC75203AF; Thu, 25 May 2017 15:37:19 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 817FA636BB; Thu, 25 May 2017 15:37:15 -0400 (EDT) From: Michael Richardson To: Joe Touch cc: Brian E Carpenter , Martin Stiemerling , anima@ietf.org, tsv-art@ietf.org In-Reply-To: <5e92dd05-074f-fde7-9281-10eaea4b0169@isi.edu> References: <6b290c47-5ab1-78e4-9f54-fa4f0679143b@gmail.com> <192f8891-5509-5201-1335-33bc7a04b7eb@gmail.com> <5e92dd05-074f-fde7-9281-10eaea4b0169@isi.edu> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Tsv-art] [Anima] TSV-ART review of draft-ietf-anima-grasp-11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 19:37:18 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Joe Touch wrote: > Version support is recommended by IANA (see RFC7506, Sec 7.5). > Extensibility is a separate issue and doesn't replace the benefit of > version support. > The goal is to avoid needing to assign a new port number for GRASPv2 = in > the future. > IMO, all messages (including NOOP) should start with a version number, > and I'd suggest at least 2 bits (if not 4). Everything is CBOR encoded, so we have no dependancy upon encoded bits on t= he wire changing. {Should CBOR change in an incompatible way, we'd need a new port number, tr= ue} Otherwise, we could obsolete any of the M_ operations trivially. We currently expect to encode the "first" layer as a CBOR array (which creates the record boundary for TCP as well). We could even decide that "version 2" would start with [M_GRASP2, [stuff]] costing us perhaps two bytes, which is about the same as inserting a version would cost, but I'm still not convinced we'd ever need to do that. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlknMmsACgkQgItw+93Q 3WXxxwf/Zp37J/EglSDeeU4FSU4ig/nqRxd4Tx6wskARI+CaWs57k8vdO/9jANkW aUhmuPzZVyPWdO84J7j5s7SJfgRbqXHp1Hiy/QI88dmBkaDd829roLX/KQqZw6VG y5YZT8nMVCpf6JglWPczdeT3bGrkpeIM3wVPb8thh/5A323uC8N5TK5vrfBlaTEp VHMcOJAjA5QwwZa0R1AQRJv417Owe9J88nLqmIKp0rrw0cKHj4bdXBD9wmvSO4KQ JutEV0rPSdF0PXaKI1CrNTiUrENxlofX+lH44/ghGd0jW/P9sQyosRfG2DnQB3ub RNNLpYw/iffmY+XLXG0VfZbGDEVKXQ== =xvJz -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 25 13:09:27 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8221F12EAC2; Thu, 25 May 2017 13:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xGARor58GFlr; Thu, 25 May 2017 13:09:24 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B6812EAC0; Thu, 25 May 2017 13:09:24 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id n23so41187188pfb.3; Thu, 25 May 2017 13:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=niM8hS6pNLq3R5gZt6KMFWU65UB5DFi1OhGLeRlF+GI=; b=s0OZzTyakYv1bQwABaQanGSFY52m2zsiyZzp/CwpXjplhg60rm9INPPPj80vJ7opNh JNAE/vf+Y2hriKOwwpfEfNb2wTwJj7IXhZiPkqPPJnJrETjLt+So7tqaWzo3Xpw5/nXB 8mLOlCZmtoiS5M0GWgNG8x089ffv84E18YY5cEt/k3X+SaLHAgbnOsFY90Bcszb/dxJr VpqRanLVo+OeCQikN2vtdsBuEtkB1MjboIx3AcvkRHXhOXWm7rubSgl8n0U0AJncpz1O n3PNNdBMzYXC/k9BefjXxG10YgSLWHK66qM+7jpq7illS+6VJBrtvNIpfk0dK5Nl0ZXM zJwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=niM8hS6pNLq3R5gZt6KMFWU65UB5DFi1OhGLeRlF+GI=; b=FgajLGBwu44bETWIr4oLdn3Oq6RUI0Fjt0Wf8uPaP3x1Pc7K3Er/Ds+400NU1yNGIR 8jgl/8AbYyBt8AQ7D2kMapFCZllhB3QHSqf8FQPt1F23qy8fhdQT1wJF1eAizN6kF+su fnlVnZlyaN8nOatKXyUA3Lonhy68+xFrTdjmJRwUDyWCDsd8vqbkib6dmIlogEJDULny ZpaRkUKRvKa6eRxyqBI6ISGcEo1jLEi2NSHyYWBu9Q99Zt3Xt/Zh0Yy8GznDkv4XPa00 DOFY6w4Q3N3eJDm4eZWm/kbJTHrsAd4ZRi4QHjFcBvCyO46FIGBZzURP01jQVkIleegt ZkkA== X-Gm-Message-State: AODbwcBj0KuadyghsAxqhhs2dFUJhoZ9ALQ7fZln1hGvRBE+KkLvRZr+ LYTvVgBSztaGIg== X-Received: by 10.98.18.157 with SMTP id 29mr45763176pfs.75.1495742963680; Thu, 25 May 2017 13:09:23 -0700 (PDT) Received: from [10.100.103.42] (210-55-57-56.adsl.xtra.co.nz. [210.55.57.56]) by smtp.gmail.com with ESMTPSA id e124sm15261587pfc.64.2017.05.25.13.09.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2017 13:09:23 -0700 (PDT) To: Michael Richardson , Joe Touch Cc: Martin Stiemerling , anima@ietf.org, tsv-art@ietf.org References: <6b290c47-5ab1-78e4-9f54-fa4f0679143b@gmail.com> <192f8891-5509-5201-1335-33bc7a04b7eb@gmail.com> <5e92dd05-074f-fde7-9281-10eaea4b0169@isi.edu> <5640.1495741035@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <606e09b0-5046-d3f5-c3ba-bf373e300f15@gmail.com> Date: Fri, 26 May 2017 08:09:28 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <5640.1495741035@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tsv-art] [Anima] TSV-ART review of draft-ietf-anima-grasp-11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 20:09:25 -0000 On 26/05/2017 07:37, Michael Richardson wrote: > > Joe Touch wrote: > > Version support is recommended by IANA (see RFC7506, Sec 7.5). > > > Extensibility is a separate issue and doesn't replace the benefit of > > version support. > > > The goal is to avoid needing to assign a new port number for GRASPv2 in > > the future. > > > IMO, all messages (including NOOP) should start with a version number, > > and I'd suggest at least 2 bits (if not 4). > > Everything is CBOR encoded, so we have no dependancy upon encoded bits on the > wire changing. > {Should CBOR change in an incompatible way, we'd need a new port number, true} > > Otherwise, we could obsolete any of the M_ operations trivially. > We currently expect to encode the "first" layer as a CBOR array (which > creates the record boundary for TCP as well). > > We could even decide that "version 2" would start with [M_GRASP2, [stuff]] > costing us perhaps two bytes, which is about the same as inserting a version > would cost, but I'm still not convinced we'd ever need to do that. You're right. If we had stuck to the original TLV model I would have agreed that a version number is needed, but the nature of CBOR means that it really isn't useful. Even the limit MESSAGE_TYPE = 0..255 in the syntax isn't restrictive; a message type >255 or <0 would just kick back an M_INVALID with old code, and would be happily accepted by new code, if we increased the valid range. Brian From nobody Thu May 25 15:11:17 2017 Return-Path: X-Original-To: tsv-art@ietfa.amsl.com Delivered-To: tsv-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85EEA129B7E; Thu, 25 May 2017 15:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 tjZTzrQo4rpr; Thu, 25 May 2017 15:11:15 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7463D127B5A; Thu, 25 May 2017 15:11:15 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4PMArMu006974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 May 2017 15:11:04 -0700 (PDT) To: Brian E Carpenter , Michael Richardson Cc: Martin Stiemerling , anima@ietf.org, tsv-art@ietf.org References: <6b290c47-5ab1-78e4-9f54-fa4f0679143b@gmail.com> <192f8891-5509-5201-1335-33bc7a04b7eb@gmail.com> <5e92dd05-074f-fde7-9281-10eaea4b0169@isi.edu> <5640.1495741035@obiwan.sandelman.ca> <606e09b0-5046-d3f5-c3ba-bf373e300f15@gmail.com> From: Joe Touch Message-ID: <73b206be-2989-e7ce-a17a-c4819c4bbbab@isi.edu> Date: Thu, 25 May 2017 15:10:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <606e09b0-5046-d3f5-c3ba-bf373e300f15@gmail.com> Content-Type: multipart/alternative; boundary="------------2788B1BA88BFA03DADA6C971" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Tsv-art] [Anima] TSV-ART review of draft-ietf-anima-grasp-11 X-BeenThere: tsv-art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Review Team List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 22:11:16 -0000 This is a multi-part message in MIME format. --------------2788B1BA88BFA03DADA6C971 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 5/25/2017 1:09 PM, Brian E Carpenter wrote: >> We could even decide that "version 2" would start with [M_GRASP2, [stuff]] >> costing us perhaps two bytes, which is about the same as inserting a version >> would cost, but I'm still not convinced we'd ever need to do that. > You're right. If we had stuck to the original TLV model I would have agreed > that a version number is needed, but the nature of CBOR means that it > really isn't useful. Even the limit MESSAGE_TYPE = 0..255 in the syntax > isn't restrictive; a message type >255 or <0 would just kick back an M_INVALID > with old code, and would be happily accepted by new code, if we increased > the valid range. > > Brian AOK - thanks for the explanation. Joe --------------2788B1BA88BFA03DADA6C971 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 5/25/2017 1:09 PM, Brian E Carpenter wrote:
We could even decide that "version 2" would start with [M_GRASP2, [stuff]]
costing us perhaps two bytes, which is about the same as inserting a version
would cost, but I'm still not convinced we'd ever need to do that.

You're right. If we had stuck to the original TLV model I would have agreed
that a version number is needed, but the nature of CBOR means that it
really isn't useful. Even the limit MESSAGE_TYPE = 0..255 in the syntax
isn't restrictive; a message type >255 or <0 would just kick back an M_INVALID
with old code, and would be happily accepted by new code, if we increased
the valid range.

    Brian
AOK - thanks for the explanation.
Joe
--------------2788B1BA88BFA03DADA6C971--