From nobody Mon May 1 22:43:01 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B637412EA54 for ; Mon, 1 May 2017 22:42: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=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 h9ovLXFPEKwO for ; Mon, 1 May 2017 22:42:52 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id AC2B9129AFC for ; Mon, 1 May 2017 22:40:20 -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: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 05:42:55 -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:35 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@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: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 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:29 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D77129C0C 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 94PbRqjnLfx5 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 5E988126DFF 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: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 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鈥檇 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 Tue May 2 00:09:21 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B8612EB6E; Tue, 2 May 2017 00:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 853LJ8FuOahh; Tue, 2 May 2017 00:09:17 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5999412EB8A; Tue, 2 May 2017 00:04:48 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1493708686; h=from:subject:to:date:message-id; bh=kr9zsj6cVtFruFj2kU8UMO4fc37tqrW2sqG4LG3ng2U=; b=h9ykr0OrEhs3TNma9aUBsJXNPxKaeyr4DragJj1HThjlmBDfCTFe4Bf0HtXjq+Mu0sAzxpLawco f5UDp1tAAnrh9sXyxMNIX8jpHhdigO+yumIG022oOO5n60uGyHLUbz9Q6hUFpubopYJgeraMxwq82 qJU6C09NEw2FAq6OVAxKRKa+ctqxxkip1mx1hhJ4bn/r9cSYIJpIaVVz6NWZferii16XzfrjBpFhc de3QOlJz/ZsVm6LX+Aqh1s9biI/+rJGBMdPY1POYqB0FZASPKLnkiY8XOZX8BCVjFC1s+88NpRXMu Y+2MI7E2z/HlqNKiQbabJZ/JsTSkw/guzdWA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 2 May 2017 00:04:46 -0700 Received: from Hebrews (109.7.6.36) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 2 May 2017 00:04:33 -0700 From: Jim Schaad To: CC: 'core' Date: Tue, 2 May 2017 09:04:08 +0200 Message-ID: <010501d2c312$4e9522f0$ebbf68d0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdLDEZBqa73F8faTQmuBKwLXgCdADA== X-Originating-IP: [109.7.6.36] Archived-At: Subject: [core] draft-ietf-core-coap-tcp-tls message length question X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 07:09:19 -0000 I am trying to decide if the maximum message size for coaps+tcp is pre or post TLS. I would assume that it would be pre-TLS to match with the message size requirements of coaps, however the minimal guidance on estimating the size of the TLS overhead is not in this document while it is in RFC 7252. Since there are multiple buffers that might need to be dealt with, and most TLS implementations are going to have an internal buffer as well, it is not completely clear to me what is being stated. Jim From nobody Tue May 2 01:17:02 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB8212EC3F for ; Tue, 2 May 2017 01:17:01 -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 O45wSp21kS_k for ; Tue, 2 May 2017 01:16:59 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id D866A131485 for ; Tue, 2 May 2017 01:10:47 -0700 (PDT) Received: from WeiGengyuPC (unknown [114.255.40.42]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 0607219F364; Tue, 2 May 2017 16:10:46 +0800 (HKT) Message-ID: From: "weigengyu" To: "Jim Schaad" , Cc: "'core'" References: <010501d2c312$4e9522f0$ebbf68d0$@augustcellars.com> In-Reply-To: <010501d2c312$4e9522f0$ebbf68d0$@augustcellars.com> Date: Tue, 2 May 2017 16:10:44 +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: [core] draft-ietf-core-coap-tcp-tls message length question X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 08:17:01 -0000 Hi Jim, I am not sure fully understood the message and its options. > I am trying to decide if the maximum message size for coaps+tcp is pre or > post TLS. > I would assume that it would be pre-TLS to match with the message size > requirements of coaps, > however the minimal guidance on estimating the size of the TLS overhead is > not in this document while it is in RFC 7252. It is pre-TLS in our implementation which is based on extending CF.CoAP in accordance with the former version draft. The maximum message size for coaps+tcp is determined when binding the protocol stack. By the way, it also is tried to have only one CoAP message format of RFC7252 over any transport facilities. A CoAP message length option is defined privately and carried in a CoAP message of RFC7252. The delimiter of one CoAP message is clear for CoAP/UDP, CoAP/TCP, or CoAP/WSS. This is not a standard. It works, and not many CoAP ACK overheads are felt. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----鍘熷閭欢----- From: Jim Schaad Sent: Tuesday, May 02, 2017 3:04 PM To: draft-ietf-core-coap-tcp-tls@ietf.org Cc: 'core' Subject: [core] draft-ietf-core-coap-tcp-tls message length question I am trying to decide if the maximum message size for coaps+tcp is pre or post TLS. I would assume that it would be pre-TLS to match with the message size requirements of coaps, however the minimal guidance on estimating the size of the TLS overhead is not in this document while it is in RFC 7252. Since there are multiple buffers that might need to be dealt with, and most TLS implementations are going to have an internal buffer as well, it is not completely clear to me what is being stated. Jim _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Tue May 2 03:49:26 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37BCD13166E for ; Tue, 2 May 2017 03:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 kFjX34Suvt8M for ; Tue, 2 May 2017 03:49:23 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D4781316AB for ; Tue, 2 May 2017 03:45:33 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id B067746DFC; Tue, 2 May 2017 12:45:31 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 162E736; Tue, 2 May 2017 12:45:31 +0200 (CEST) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id C40F110D; Tue, 2 May 2017 12:45:30 +0200 (CEST) Received: (nullmailer pid 5053 invoked by uid 1000); Tue, 02 May 2017 10:45:29 -0000 Date: Tue, 2 May 2017 12:45:29 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "Cullen Jennings (fluffy)" , Ari =?iso-8859-1?Q?Ker=E4nen?= Cc: core Message-ID: <20170502104529.dqr3pbmrcmb5wlkm@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="txvs2l7zvonntcer" Content-Disposition: inline In-Reply-To: <492EED56-D406-4381-86D3-5473B8D0D65D@ericsson.com> <9AA156AA-64DA-4853-A9B2-1E8821A3556D@cisco.com> User-Agent: NeoMutt/20170306 (1.8.0) Archived-At: Subject: Re: [core] SenML and its use in core-interfaces (follow-up on bn/n URI clarification) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 10:49:25 -0000 --txvs2l7zvonntcer Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Cullen, hello Ari, On Fri, Apr 14, 2017 at 10:07:11AM -0700, Cullen Jennings (fluffy) wrote: > I wonder why the senml in that draft can not have unique names in the > senml ? On Wed, Apr 19, 2017 at 08:55:57PM +0000, Ari Ker=E4nen wrote: > OK, maybe we can have the call later then. Do you refer to Michael > Koster's HSML draft below or something else? I've talked to Michael and Carsten piggy-backing on a resource-directory call, and it'd be OK with Michael (whom I perceive to be the most active core-interfaces author recently) if that went from using plain SenML to using HSML (moving this from "blocking SenML" to "will need to look at SenML extensions"); possibly, it could also move to CORAL, or the formats could even merge. With that, the whole issue is probably not that pressing any more; I'd still be happy to discuss out the rationale behind using URI names and performance/scalability issues involved with it; if you're still interested, most (UTC+0200-viable) times on May 3rd or 8th to 10th would work fine for me. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --txvs2l7zvonntcer Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAlkIY0kACgkQOY0REtOk veEA6A//eYXrc6LQPdmS1z6VTaAyWns2v5TPxEqekj6NQtWq26iXky49CJJa/y0C 70p5SCaP6Ce6wKVRw5sO0z23pTQfy6C8Om/arDJRXT5W8D+c5hZ6z+pswfeFSzbi S7m634wioLxuoVsczE8ittyhbMZkcZ2RdPV0cPFKasfEHeGQBcHmDcSyRUNvypQw 0g0hD4ovF5QmRN4Fkjt0VzqoiVBTWvht41W4PvWLewzAk6g10Rie9SwNrf7P495f ECQSeF6DfgxQ/nW3zloa9cqyaUISqZy5vbKrowgIg+WAlsjtMJLHDorPPo2rv4Nm 9OQzuBzACPnrjP4vmK4+d7NFOz0hG4yCiaJaZRVw9OR9b0OJYM526lz4rcmp7vYI 6UpDto8W+bp7yUbRexGbC/o2xS8XO1ctUo/SccBbcCmRdBFszXGK/AImofF88mOO 4lr2olwxL8RRsgwmJMymHPrtgQxsbgl0EJ3fw+eO7Cc6FUMzJ7z7NbnTnGpczKSt cuJGlNT5lnBmby0vBbt6pUbmE21mcWya+9s5p/FHv5kMFoftR7c3m/sGGG6futsK JviT5+UXLob8iaJBsiYPbzIwovOAh7roYayxiUCkqHFoMc8Q59Lp/0p+yI6VbjjY lMrsYrZZcpJ8x4TUPvXnvsI+z6AyMtTQWZMfmZhO0fJgNfdCNVY= =enDV -----END PGP SIGNATURE----- --txvs2l7zvonntcer-- From nobody Tue May 2 07:26:44 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E826C1279E5; Tue, 2 May 2017 07:26:41 -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 I8n2dkJQzIB2; Tue, 2 May 2017 07:26:38 -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 9C164131463; Tue, 2 May 2017 07:23:12 -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 v42EMZdm024979; Tue, 2 May 2017 16:22:35 +0200 (CEST) Received: from [192.168.217.113] (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 3wHNmB6Y6zzDHbT; Tue, 2 May 2017 16:22:34 +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: <010501d2c312$4e9522f0$ebbf68d0$@augustcellars.com> Date: Tue, 2 May 2017 16:22:34 +0200 Cc: draft-ietf-core-coap-tcp-tls@ietf.org, core X-Mao-Original-Outgoing-Id: 515427754.313425-a328b40959d63397e5d4f28e27ec5595 Content-Transfer-Encoding: quoted-printable Message-Id: <5858188F-7CF8-4740-8FD8-79189BC3B80F@tzi.org> References: <010501d2c312$4e9522f0$ebbf68d0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] draft-ietf-core-coap-tcp-tls message length question X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 14:26:42 -0000 On May 2, 2017, at 09:04, Jim Schaad wrote: >=20 > I am trying to decide if the maximum message size for coaps+tcp is pre = or > post TLS. =20 Good question. RFC 7252 Section 4.6 discusses message sizes, but never = really comes clean what exactly that means, because it doesn=E2=80=99t = need to. But the progression from 1280 to 1152 to 1024 for MTU, message size, = payload size kind of makes clear that this is the size of the CoAP = message. Which is OK, as =E2=80=9Cmessage size=E2=80=9D is not very different = from =E2=80=9Csize of the message=E2=80=9D, exactly what=E2=80=99s = meant. > I would assume that it would be pre-TLS to match with the message > size requirements of coaps, however the minimal guidance on estimating = the > size of the TLS overhead is not in this document while it is in RFC = 7252. TCP removes the need to consider MTU that much: TCP segmentation is much more well-behaved than the IP (or 6LoWPAN = adaptation layer) fragmentation needed for UDP. On the other hand, there is still a bit of space between 1152 and 1280 = for IP, TCP, TLS, so segmentation for default-maximum-size messages is = not necessary. > Since there are multiple buffers that might need to be dealt with, and = most > TLS implementations are going to have an internal buffer as well, it = is not > completely clear to me what is being stated. If there were an intention to include TLS overheads inside the figure = for message size, this would run into trouble quickly, because there is = no way for the CoAP implementation to control how many TLS headers the = TLS layer spends for one message. You can be optimistic and say = =E2=80=9C1=E2=80=9D, but that is just that, optimistic (or the actual = number might even be =E2=80=9C0.5=E2=80=9D if there is some = concurrency). So, clearly, the sensible interpretation, again, is for =E2=80=9Cmessage = size=E2=80=9D to be the size of the CoAP message (header/length/token, = Options, payload marker, payload). (Note that, for a ~ 1152 byte message, the size of a CoAP over TCP = message is exactly the same as that of a CoAP over UDP message; see = Figure 7 of draft-ietf-core-coap-tcp-tls.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue May 2 12:53:08 2017 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 001E2129C4D; Tue, 2 May 2017 12:53:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149375478596.21455.16152614346903244281@ietfa.amsl.com> Date: Tue, 02 May 2017 12:53:05 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-sid-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 19:53:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : YANG Schema Item iDentifier (SID) Authors : Michel Veillette Alexander Pelov Randy Turner Ana Minaburo Abhinav Somaraju Filename : draft-ietf-core-sid-01.txt Pages : 24 Date : 2017-05-02 Abstract: YANG Schema Item iDentifiers (SID) are globally unique 64-bit numeric identifiers used to identify all items used in YANG. This document defines the semantics, the registration, and assignment processes of SIDs. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned SIDs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-sid-01 https://datatracker.ietf.org/doc/html/draft-ietf-core-sid-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 3 06:42:06 2017 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E4512947B; Wed, 3 May 2017 06:42:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149381892566.21455.3452281823738805238@ietfa.amsl.com> Date: Wed, 03 May 2017 06:42:05 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-object-security-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 13:42:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : Object Security of CoAP (OSCOAP) Authors : G枚ran Selander John Mattsson Francesca Palombini Ludwig Seitz Filename : draft-ietf-core-object-security-03.txt Pages : 44 Date : 2017-05-03 Abstract: This document defines Object Security of CoAP (OSCOAP), a method for application layer protection of the Constrained Application Protocol (CoAP), using the CBOR Object Signing and Encryption (COSE). OSCOAP provides end-to-end encryption, integrity and replay protection to CoAP payload, options, and header fields, as well as a secure message binding. OSCOAP is designed for constrained nodes and networks and can be used across intermediaries and over any layer. The use of OSCOAP is signaled with the CoAP option Object-Security, also defined in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-object-security-03 https://datatracker.ietf.org/doc/html/draft-ietf-core-object-security-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-object-security-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 3 14:21:01 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF63129B4F for ; Wed, 3 May 2017 14:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 wPSTlofAvEFr for ; Wed, 3 May 2017 14:20:59 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 915C2129B73 for ; Wed, 3 May 2017 14:19:06 -0700 (PDT) X-AuditID: c1b4fb2d-b3dff7000000196b-ef-590a4946c6e0 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0C.6D.06507.6494A095; Wed, 3 May 2017 23:19:04 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0339.000; Wed, 3 May 2017 23:19:01 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: =?iso-8859-1?Q?Christian_Ams=FCss?= , Cullen Jennings CC: core Thread-Topic: [core] SenML and its use in core-interfaces (follow-up on bn/n URI clarification) Thread-Index: AQHSwzE592xrEscukkSmVrMDqORATKHi/duA Date: Wed, 3 May 2017 21:19:01 +0000 Message-ID: <5D6788C7-E1C9-4D52-B1CE-A98F29965BF4@ericsson.com> References: <20170502104529.dqr3pbmrcmb5wlkm@hephaistos.amsuess.com> In-Reply-To: <20170502104529.dqr3pbmrcmb5wlkm@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <11CE1B5F0F660F4BBBAC5D8CBC9F8D96@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7rq6HJ1ekwY3/ehbLLzxnsdj3dj2z RcdkNgdmjym/N7J6bN1/l8ljyZKfTAHMUVw2Kak5mWWpRfp2CVwZLbfusBRs56n4c6SugfEl ZxcjJ4eEgIlE04+jrF2MXBxCAkcYJXq2HWaDcBYzSkxfvYAZpIpNwF5i8pqPjCC2iECuxNyu U2wgNrOAhMTZlYdZQWxhgQSJzb+WM0HUJEqc/nyFBcI2kjjWPh+shkVAReLyupdgM3mBZt5b sZ0dxBYScJGY1jkJrIZTwFXi0+qTYPMZBcQkvp9awwSxS1zi1pP5TBBXC0gs2XOeGcIWlXj5 +B8rhK0ksfbwdhaIej2JG1OnQN1pLTGt+yw7hK0tsWzha6gbBCVOznzCMoFRbBaSFbOQtM9C 0j4LSfssJO0LGFlXMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgRG2sEtv3V3MK5+7XiIUYCD UYmHN+ERZ6QQa2JZcWXuIUYJDmYlEd6tllyRQrwpiZVVqUX58UWlOanFhxilOViUxHkd9l2I EBJITyxJzU5NLUgtgskycXBKNTAKVDbcvtNmfbzO8Qh7falM8jf9psfKfEWPzJc5mC1fzOMe 6DH3zQMmvozJtxe1OzF/O7JUdc09XfOdp9LVLn0MmrHR2niFiozKx7eSq074mDx/khZ2Yu/m Hsvr62X6p1QefXx1w1+W1/yVczUK58R+N4vN9fAL05USetdWbNmV/dGwrqVeUU2JpTgj0VCL uag4EQBBhwq+sAIAAA== Archived-At: Subject: Re: [core] SenML and its use in core-interfaces (follow-up on bn/n URI clarification) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 21:21:01 -0000 Hi Christian, Thanks for the update! If we want to have a call it should probably be US-f= riendly too, so late evening in Europe time zones. I'd suggest 16:00 CEST (= 7 AM PST) on 9th of May. Cheers, Ari > On 02 May 2017, at 13:45, Christian Ams=FCss wrote: >=20 > Hello Cullen, hello Ari, >=20 > On Fri, Apr 14, 2017 at 10:07:11AM -0700, Cullen Jennings (fluffy) wrote: >> I wonder why the senml in that draft can not have unique names in the >> senml ? >=20 > On Wed, Apr 19, 2017 at 08:55:57PM +0000, Ari Ker=E4nen wrote: >> OK, maybe we can have the call later then. Do you refer to Michael >> Koster's HSML draft below or something else? >=20 > I've talked to Michael and Carsten piggy-backing on a resource-directory > call, and it'd be OK with Michael (whom I perceive to be the most active > core-interfaces author recently) if that went from using plain SenML to > using HSML (moving this from "blocking SenML" to "will need to look at > SenML extensions"); possibly, it could also move to CORAL, or the > formats could even merge. >=20 > With that, the whole issue is probably not that pressing any more; I'd > still be happy to discuss out the rationale behind using URI names and > performance/scalability issues involved with it; if you're still > interested, most (UTC+0200-viable) times on May 3rd or 8th to 10th would > work fine for me. >=20 > Best regards > Christian >=20 > --=20 > To use raw power is to make yourself infinitely vulnerable to greater pow= ers. > -- Bene Gesserit axiom From nobody Wed May 3 19:30:00 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C7A129443 for ; Wed, 3 May 2017 19:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 NGN9EP9jGC_w for ; Wed, 3 May 2017 19:29:57 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F300E126C3D for ; Wed, 3 May 2017 19:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2129; q=dns/txt; s=iport; t=1493864996; x=1495074596; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bYg6IXaQhV/1fUSWBcWoXvl1BUnFK592yrIt0aa7c3A=; b=WLhZP43fteIYqWWgs0kTR7t2ont/trDhTbMbDK4NTVDRrfzFt2iBMy6w 9PF/E1NJ0i32XrenLxuJovpPXs2QEMyGTwUTCkKKppFETQaJCA+KVzWVd BP3FgLCUY2dTQ9G6Fhwmr3oOIv/V2IltYcjHd0o3BUsruKOJmq6ASmh19 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BQAQBrkQpZ/4kNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQwHjXmRMiGVboIPIQuEaIEQAoRAPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQIBAQFsCwULAgEIGC4nCyUCBA4FihkIDrJ7imoBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEYBYg9KwuCZYRJGoM0gjEFkFiNBAGTE4ICj16IeYs6AR84gQpvFUU?= =?us-ascii?q?SAYUTgUp2h2qBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,286,1491264000"; d="scan'208";a="244021476" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 May 2017 02:29:55 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v442TtjE015090 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 May 2017 02:29:55 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 3 May 2017 22:29:55 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Wed, 3 May 2017 22:29:43 -0400 From: "Cullen Jennings (fluffy)" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= CC: =?iso-8859-1?Q?Christian_Ams=FCss?= , core Thread-Topic: [core] SenML and its use in core-interfaces (follow-up on bn/n URI clarification) Thread-Index: AQHSwzE7nWnxiINeu02FwZuw/afJXaHjYnCAgABW6YA= Date: Thu, 4 May 2017 02:29:43 +0000 Message-ID: <89B55F28-2523-4EBB-ACC2-6CCD756E1A07@cisco.com> References: <20170502104529.dqr3pbmrcmb5wlkm@hephaistos.amsuess.com> <5D6788C7-E1C9-4D52-B1CE-A98F29965BF4@ericsson.com> In-Reply-To: <5D6788C7-E1C9-4D52-B1CE-A98F29965BF4@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] SenML and its use in core-interfaces (follow-up on bn/n URI clarification) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 02:29:59 -0000 OK, this sounds like a good path forward. I am still interests in learing m= ore about the issue and how we might solve it.=20 16:00 CEST is a good time for me generally but unfortunately on may 9 I wil= l be flying. I could do May 5, or 10. > On May 3, 2017, at 3:19 PM, Ari Ker=E4nen wrot= e: >=20 > Hi Christian, >=20 > Thanks for the update! If we want to have a call it should probably be US= -friendly too, so late evening in Europe time zones. I'd suggest 16:00 CEST= (7 AM PST) on 9th of May. >=20 >=20 > Cheers, > Ari >=20 >> On 02 May 2017, at 13:45, Christian Ams=FCss wrote: >>=20 >> Hello Cullen, hello Ari, >>=20 >> On Fri, Apr 14, 2017 at 10:07:11AM -0700, Cullen Jennings (fluffy) wrote= : >>> I wonder why the senml in that draft can not have unique names in the >>> senml ? >>=20 >> On Wed, Apr 19, 2017 at 08:55:57PM +0000, Ari Ker=E4nen wrote: >>> OK, maybe we can have the call later then. Do you refer to Michael >>> Koster's HSML draft below or something else? >>=20 >> I've talked to Michael and Carsten piggy-backing on a resource-directory >> call, and it'd be OK with Michael (whom I perceive to be the most active >> core-interfaces author recently) if that went from using plain SenML to >> using HSML (moving this from "blocking SenML" to "will need to look at >> SenML extensions"); possibly, it could also move to CORAL, or the >> formats could even merge. >>=20 >> With that, the whole issue is probably not that pressing any more; I'd >> still be happy to discuss out the rationale behind using URI names and >> performance/scalability issues involved with it; if you're still >> interested, most (UTC+0200-viable) times on May 3rd or 8th to 10th would >> work fine for me. >>=20 >> Best regards >> Christian >>=20 >> --=20 >> To use raw power is to make yourself infinitely vulnerable to greater po= wers. >> -- Bene Gesserit axiom >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed May 3 19:32:45 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459F11296D2 for ; Wed, 3 May 2017 19:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 vAOY9zKhEk9z for ; Wed, 3 May 2017 19:32:40 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8695C12960D for ; Wed, 3 May 2017 19:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2384; q=dns/txt; s=iport; t=1493865148; x=1495074748; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hZ/U6V1gVV0rkurgsRqxG4LVciZyyvEDYaCoJfAPZPc=; b=flpxIjdmMxxpkeotnMr4kNDaWsMy4iU3O62gsNnP0ZkR8D5/m/8rGZY4 +tnewuvt/C/A1Xc1UYNJ541I4ItuRfN3s1Qn3LfHZKfz6EZhdXXxGbsNJ FZlwaqF6V/+V0eJK26rUrQ2Q8Z1Cs2H3IP9ksSbw66yXtv1ccJP8JRSYv A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DWAQCJkgpZ/49dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1ViegEBEAeIOoU/kVOVboIPIQuEaIEQAoRAPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUVAQEBAQIBAQFsCwULAgEIGC4nCyUCBA4FihkIDrJ7imoBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYg9K4JwhEkagzSCMQWQWI0EAZMTggKPXoh5izoBHziBCm8?= =?us-ascii?q?VRRIBWQ6ELIFKdodqgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.38,286,1491264000"; d="scan'208";a="421582563" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 May 2017 02:32:27 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v442WQbw013516 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 May 2017 02:32:27 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 3 May 2017 22:32:26 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Wed, 3 May 2017 22:32:25 -0400 From: "Cullen Jennings (fluffy)" To: "Cullen Jennings (fluffy)" CC: =?iso-8859-1?Q?Ari_Ker=E4nen?= , =?iso-8859-1?Q?Christian_Ams=FCss?= , core Thread-Topic: [core] SenML and its use in core-interfaces (follow-up on bn/n URI clarification) Thread-Index: AQHSwzE7nWnxiINeu02FwZuw/afJXQ== Date: Thu, 4 May 2017 02:32:25 +0000 Message-ID: <0084DFA9-D26B-4ADA-AFA1-B5F617DC14CA@cisco.com> References: <20170502104529.dqr3pbmrcmb5wlkm@hephaistos.amsuess.com> <5D6788C7-E1C9-4D52-B1CE-A98F29965BF4@ericsson.com> <89B55F28-2523-4EBB-ACC2-6CCD756E1A07@cisco.com> In-Reply-To: <89B55F28-2523-4EBB-ACC2-6CCD756E1A07@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5D52E56C59557C40BB7D1DD20934352C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] SenML and its use in core-interfaces (follow-up on bn/n URI clarification) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 02:32:43 -0000 > On May 3, 2017, at 8:30 PM, Cullen Jennings wrote: >=20 >=20 > OK, this sounds like a good path forward. I am still interests in learing= more about the issue and how we might solve it.=20 >=20 > 16:00 CEST is a good time for me generally but unfortunately on may 9 I w= ill be flying. I could do May 5, or 10. Oops I sent that too soon. Turns out I can not do the 10th but I can do the= 11th.=20 >=20 >=20 >> On May 3, 2017, at 3:19 PM, Ari Ker=E4nen wro= te: >>=20 >> Hi Christian, >>=20 >> Thanks for the update! If we want to have a call it should probably be U= S-friendly too, so late evening in Europe time zones. I'd suggest 16:00 CES= T (7 AM PST) on 9th of May. >>=20 >>=20 >> Cheers, >> Ari >>=20 >>> On 02 May 2017, at 13:45, Christian Ams=FCss wrote: >>>=20 >>> Hello Cullen, hello Ari, >>>=20 >>> On Fri, Apr 14, 2017 at 10:07:11AM -0700, Cullen Jennings (fluffy) wrot= e: >>>> I wonder why the senml in that draft can not have unique names in the >>>> senml ? >>>=20 >>> On Wed, Apr 19, 2017 at 08:55:57PM +0000, Ari Ker=E4nen wrote: >>>> OK, maybe we can have the call later then. Do you refer to Michael >>>> Koster's HSML draft below or something else? >>>=20 >>> I've talked to Michael and Carsten piggy-backing on a resource-director= y >>> call, and it'd be OK with Michael (whom I perceive to be the most activ= e >>> core-interfaces author recently) if that went from using plain SenML to >>> using HSML (moving this from "blocking SenML" to "will need to look at >>> SenML extensions"); possibly, it could also move to CORAL, or the >>> formats could even merge. >>>=20 >>> With that, the whole issue is probably not that pressing any more; I'd >>> still be happy to discuss out the rationale behind using URI names and >>> performance/scalability issues involved with it; if you're still >>> interested, most (UTC+0200-viable) times on May 3rd or 8th to 10th woul= d >>> work fine for me. >>>=20 >>> Best regards >>> Christian >>>=20 >>> --=20 >>> To use raw power is to make yourself infinitely vulnerable to greater p= owers. >>> -- Bene Gesserit axiom >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 From nobody Thu May 4 06:20:40 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3E212932A; Thu, 4 May 2017 06:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 s2gbvFu_E7eQ; Thu, 4 May 2017 06:20:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 85DE7128B4E; Thu, 4 May 2017 06:20:32 -0700 (PDT) Received: from [192.168.91.191] ([80.92.121.214]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MfVYB-1dPJnR059P-00P8MC; Thu, 04 May 2017 15:20:22 +0200 To: Jim Schaad , draft-ietf-core-coap-tcp-tls@ietf.org References: <010501d2c312$4e9522f0$ebbf68d0$@augustcellars.com> Cc: 'core' From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <05f09ab0-77ec-1ace-b713-5d6f808528c7@gmx.net> Date: Thu, 4 May 2017 13:17:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <010501d2c312$4e9522f0$ebbf68d0$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GCTNEF3m2pCTHC810nRvilwn6pVb1B6ut" X-Provags-ID: V03:K0:BdSVZlRh67W4UEUHIFPNwR4sJbDVVlT5itiwegN1PX1h1MpFnAy b/njk+g9dqhhDFMUNCSDcGDSQHOLLRjh4gEe3dhSMVMhMKXqhcuJOwpfxzZWIcDB8bgkLKS +3xrUYOJXRL70pa/xvMklqKPCqVcSFR5k+d1YnDIKYLJEiO7roOBt7xFKSjzIdB6/kWFzBZ 1blgw9sTnvBfJuEp9X50A== X-UI-Out-Filterresults: notjunk:1;V01:K0:A/d2pf5JZZ0=:SNxF09uthsKFCWkcO57tL0 en5f5Eeq1lkX76bzNhRbBBd8uaLJJ33GF6SPJRpxo5lle09YZ3Oqqd9C1Dcg/ZvgMnXMKcytC xIuq+cqNqu2+EniG8csdPSFd+rcVosrPEXT6y7Z3JcG51FxFV6h0vUWpbRnPXpZRyJRhjS8Ln a7uDxYeOGX/bOZFZriXwNSWHm7wAI7OYNP3PAIebkJ3xDhGq5B3zraZ4hZnTBwWKBDkupWciB MCDHGvzo/59cTgp41JSyCLpg5nnQGCLlxYn8HN/Dw1teWICZ1j55LRzxZkeivSzUGXukCUT0q XNzeAwVf5Dr1kV04iZdY0AhLCS+MP844pXhRdsbLC5ADD7QeK7bbJUoWMvYDAGrrPWDbP27uk LVycQtZIHSLae3Y0UoyTtOsaFazOkM0m7cv75ZQH26nlClh1YchZ4ljGcz/upzRU0j1VfSiPU HT9npXfcgOXcq0wTUgTf45S3WcQj5EFqgRTvbo89TOXyK/hOTc//NX9S8dGY2EdaZUW6s8PIV H4TFTVvXNDPg8nD/LKKFmDxwI+GtX35sMCpLo4Yp/RGSvAjv6AYxmDt2WpBj96GS+vaxft/X9 IxJtK4DnlQnCVnhN4gwQrbATADNR5clTixvjSspZxvlS7S2j8PbFNe6Cj4OJyDNw4yKbxbyq/ oh/mAdEMO6r/Cf6aE5hi+0AbG+C7NFLvhRFtAwZ1EorMJ816tSukKuHUUTe8QPcvCAxhKXa9o ztxke7DXT4nOZBnN2EQlV78gf+D4ZOtXxwP6d7kpw9mzBE52wXe4MxE4vL4= Archived-At: Subject: Re: [core] draft-ietf-core-coap-tcp-tls message length question X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 13:20:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GCTNEF3m2pCTHC810nRvilwn6pVb1B6ut Content-Type: multipart/mixed; boundary="R12R4T7Hq1k2op5SpTJ5l4QSaGwp6AGOF"; protected-headers="v1" From: Hannes Tschofenig To: Jim Schaad , draft-ietf-core-coap-tcp-tls@ietf.org Cc: 'core' Message-ID: <05f09ab0-77ec-1ace-b713-5d6f808528c7@gmx.net> Subject: Re: [core] draft-ietf-core-coap-tcp-tls message length question References: <010501d2c312$4e9522f0$ebbf68d0$@augustcellars.com> In-Reply-To: <010501d2c312$4e9522f0$ebbf68d0$@augustcellars.com> --R12R4T7Hq1k2op5SpTJ5l4QSaGwp6AGOF Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Jim, similarly to Carsten and Gengyu I would argue that the message size refers to the payload of the CoAP message since this is something the CoAP layer would know. Our mbed TLS stack also provides information to the application about the level of "expansion" due to encryption but then there is potentially also padding involved (although more theoretically than in practice to conceal the real size of the message). Ciao Hannes On 05/02/2017 09:04 AM, Jim Schaad wrote: > I am trying to decide if the maximum message size for coaps+tcp is pre = or > post TLS. I would assume that it would be pre-TLS to match with the me= ssage > size requirements of coaps, however the minimal guidance on estimating = the > size of the TLS overhead is not in this document while it is in RFC 725= 2. > Since there are multiple buffers that might need to be dealt with, and = most > TLS implementations are going to have an internal buffer as well, it is= not > completely clear to me what is being stated. >=20 > Jim >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 --R12R4T7Hq1k2op5SpTJ5l4QSaGwp6AGOF-- --GCTNEF3m2pCTHC810nRvilwn6pVb1B6ut Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJZCw3VAAoJEGhJURNOOiAtOikH/jwY1LgAQNKC9Cx8jzrlBHkn 29VXwQyaU9qvv3M/rOC7y38iHYx6+VQOQzM/GSJs214dtRWDztN8dHei6fV9HIe9 ++yxgWfaC2ikNWAk8LldlmAuv7haJ7WBx2mmRtC8Vg4WLgbSSM+0vDGmiIHkm2bI 4Ljkp5rfYnurLuAAZ2DzexigUR9SRDZziGLbFuC9effcvN1zq5U0hiGKk46zyA+t 4aWQMBzpt7M5mItiRKcs6P9gUBT8uhpDIJevorpC4djxX2YGJ/IrEJdc7aia25UL ZFW+Wb8g13kx76Ys8FRrZvdmifKA7ByV468rxJA9UzJsTCwgEHXgeOOb8HnjnE4= =H/mb -----END PGP SIGNATURE----- --GCTNEF3m2pCTHC810nRvilwn6pVb1B6ut-- From nobody Thu May 4 09:08:41 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC7A1293D6; Thu, 4 May 2017 09:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 aZLIb4V3MVMy; Thu, 4 May 2017 09:08:37 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 01A8A1286CA; Thu, 4 May 2017 09:08:36 -0700 (PDT) Received: from [192.168.91.191] ([80.92.121.214]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LyEJp-1eBDuh3fpF-015Yn6; Thu, 04 May 2017 18:08:35 +0200 References: <3f78f14c-f050-1f1b-1564-400e23f80d70@gmx.net> To: "Ace@ietf.org" , "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Forwarded-Message-Id: <3f78f14c-f050-1f1b-1564-400e23f80d70@gmx.net> Message-ID: Date: Thu, 4 May 2017 18:08:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <3f78f14c-f050-1f1b-1564-400e23f80d70@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7rVGcREMFpwUEOtqGnhowAwAbIstGIov6" X-Provags-ID: V03:K0:fMCpQ/ny3bRNn1+4+HnQWGXtY5HHA6ut5Dgko+fBZzQLOTql8XQ 3m6yODwRkk/4s0pmxtjrm51uoQOAIXVVsqjDLanwdTsjeiFtCq8Y8QcF6s47+uOZJE+W7HS ON/WZxFVLdKmcaWXvJEIaAREgydTs1901cihcRcNWtYsZNdIPvizEO2l8ms8OPS5ZyG2yhz gwxBsaKJu6andDlx2/bqQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:Svl1yC57th8=:osTpTA3wQD8eOjVALumgln 9hjxZ5EVuR9SllrlCF+883PR+QGWmshvAqlZO9NPG9NF+teJEbLms8MZNXJjj7oucQn+Yhlss x9Gzgqmf2kYSxV1KSn4lBpiOMOC2TDnHZpM9obwVlsS5nwBUjYnlhyr0RE4XE/jSpWsG8Syt1 cR6j5As6IGdQrF0hIwjKbm6Ima209UEMz81v+LFU9P/wnmPBA3xN9KxzR9P4o1Vh5GFAgvdHj Rk+EQPUVnbjPDGqeAaFrumyEHPZkzt0YmnV4pVuEEbyuGcKyGKLIbKPIYWfc2PmOqlgvEYipv MnW+gf+KDsVVQp0c5DYqvp1JAR3C47LigQBrXJ2jZGhqd3f/mW4S0zUBVJZoDs9/CFvl7YB7U 0akaT/gqI3rKqrJ+JkvB3mhE2VSDPoExnRAK861wZiO3CoA2jhn0G9NCrtGCrPMTtnh8ycA+8 e+9HNMwXLxM+vXkDpww4CplZ2YoZPra3OZV8GLDhh7lieSZSBI8SgNmqcT7oRlsvPSLpVXbV/ Bp4uNvRC1cwuu2GTz+nOS3DjmekjvZ1nmy39GaecL3U5010Wrd55saifFuYJGgEL0zFxGo1+l XFsOS2EimlZkkynwxVtOwcqt11Z09a6nkfR4tYlM24h7HNJMNdOW1FFHgrWWQlmXCqq3GRG09 ee8LX9mwv50X+CnZOtIqzqeh4Exg0FwZBd9ygYq7oypPcRmm7mU4FkgquFTJ6M+RI377UhIFS 6VsAc26r+yI5xHscpmnAzdojfOzMFEsutpDCyI4PHt5hj2Q4JRi3kKaEQhE= Archived-At: Subject: [core] Fwd: 2nd OAuth Security Workshop X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 16:08:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7rVGcREMFpwUEOtqGnhowAwAbIstGIov6 Content-Type: multipart/mixed; boundary="ewhmCM1u9J4OAKBlLJRgrr2w9GTKasWrD"; protected-headers="v1" From: Hannes Tschofenig To: "Ace@ietf.org" , "core@ietf.org WG" Message-ID: Subject: Fwd: 2nd OAuth Security Workshop References: <3f78f14c-f050-1f1b-1564-400e23f80d70@gmx.net> In-Reply-To: <3f78f14c-f050-1f1b-1564-400e23f80d70@gmx.net> --ewhmCM1u9J4OAKBlLJRgrr2w9GTKasWrD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Forwarding also to ACE and CORE because of the relationship with OAuth. IoT is in scope of this workshop! -------- Forwarded Message -------- Subject: 2nd OAuth Security Workshop Date: Thu, 4 May 2017 18:07:43 +0200 From: Hannes Tschofenig To: saag Hi all, I would like to draw your attention to a workshop on OAuth security, which is attached to the next IETF meeting. The dates are July 13-14, 2017 in Zurich. Here is the necessary info: https://zisc.ethz.ch/oauth-security-workshop-2017-cfp/ This is an attempt to bridge the gap between research and standardization= =2E You are welcome to join the workshop. Your input is appreciated! Ciao Hannes --ewhmCM1u9J4OAKBlLJRgrr2w9GTKasWrD-- --7rVGcREMFpwUEOtqGnhowAwAbIstGIov6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJZC1IBAAoJEGhJURNOOiAtfBYH/itIQBBN4fAFXq/CeDoeO3/z qJtPsnhqy5XIeI9ckhYcdBPmMbdKNUbpuekcU46swxyRgSIDlKA41b3dTGN6tFhg XUf/Z0+mSUYf/wxsiSGWqsqwp7nrNxwyqtCL6qNn1OPlb8K8hfbWJYAL2JTQcChT tgxtEtWVFW3GRNbIJ8ak1OV+Mowa/uvginV9uVJEUnh0SyOAPAi4GU65WaIgJclR 7yNhNIO3wWTNYybAMIj1DFBYz0EMiYxDshEmuEvS4qBfRY4OxKJEAuqqZ8XAiTMs fyUBs4ModfSCVSWPIg5Fg7VMM/32AoFVBH85lOH3MvPEMHPLX3JgIEeoAIt/d4o= =mLKf -----END PGP SIGNATURE----- --7rVGcREMFpwUEOtqGnhowAwAbIstGIov6-- From nobody Thu May 4 09:30:27 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905C41294F3 for ; Thu, 4 May 2017 09:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.onmicrosoft.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 0HPDpuIksDOx for ; Thu, 4 May 2017 09:30:23 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0108.outbound.protection.outlook.com [104.47.0.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA2B128616 for ; Thu, 4 May 2017 09:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BvvLdUFxSYRR8tYkfP+FT+kVSR3ipU/lFoqJVMo/ycI=; b=mfnVfJe16P07I1Zhkjs4ZJG25KuQ/g1Mv7pq8a0+rJyt9ew376hOilKjWLuU+G5O1rOZoJKO2ju3UwqkQZBlWCZe/qYexDd885Bo5fCsDEWtLHFsVJ/EcrzJrlGMk7aeSfrvoE01iX7WmmiAyOT9/aRnRofYF789bj1iTfcpz7w= Received: from VI1P122CA0004.EURP122.PROD.OUTLOOK.COM (2603:10a6:820:2::18) by HE1P122MB0025.EURP122.PROD.OUTLOOK.COM (2603:10a6:23:2::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Thu, 4 May 2017 16:30:19 +0000 Received: from AM1FFO11FD004.protection.gbl (2a01:111:f400:7e00::182) by VI1P122CA0004.outlook.office365.com (2603:10a6:820:2::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12 via Frontend Transport; Thu, 4 May 2017 16:30:19 +0000 Authentication-Results: spf=neutral (sender IP is 23.103.228.36) smtp.mailfrom=philips.com; vanderstok.org; dkim=none (message not signed) header.d=none; vanderstok.org; dmarc=none action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 23.103.228.36 is neither permitted nor denied by domain of philips.com) Received: from 011-smtp-out.Philips.com (23.103.228.36) by AM1FFO11FD004.mail.protection.outlook.com (10.174.64.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.9 via Frontend Transport; Thu, 4 May 2017 16:30:19 +0000 Received: from AM3PR90MB0097.MGDPHG.emi.philips.com (141.251.117.145) by AM3PR90MB0098.MGDPHG.emi.philips.com (141.251.117.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11; Thu, 4 May 2017 16:30:18 +0000 Received: from AM3PR90MB0097.MGDPHG.emi.philips.com ([141.251.117.145]) by AM3PR90MB0097.MGDPHG.emi.philips.com ([141.251.117.145]) with mapi id 15.01.1075.010; Thu, 4 May 2017 16:30:18 +0000 From: "Dijk, Esko" To: "consultancy@vanderstok.org" , Carsten Bormann CC: Core Thread-Topic: [core] Resource Directory: Simplifying Domains Thread-Index: AQHSugIoVokwIT4YwUqXPWdHbAWFSaHPZwQAgBUKTjA= Date: Thu, 4 May 2017 16:30:18 +0000 Message-ID: <0bd0cd5aac2e444cbb625afc688f1c5f@AM3PR90MB0097.MGDPHG.emi.philips.com> References: <2688B534-A979-42F6-AC33-925817005F80@tzi.org> <75dc1a630fca3fd2e50fe13f867cb85b@xs4all.nl> In-Reply-To: <75dc1a630fca3fd2e50fe13f867cb85b@xs4all.nl> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.95.87.52] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 28c3d776-6daa-4534-4cdb-08d4930ada8f Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OrganizationHeadersPreserved: AM3PR90MB0098.MGDPHG.emi.philips.com X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:23.103.228.36; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39850400002)(39840400002)(39860400002)(39410400002)(39400400002)(2980300002)(377424004)(199003)(13464003)(189002)(374574003)(85714005)(9170700003)(7736002)(4326008)(53546009)(5660300001)(102836003)(305945005)(50986999)(50466002)(6116002)(3846002)(24736003)(54356999)(38730400002)(23676002)(86362001)(33646002)(76176999)(105586002)(53936002)(47776003)(106466001)(189998001)(8676002)(2501003)(7696004)(108616004)(2900100001)(2906002)(55016002)(6306002)(81166006)(229853002)(478600001)(2950100002)(8936002)(356003)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1P122MB0025; H:011-smtp-out.Philips.com; FPR:; SPF:Neutral; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD004; 1:F3Unw5YzbQ3/UYYYv1Y6pB4ihsqQfNcI/kY5tBiD1IwB73ok0t8sQxS5/0XjdNDeDSkQ4ol0fcVRI8q6UoJR6s2+CJCSgF9zXeTauKASgM3TNmtTZlBLO1hchrz9JHjxYComnkP2d+9kusI987YDUFdSBFa/RgDztAS9r0SVA9SKZsm0iL3S71sIG0wlpa7TvHKz0UBHYTsN+wXravjtJJHuhKZILP7+rSZJXCkXOYqxLrGwUjSod8s1S5P8721FW4f9GGp+PvrwqfJDqnR1pe7FFyyXcWJ7jYfyFQu5Zn/Gex2bFlY8hc9HDwljymCFy84g10Wd74pDQZ/wHfi5kZb/SHrq3fiShcdzxZRNIeBY6abbP4v0qsqd/h7UaBW06Au6u197TfsYL/JF4vjeCG4yC5NkUg0SZRzD6UDbq/Yk95l1VSb0LTJ2xl1rknvE+4y7JuB4/3n0iprdlPwyOc45aryA38uR1tyaGPVubmFgbc2ZOdrGI89N6V67DFvU X-CrossPremisesHeadersPromoted: AM1FFO11FD004.protection.gbl X-CrossPremisesHeadersFiltered: AM1FFO11FD004.protection.gbl X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:HE1P122MB0025; X-Microsoft-Exchange-Diagnostics: 1; HE1P122MB0025; 3:BQ5JhDM8wrWe0xfk4xZ2lNk0gsK2+MnzmWd5MA6SdeUIjBw5KuNDgh4bfO8/f6wXnyCOiJydJk0sumxI/9Qyh5enjJSp5P7V9ydKuX2aefI8hLToMex1pY9nZ2M12gBPBBXt/oiwXVIKc/FXVnKR9YtykRwTbaAnr2J1muXlHwfMOjp4JfojLGg9KOIBPQqIQ43PFQ0hcmrnkmIoJHDJ8x8Ou60kcIHSf7hjKLerNBT0R8k/cS7bisMLDMwGYZX7kS6w3LQ9NrYjIefRiczCbWQCdKCRfOptko7qsyMMdC9JOPDzOh50RgiCzpKB4w9AWTFcyPUifBrK4bWerS79rnuAGmxCYx061eHn5qV4OJtsH/CUeyRzSYHbLglWYIBs6zqYgJBkj3OFr/B1QA+7blIjykBQOzXirI+IMVM11RYrXU/evZSy8r5xuluZXbZ/DodGhgDFYFMD/piWIxq4eaToMhYGXkZVD1ce/MVf8aDBDrA/fcGyfDFY+w6j1z5N X-Microsoft-Exchange-Diagnostics: 1; HE1P122MB0025; 25:P2FeLaBIYmVYzoUcI/LAll6Tjsm2ZEwRXuawgM2IdTA6UPi4JDXOg0j1M1145NCrF0I11SqJ7jvpYmGEW5iB881UGmvWoafRororQqzAAY+Os5PyzCB3OBYHITJkkF7vZhVjje6GlUCcDGPb4V9iigh3smFTYup2TnBY5F9fzxg9c0ZxopophzbRNj0lCf0p6YDP3dCRrxbvIpMULVEFDE/VqcCq5MXtrZ5KqR+KsglOZGNjUVw2S9l0NCQOWAyaga3bPLVW4zPV6eQ3t1j10OpHK5t176LlvOuawZjJvlWrWFRA+wJibSrRXAVpdki2Jj7ZHz0zuQlsalTimhTjoD2SYx7e3wfHxLfrhsoYhfxBisXOTe7Q9MCoRACt9KuXGoQLraUzthgXILXfNXa2rSidHK/HzLvr2FH8p/iPpRcWEFwoD5bR3vb3hkj2jvG7kltuVFynkEeZsxl7cphB2g==; 31:42g7kkwSzPDVRp2Ynjq6M54GleeQGLSeri1kO7aK11n/kdXoq4qwYSyhrx+bKY3i7RnnS7+8tPrJpjhPqMO+TjnSXzJNHS7Qe0a6E53y5o4z3TlKWZKQRib1NpsWuR7kHCRJlc7sgIy/kQwX4ruoENjNevOJIo+sCK7e+ldCtYQJtt64Q5QNlz/Sl87GhhpdIKkDgfWRKMu6XjaZxJ6enc93CIux+0GSoCDFmPyUpfSmEm7qfq62idJ7byZdIQBExcHWdt9t/QzjiYnKip8aY9EO05IwNQYUY4tEzCYXpMU= X-Microsoft-Exchange-Diagnostics: 1; HE1P122MB0025; 20:kkkJvr35+oYbrkWWkGMHppYy9nGRRV2VyHXjVosbshGZnkFGIgR4JY4vjiC32UGi79USdCVPTKa9TeIQWGz4bIH3H8BF3dYaoh+FhX1J/vmNvApVErR9kTs0ggPnkabAiv3iSTrbLmQQmaXn2WZ6Xh+TEixlm07CDAYjHCdMuyWm1bO4m97zWKU9QnQdMr6M/QhaJcSWHeTZl/JvY2vjTwy/CAHe6zhMXjSYt+uM8tjjallEO9ebZ9g4+nbiIYQisxeMY8c1TWO46MBQJSTvFGrnDPwoQAVGSl7r2Pbcaeg+XEoZrX/Lk8A11hIvMILmfH109AiGNDU+ubtc0uTtz7+H5yUO/9jS4cMuO9vcYreUm9M5a+BrDHvyWKMIi/E7sbK6JSVzwxqcHc0eo1l4K7jPwrymNDhwVBH69/Cot+oig2NkVlXCmpWKknF9ta6EYYM1XoyjrGllm/jhg0HmR8NwCxTCgnHJ/JZ3Mv0sOf4m+CkTZXougDtPf/4rnhUM X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(13018025)(8121501046)(13016025)(5005006)(93006095)(93003095)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123558100)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:HE1P122MB0025; BCL:0; PCL:0; RULEID:; SRVR:HE1P122MB0025; X-Microsoft-Exchange-Diagnostics: 1; HE1P122MB0025; 4:7QiAHQ4p0bogkh53sWdFJj58U8E0QwALxUPoSFQWr+5b5brYVutdwSq48zUr//UNriTXIIGdAkuZbw6M59A/2OY2Jz0m4/X/wm3eXmG6B2XgYC/SVSzTYXMCu7JxzGnBXIGnZ9rzwXlSS0WP4wkhEYhcTGcP9RuhSHkJBSb8e5mH7urAydvPToMYBz8g+fIQaggszobfTGwJzQz383BpF7C9zWcuy6Ves2oXGo+J7Anv7xJILXT/NU9tyw2PWnMgN9UEY4B8SbpyKQeQPPNHQhzcOqM5WswLX24xZNmCEOLX7G8l+QK9ylnrcUmA8ZjGAKCk2+WHWATRk+wFuUV5hq25nxkNzvLrIoQeboy0eg2Ytl3PweNui9ktPEyEvDnNzbHcoD8EW8GFBsocBzAjapva/praLtqXQgq2Oe0TSpgSclSaGPUHs7/hzg+jKBA+4EllFt+DUn3tSLiNSXCandPYwNFVLUGdmx+UznPwu4rsVTSOXE1DI7LQbqn9S3nKvhZcaabo1NKiWt8BvE4NaxAPF8n6FgZ92m4YZT4iDFWsQAkeAvt8MTtHNamtFMmnTVq5kOZRGS+AshbiUK+EuQCJuNEB9RTu5rchDkFMgp0Tvq3ojoHbpOBjU6p+KyEpKgT4JHq9ki37wDqO9fsio9ju18s2Cq1VbAW8AmoBL162i1a2Ogpk9YoYabsE1VndHi81dGVl5bjMh0qlU+VTeyH9ooser8ekvUchDi1RKQskhrDjDs0thXB4hSdUWNbHXrUjiVhp4Xl+e8qIVc6hvU3xSCJxHWrppVnbyAGp+nC33q/P1DMFQP+yopvrRw66LyF264SvOSXbKho0Dd6ozA== X-Forefront-PRVS: 02973C87BC X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQMTIyTUIwMDI1OzIzOlhPdWw0OWhGZTljazB2dXhBc0dTMDhDSlIz?= =?utf-8?B?SnhmZEdaL29RbTJaZDBQejZBR3QxMUo0L0lrNzl2Q3ozbTdhcW1ieFVGYlVI?= =?utf-8?B?eVFOcTh6WmFnOHhWNzc1aTdjK1g0R25LZ2ZoYm5KT2x6L3k2RHA1dVZYUHpw?= =?utf-8?B?TFlFRXlPWTNKOHV4RVZzakxIOE1Kc2pNNVRVa25TeVJ0blFha0lJQllscHRh?= =?utf-8?B?c0Y0bWdsN3dMblZ2TnRMVDZzYlAremQrOW0yS2ZIT1dCNEJ6UjJ3c1dLT1lO?= =?utf-8?B?a1oyaWNaSVBSOVdhcUdjWG5TSEVUSFVFeUh2N1JydG16U0x2K3ZuOEpZekF2?= =?utf-8?B?bkZIT0dieEw4VEIwbmY4TC9aekVmaFBGTGNjVVBadjRiVElCcXhzcytEUEpZ?= =?utf-8?B?TjNxUnJaNkZsbTd6SjV6SUtMTzc3SmphWXpxS2RsZGF6c2RFR2dZMlliWDRM?= =?utf-8?B?TVBid3YreUdqTFlvVDl6MkFQRWZ6Rk55N3lvUjU1d0liMkZmV3M4dUVBNk1Q?= =?utf-8?B?TnVRaEJkT1EwRzEza3Y2Z0l4dU1uRHhPcVN2QUVhQWFXZnRra0laR1dGeE5a?= =?utf-8?B?SGVXZXBHQjNIM3I4N0dFL05tR3diKytNbEVGRExINGV6VzdXRW42T0hUZUtC?= =?utf-8?B?ZWtvSWZ4SU5LR1V0MU9hbkY1MHdBdXJ4YUp0SVczZFh1bFpRZVJhQ1A0cGZ4?= =?utf-8?B?YUtObGFqTVdkbDQxVFZ3cStNekl5ZlpyS25OUEdyWnh1VWpCd1RmK3E2Q0JT?= =?utf-8?B?NDlJaDhVQzdWTHNJOTRYL2VtY2hJVUlBQ2pPbG9uNlpYTWNWS2poZzFKNHUw?= =?utf-8?B?akZWTWtWUHlYRVlTS2hEY2Q1MHlrSUtteWNIOGY4M0ZVRExpM2ZLUmpRek1F?= =?utf-8?B?UFFQVi9qVzFLNnR1QXY3RUJZamtGcm9CQ2QvOHUwYTNnU1QxK2ZBL0RvSkVa?= =?utf-8?B?NGY0RUxKVlBETkREOXlMSUhlUnJ1ZFdrWkVEeGszei9jSjN5aFl1dUFadGg5?= =?utf-8?B?bGc2OGxiOGJEWHREbHRienJBT2J1Q3cvTFFXRXVHT2d3anpsSWdIMnFwY2RF?= =?utf-8?B?dDFpb0Z6ZFJsMkRaYThBUTV4K29qVlMyNGRWUUg5YmRVWExIbDNXUk00Z0cz?= =?utf-8?B?Sm1TN2JobGNUdERUc2plTnkrMW8vdzhUVG1tamlZV0Q4bUcvMW04cDBVZFJu?= =?utf-8?B?K2d5MXhZNVJoMXk0OER0cUQ4djZtQUNJUDJBSkZhN1A0cGdJeXZPbndRemgz?= =?utf-8?B?Tk0xem4yaXRIamdFSWN6M2ttZEJ0WXFlbVB3S25iTHF6TnI5SS9JcE5qL0E3?= =?utf-8?B?TjlGSGQxRTJCbExZMmhDYVlXS2ZFMm1sTXlGSStwL0xTaU96QnU2TzF0Rk5o?= =?utf-8?B?azA2V3BXSFBiSjRrVlFGKzdiK3k2S2c1WjAwQU9lRkZmMjJyZUFyMVN2NzdD?= =?utf-8?B?SlBRT0RJaUduVTN2cnpzRFlFeUcrUnhaVEhRa2Y4NmdyT1ovNi9oS2RuZXB4?= =?utf-8?B?NU9jVlRyMGdHWjZ3L1NVdS90eEgvdVJvbWdqRjdXeEYvNzVGZXhKUU1HMGtl?= =?utf-8?B?dzBpV0dkdlVGK1k2blo5VVIycWw2TWtzaFFLUnY1U25SRXNROWJUZjA5TVVo?= =?utf-8?B?NGdBV1ZndENaTmFISk9UeFU2aDc5RGVNWDVuQ3VUYlhFNysrYWxMNUEzWGc5?= =?utf-8?Q?6jKxtUwhhpZ97xnrVh/sw/c48wuyYLhruv6K3sX?= X-Microsoft-Exchange-Diagnostics: 1; HE1P122MB0025; 6:nWjaCAZT+zCzStUp7rCW0dBm4zHJLXLaotXjLwWqbvmjbf8tDarGr0fPMfL88kRHZEYD7NNFM5eBeRfRQGuig+IMir5BXDrSM3XbqF0v0hdifTxzHvxEpaAIrr+7CyLUEaIA/udcOh9aT1q+LClBznntGgfJAdm7Z728cNgjoOjiMRm6q8GSEOinNqA3NWKZuCsg5boMBTXJx8mxDgH6Fp5AWOI66jvNQZnhc/amm0CcnbU/ZfHyMMse2VmxOughQhrbGCwWjKuD9LPu8IaA7foC147LwVtTLHTXHjCzAYkx+62wJUdZLXBymmmP2jbGizZXq62QoE8I3tNCiThx4ZFYzaAfq8zrmA6ThzkOp5orCfpieGSQe2WyBLeifVdxUIf3YDT5OCUptIZFrxjGTMrDwNn+gvZlQpCgMSKSS7rl3wEZIpqRiz2tR6DxWlEp13DiD9z0CQBywWMoaDrmSLbDnNOLs/WBc4Kk8/rxQvbYmhZpLPcCPpRYEEPcN3BwFNwRJV7ucEzfDMRShAVo/c+aMfKzJ0w7QRaMVve44F8=; 5:1L/zfoHXWP+95qL5FFLlA3g9YXsMybUSf5Q7U+y2rLfaLV52J3qhYK/csoPIah8mpjvT7LYH7BvGPVBDUFL2/Q7xL8B2td4nKwqL3mE6J/f1scE9ZmsXE+lDlVWL3WEHsF5Thjwrcxth+CHC17NJeg==; 24:zR4a3/CokQ+QzDqHaKWjlKxNY6tIvG61B8MdNd8fEYUu//iYVSmbBIhqV3qIXAbIQb029B25mOAsnUMjFoxLjO56I8tMQ+jTx0a1cY8oFKQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1P122MB0025; 7:CPG1PIFviUxzDICnUdTUNbyJXs+1AmHtSw7A4rUDbVL52b7/KlOph6cAhctbklQjiwJnDGOxiBWBGfDJv3RfMzS+kGcRxPBIw8PdIugcIwqEbWqFsVy/6xEDlWZohWe9H0Tin4RR4sVlOT8C8vXHeVLiR2qFwQgDFDb3Q+gCY7+e4f44SbE7ty6rmgXFtGqfXQR+wygkcz0r0e0pHttZ9naFuW8DFMpdg6E69aug92a9ODIwkrE2i6OLkIYVYaci8jAuZ/RW+b+c/YyufvgUlQO2fWd1H/nE2MePd2m0pMvAQjZevaX58ulhJovqDZi1JfDKhl2jdOP/kZ4/JAhaIw== X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 May 2017 16:30:19.1083 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.228.36]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P122MB0025 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: AM3PR90MB0097.MGDPHG.emi.philips.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 86.95.87.52 X-MS-Exchange-CrossPremises-transporttraffictype: Email X-MS-Exchange-CrossPremises-transporttrafficsubtype: X-MS-Exchange-CrossPremises-disclaimer-hash: 7fd5309d68bb4378c576a4d2c2ad972d336f5eb0475879c2a0b14da1aac98972 X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-OrganizationHeadersPreserved: HE1P122MB0025.EURP122.PROD.OUTLOOK.COM Archived-At: Subject: Re: [core] Resource Directory: Simplifying Domains X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 16:30:26 -0000 SGVsbG8sDQoNCnRoZSBwcm9wb3NlZCBzaW1wbGlmaWNhdGlvbiB3b3VsZCBkaWZmZXIgZnJvbSB0 aGUgY3VycmVudCBEb21haW4gY29uY2VwdC4gIEluIHRoZSBjdXJyZW50IGNvbmNlcHQsIGEgcmVn aXN0ZXJpbmcgZW5kcG9pbnQgKG9yIGEgdG9vbCAnQ1QnIG9uIGl0cyBiZWhhbGYpIGNhbiBjcmVh dGUgYXJiaXRyYXJ5IG5ldyBkb21haW5zIGJ5IHB1dHRpbmcgaW4gYSBkPTxzdHJpbmc+IGVpdGhl ciBpbiB0aGUgVVJJIG9yIGluIHRoZSBpbmRpdmlkdWFsIGxpbmtzIGJlaW5nIHJlZ2lzdGVyZWQu IEluIHRoZSBwcm9wb3NlZCBjb25jZXB0LCB0aGUgRG9tYWlucyBhcmUgbGltaXRlZCB0byB0aGUg cmVzb3VyY2VzIGFscmVhZHkgcHJlLWhvc3RlZCBhdCB0aGUgUkQuIChFLmcuIC9yZC9kb21haW4x LCAvcmQvZG9tYWluMiAtIG9ubHkgY2hvaWNlIGJldHdlZW4gdGhlc2UgMiBkb21haW5zIGFuZCBu b3QgYXJiaXRyYXJ5IG90aGVyIG9uZXMuKQ0KDQpBZ3JlZSB3aXRoIFBldGVyIHRoYXQgZm9yIHRo ZSBjb25zdHJhaW5lZCBlbmRwb2ludCAodGhhdCdzIGUuZy4ganVzdCByZWdpc3RlcmluZykgaXQg aXMgZWFzaWVzdCBhcyB3cml0dGVuIGN1cnJlbnRseSAtIGl0IGp1c3QgcmVnaXN0ZXJzIHdpdGhv dXQgZCBwYXJhbWV0ZXJzIHRvIHRoZSBkZWZhdWx0IGRvbWFpbjsgd2l0aG91dCBoYXZpbmcgdG8g Y2hvb3NlIGJldHdlZW4gZG9tYWlucy4NCg0KRXNrbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIHBldGVyIHZhbiBkZXIgU3Rvaw0KU2VudDogRnJpZGF5LCBBcHJpbCAyMSwgMjAxNyA5OjA0 DQpUbzogQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+DQpDYzogQ29yZSA8Y29yZUBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0gUmVzb3VyY2UgRGlyZWN0b3J5OiBTaW1wbGlmeWlu ZyBEb21haW5zDQoNCkhpIENhcnN0ZW4sDQoNCm15IGhpcCBndW4gc2hvdCByZWFjdGlvbi4NClRo ZSBhbHRlcm5hdGl2ZSBzZWVtcyBtb3JlIGNvbXBsZXggdG8gaGFuZGxlIHRoYW4gdGhlIG9yaWdp bmFsIGZyb20gYXBwbGljYXRpb24gcG9pbnQgb2Ygdmlldy4NCkluIG15IG9waW5pb24sIHRoZSBh cHBsaWNhdGlvbiBlYXNlIG9mIHVzZSB0YWtlcyBwcmVjZWRlbmNlIGhlcmUuDQoNClBldGVyDQoN CkNhcnN0ZW4gQm9ybWFubiBzY2hyZWVmIG9wIDIwMTctMDQtMjAgMjA6MTU6DQo+IEluIHRoZSBj dXJyZW50IHJlc291cmNlIGRpcmVjdG9yeSwgbXVsdGlwbGUgZG9tYWlucyBhcmUgcHJldHR5IG11 Y2gNCj4gc2hpcHMgaW4gdGhlIG5pZ2h0IHRvIGVhY2ggb3RoZXI7IGRvbWFpbnMgImNvbXBhcnRt ZW50YWxpemUiIHRoZSBSRC4NCj4gQWZ0ZXIgd2UgaGFkIGEgZGlzY3Vzc2lvbiBvZiBSRCBkb21h aW5zIGJldHdlZW4gdGhlIGF1dGhvcnMsIEknbSBubw0KPiBsb25nZXIgc3VyZSB3ZSBhY3R1YWxs eSBuZWVkIGFsbCB0aGlzIG1lY2hhbmlzbS4NCj4gSW5zdGVhZCwgZWFjaCBzdWNoIGNvbXBhcnRt ZW50L2RvbWFpbiBjb3VsZCBiZSBtb2RlbGVkIGFzIGEgc2VwYXJhdGUNCj4gcmVzb3VyY2UgZGly ZWN0b3J5IG9mIGl0cyBvd24uDQo+IE11bHRpcGxlIGRvbWFpbnMgY291bGQgYmUgb2ZmZXJlZCBh cyBtdWx0aXBsZSByZXNvdXJjZSBkaXJlY3RvcmllcywNCj4gZS5nLiB1bmRlcg0KPg0KPiAgICAg L3JkL3tkb21haW59DQo+DQo+IChUaGlzIGRvZXMgbm90IG1lYW4gdGhhdCB0aGVyZSBuZWVkIHRv IGJlIG11bHRpcGxlIGNvcGllcyBvZiBSRA0KPiBzb2Z0d2FyZSBydW5uaW5nIGV0Yy4sIGl0IGp1 c3QgbWVhbnMgYSByZXNvdXJjZSBkaXJlY3RvcnkNCj4gaW1wbGVtZW50YXRpb24gY291bGQgb2Zm ZXIgbXVsdGlwbGUgb2YgdGhlIGVudHJ5IHBvaW50cyBjYWxsZWQNCj4gInJlc291cmNlIGRpcmVj dG9yaWVzIiB1bmRlciBkaWZmZXJlbnQgVVJJcy4pDQo+DQo+IFRoZSByZW1haW5pbmcgcXVlc3Rp b25zIGFyZQ0KPg0KPiAtLSBob3cgZG9lcyBhIGNsaWVudCBmaW5kIHRoZSByZXNvdXJjZSBkaXJl Y3RvcnkgZm9yIHRoZSBkb21haW4gaXQNCj4gICAgd2FudHMgdG8gcmVnaXN0ZXIgdW5kZXIuDQo+ IC0tIGhvdyBkb2VzIGEgY2xpZW50IGxpc3QgdGhlIHJlc291cmNlIGRpcmVjdG9yaWVzIGFuZCBm aW5kIHRoZQ0KPiAgICAiZG9tYWluIiBmb3IgZWFjaC4NCj4NCj4gTGlzdGluZyB0aGUgcmVzb3Vy Y2UgZGlyZWN0b3JpZXMgY291bGQgc2ltcGx5IGJlIGRvbmUgYnkgb2ZmZXJpbmcgYQ0KPiBjb2xs ZWN0aW9uIGludGVyZmFjZSB0byB0aGVtLiAgVGhlIGRvbWFpbiBwcm9wZXJ0eSBjb3VsZCBiZSBj b252ZXJ0ZWQNCj4gaW50byBhIFVSSSBhbmQgbGlzdGVkIGluIHRoZSByZXNvdXJjZSBkaXJlY3Rv cnkuICBDb25zdHJ1Y3Rpb24gb2YgYW4NCj4gUkQgVVJJIGNvdWxkIGJlIHZpYSBhIHRlbXBsYXRl IGFzIHNob3duIGFib3ZlLg0KPg0KPiBCZWZvcmUgd2UgZnVydGhlciBmbGVzaCBvdXQgdGhpcyBk ZXNpZ24sIEknZCBsaWtlIHRvIGtub3cgd2hvIGhhcw0KPiBpbXBsZW1lbnRlZCBkb21haW5zICh3 aGljaCBhcmUgb3B0aW9uYWwgaW4gdGhlIGN1cnJlbnQgUkQpIGFuZCBob3cNCj4gbXVjaCB0aGV5 IHdvdWxkIGJlIGltcGFjdGVkIGJ5IHN1Y2ggYSBzaW1wbGlmaWNhdGlvbi4NCj4NCj4gR3LDvMOf ZSwgQ2Fyc3Rlbg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQg dW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3Ig dGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg eW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1p bmF0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBk ZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo= From nobody Thu May 4 11:24:50 2017 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BB4128799; Thu, 4 May 2017 11:24:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149392228264.6852.3113845407655898493@ietfa.amsl.com> Date: Thu, 04 May 2017 11:24:42 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 18:24:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : Media Types for Sensor Measurement Lists (SenML) Authors : Cullen Jennings Zach Shelby Jari Arkko Ari Keranen Carsten Bormann Filename : draft-ietf-core-senml-06.txt Pages : 46 Date : 2017-05-04 Abstract: This specification defines media types for representing simple sensor measurements and device parameters in the Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), eXtensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use this media type in protocols such as HTTP or CoAP to transport the measurements of the sensor or to be configured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-senml-06 https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 4 13:00:39 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378B6129442 for ; Thu, 4 May 2017 13:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Ckq6WtNRNa2A for ; Thu, 4 May 2017 13:00:36 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 01AA5128854 for ; Thu, 4 May 2017 13:00:35 -0700 (PDT) X-AuditID: c1b4fb3a-b7dff70000005025-c0-590b88603a9e Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B7.28.20517.0688B095; Thu, 4 May 2017 22:00:34 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0339.000; Thu, 4 May 2017 22:00:32 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: "Cullen Jennings (fluffy)" CC: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= , core Thread-Topic: [core] SenML and its use in core-interfaces (follow-up on bn/n URI clarification) Thread-Index: AQHSwzE592xrEscukkSmVrMDqORATKHi/duAgABWz4CAAADBgIABJNQA Date: Thu, 4 May 2017 20:00:31 +0000 Message-ID: <66658FD9-C767-4241-9946-6F9CF36BCF44@ericsson.com> References: <20170502104529.dqr3pbmrcmb5wlkm@hephaistos.amsuess.com> <5D6788C7-E1C9-4D52-B1CE-A98F29965BF4@ericsson.com> <89B55F28-2523-4EBB-ACC2-6CCD756E1A07@cisco.com> <0084DFA9-D26B-4ADA-AFA1-B5F617DC14CA@cisco.com> In-Reply-To: <0084DFA9-D26B-4ADA-AFA1-B5F617DC14CA@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-62BD973E-EF1C-41FC-812C-4CCC217FC8D8"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyM2J7uG5SB3ekwd8dXBbLLzxnsdj3dj2z RcdkNgdmjym/N7J6bN1/l8ljyZKfTAHMUVw2Kak5mWWpRfp2CVwZfc2nmQsmhVcc+P+FqYHx VkgXIyeHhICJxKRPu1i6GLk4hASOMEp8WDqPEcJZzCjx+ehvdpAqNgFbiSet+1hBbBEBQ4mm PfOYQGxmgQSJ9V+XgtnCQPbmX8uZIGoSJU5/vgI0lQPIdpPY9MsYJMwioCJx8clGdpAwr4A9 0C4xiFUPGCXuNbWAtXICrTp2eQsLiM0oICbx/dQaqFXiEreezGeCOFpE4uHF02wQtqjEy8f/ WEEGMQtMZpR4OfcQ2J28AoISJ2c+YZnAKDwLSf8sZHWzkNRBFGlK7O9eDmUrSkzpfsgOYVtL zPh1kA3CNpV4ffQjI7KaBYwcqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECo+3glt9WOxgP Pnc8xCjAwajEw6uQwx0pxJpYVlyZe4hRBWjOow2rLzBKseTl56UqifCmtgOleVMSK6tSi/Lj i0pzUosPMUpzsCiJ8zrsuxAhJJCeWJKanZpakFoEk2Xi4JRqYJxzii9r4uWnLxusCn7N7wk3 nmyVLLe86lWdL+/a5xbz98XfXH/3yD4bhifbom6UM9RJ7XyiYZRWby/4+Za1c9WlH01Hq9tS ZlcsvfH+L/OsSm/xF+G8q3XfT5xlt6H/bGeT+u/bRzTULXPrpZqfz1lbpdQukKRnnO7nMu+e wbGFrXx79kfN7FFiKc5INNRiLipOBAAq5tlZvgIAAA== Archived-At: Subject: Re: [core] SenML and its use in core-interfaces (follow-up on bn/n URI clarification) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 20:00:38 -0000 --Apple-Mail-62BD973E-EF1C-41FC-812C-4CCC217FC8D8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 VGhlIDExdGggMTY6MDAgQ0VUIHdvcmtzIGZvciBtZS4gSWYgYW55b25lIGVsc2Ugd2FudHMgdG8g am9pbiwgcGxlYXNlIGxldCB1cyBrbm93LiANCg0KQ2hlZXJzLA0KQXJpDQoNCj4gT24gNCBNYXkg MjAxNywgYXQgNS4zMiwgQ3VsbGVuIEplbm5pbmdzIChmbHVmZnkpIDxmbHVmZnlAY2lzY28uY29t PiB3cm90ZToNCj4gDQo+IA0KPj4gT24gTWF5IDMsIDIwMTcsIGF0IDg6MzAgUE0sIEN1bGxlbiBK ZW5uaW5ncyA8Zmx1ZmZ5QGNpc2NvLmNvbT4gd3JvdGU6DQo+PiANCj4+IA0KPj4gT0ssIHRoaXMg c291bmRzIGxpa2UgYSBnb29kIHBhdGggZm9yd2FyZC4gSSBhbSBzdGlsbCBpbnRlcmVzdHMgaW4g bGVhcmluZyBtb3JlIGFib3V0IHRoZSBpc3N1ZSBhbmQgaG93IHdlIG1pZ2h0IHNvbHZlIGl0LiAN Cj4+IA0KPj4gMTY6MDAgQ0VTVCBpcyBhIGdvb2QgdGltZSBmb3IgbWUgZ2VuZXJhbGx5IGJ1dCB1 bmZvcnR1bmF0ZWx5IG9uIG1heSA5IEkgd2lsbCBiZSBmbHlpbmcuIEkgY291bGQgZG8gTWF5IDUs IG9yIDEwLg0KPiANCj4gT29wcyBJIHNlbnQgdGhhdCB0b28gc29vbi4gVHVybnMgb3V0IEkgY2Fu IG5vdCBkbyB0aGUgMTB0aCBidXQgSSBjYW4gZG8gdGhlIDExdGguIA0KPiANCj4+IA0KPj4gDQo+ Pj4gT24gTWF5IDMsIDIwMTcsIGF0IDM6MTkgUE0sIEFyaSBLZXLDpG5lbiA8YXJpLmtlcmFuZW5A ZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+PiANCj4+PiBIaSBDaHJpc3RpYW4sDQo+Pj4gDQo+Pj4g VGhhbmtzIGZvciB0aGUgdXBkYXRlISBJZiB3ZSB3YW50IHRvIGhhdmUgYSBjYWxsIGl0IHNob3Vs ZCBwcm9iYWJseSBiZSBVUy1mcmllbmRseSB0b28sIHNvIGxhdGUgZXZlbmluZyBpbiBFdXJvcGUg dGltZSB6b25lcy4gSSdkIHN1Z2dlc3QgMTY6MDAgQ0VTVCAoNyBBTSBQU1QpIG9uIDl0aCBvZiBN YXkuDQo+Pj4gDQo+Pj4gDQo+Pj4gQ2hlZXJzLA0KPj4+IEFyaQ0KPj4+IA0KPj4+PiBPbiAwMiBN YXkgMjAxNywgYXQgMTM6NDUsIENocmlzdGlhbiBBbXPDvHNzIDxjLmFtc3Vlc3NAZW5lcmd5aGFy dmVzdGluZy5hdD4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBIZWxsbyBDdWxsZW4sIGhlbGxvIEFyaSwN Cj4+Pj4gDQo+Pj4+PiBPbiBGcmksIEFwciAxNCwgMjAxNyBhdCAxMDowNzoxMUFNIC0wNzAwLCBD dWxsZW4gSmVubmluZ3MgKGZsdWZmeSkgd3JvdGU6DQo+Pj4+PiBJIHdvbmRlciB3aHkgdGhlIHNl bm1sIGluIHRoYXQgZHJhZnQgY2FuIG5vdCBoYXZlIHVuaXF1ZSBuYW1lcyBpbiB0aGUNCj4+Pj4+ IHNlbm1sID8NCj4+Pj4gDQo+Pj4+PiBPbiBXZWQsIEFwciAxOSwgMjAxNyBhdCAwODo1NTo1N1BN ICswMDAwLCBBcmkgS2Vyw6RuZW4gd3JvdGU6DQo+Pj4+PiBPSywgbWF5YmUgd2UgY2FuIGhhdmUg dGhlIGNhbGwgbGF0ZXIgdGhlbi4gRG8geW91IHJlZmVyIHRvIE1pY2hhZWwNCj4+Pj4+IEtvc3Rl cidzIEhTTUwgZHJhZnQgYmVsb3cgb3Igc29tZXRoaW5nIGVsc2U/DQo+Pj4+IA0KPj4+PiBJJ3Zl IHRhbGtlZCB0byBNaWNoYWVsIGFuZCBDYXJzdGVuIHBpZ2d5LWJhY2tpbmcgb24gYSByZXNvdXJj ZS1kaXJlY3RvcnkNCj4+Pj4gY2FsbCwgYW5kIGl0J2QgYmUgT0sgd2l0aCBNaWNoYWVsICh3aG9t IEkgcGVyY2VpdmUgdG8gYmUgdGhlIG1vc3QgYWN0aXZlDQo+Pj4+IGNvcmUtaW50ZXJmYWNlcyBh dXRob3IgcmVjZW50bHkpIGlmIHRoYXQgd2VudCBmcm9tIHVzaW5nIHBsYWluIFNlbk1MIHRvDQo+ Pj4+IHVzaW5nIEhTTUwgKG1vdmluZyB0aGlzIGZyb20gImJsb2NraW5nIFNlbk1MIiB0byAid2ls bCBuZWVkIHRvIGxvb2sgYXQNCj4+Pj4gU2VuTUwgZXh0ZW5zaW9ucyIpOyBwb3NzaWJseSwgaXQg Y291bGQgYWxzbyBtb3ZlIHRvIENPUkFMLCBvciB0aGUNCj4+Pj4gZm9ybWF0cyBjb3VsZCBldmVu IG1lcmdlLg0KPj4+PiANCj4+Pj4gV2l0aCB0aGF0LCB0aGUgd2hvbGUgaXNzdWUgaXMgcHJvYmFi bHkgbm90IHRoYXQgcHJlc3NpbmcgYW55IG1vcmU7IEknZA0KPj4+PiBzdGlsbCBiZSBoYXBweSB0 byBkaXNjdXNzIG91dCB0aGUgcmF0aW9uYWxlIGJlaGluZCB1c2luZyBVUkkgbmFtZXMgYW5kDQo+ Pj4+IHBlcmZvcm1hbmNlL3NjYWxhYmlsaXR5IGlzc3VlcyBpbnZvbHZlZCB3aXRoIGl0OyBpZiB5 b3UncmUgc3RpbGwNCj4+Pj4gaW50ZXJlc3RlZCwgbW9zdCAoVVRDKzAyMDAtdmlhYmxlKSB0aW1l cyBvbiBNYXkgM3JkIG9yIDh0aCB0byAxMHRoIHdvdWxkDQo+Pj4+IHdvcmsgZmluZSBmb3IgbWUu DQo+Pj4+IA0KPj4+PiBCZXN0IHJlZ2FyZHMNCj4+Pj4gQ2hyaXN0aWFuDQo+Pj4+IA0KPj4+PiAt LSANCj4+Pj4gVG8gdXNlIHJhdyBwb3dlciBpcyB0byBtYWtlIHlvdXJzZWxmIGluZmluaXRlbHkg dnVsbmVyYWJsZSB0byBncmVhdGVyIHBvd2Vycy4NCj4+Pj4gLS0gQmVuZSBHZXNzZXJpdCBheGlv bQ0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4gY29yZSBtYWlsaW5nIGxpc3QNCj4+PiBjb3JlQGlldGYub3JnDQo+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo+PiANCj4gDQo= --Apple-Mail-62BD973E-EF1C-41FC-812C-4CCC217FC8D8 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR5DCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF6jCCA9KgAwIBAgIRAPoMA5z/l/RYsixy5v8S2z8w DQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjAyMTQ1NjQyWhcNMTcxMjAyMTQ1NjQxWjBlMREwDwYD VQQKDAhFcmljc3NvbjEVMBMGA1UEAwwMQXJpIEtlcsOkbmVuMScwJQYJKoZIhvcNAQkBFhhhcmku a2VyYW5lbkBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VhcmlrZXIwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCJDr/JbhnJ9M4/bnGBCyYu4s57UPPPpoDmq/xpr5fvMANbVM0+weVHISM3 bk56dTvelI8wz/B7TpYZ60QP2XA7pZhJcRbr3M0fuyES/sTehYWRnEt6Zv+UHqV1U1Fzd+Y9zwAi 9smZvU7/DWHrylywwb/MJMMcSnwr1DDII/ZZcFRwFxnefrsW5JZzGEktM5JzEyJeBvMzLnfnxlRU ZnBKmjWHo6+NY0zGE/av3O9VT6tWKewgurAHciLqBK4yF6reffE2e+k+GPmcODoeAdTZb82sT8qh ilGGjHJL/0yBghdLIcpq7iajSEcCCPQ0PDOTjk5hz+kHWR56vuD6pPkTAgMBAAGjggG+MIIBujBI BgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjIuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3Nw Mi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVy YS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNlcjAjBgNVHREEHDAagRhhcmkua2VyYW5l bkBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYs aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYI KwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBRO3s66I+x4qLz+nDBzngqpTuX64DAfBgNVHSME GDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQAD ggIBAFYpgmqF4ZIcZkZLtjukdgdQj1wxRgeaGAiguqpZxuR4YOq8exKpgAIA5m3FZ+icGCVY2DYa nwzP+5+IKjvjspD5hb3J+fY1egdVgcq5ku2DDG2ReJ0dp39XFAksNEJ8Z5O/QHEXy4X7TmFamArH WJEHkd690X6pvnkdwJXD+TnIUr5l42cjgUkKEPg0g+2Kgdp1NGdoFbCtuwrUtZpBgu0VEVQfq5qo dINAXqciN3C0qf3gwu3bvQixCPvaq8M4eTdda3Dun5bSbQPLpZtIw3Kw0RqH2CnR8+zyFuKsrnKo 4Sn66D0h/YoVkeAoLAlmSGH/dYgWIVlqxXZR8302DHjWWWxl7bwKMDnD3uq2dnzoNpO8TmTc0O/l RqEFHZvEPOe+JkWPCFQ9KZhcl9qcodbVKilY+Yhndh73O8VJRtg15NSzFNuNiS7PjkGuTNYhK/be ztgM3DH8vftAtvQCg2O6rYShT11RMiIjn7aCIhpkqJLltBiX3aAbT6FXXi7mEtbN83tDKp2Izn42 bcqOJdk9b/5OEP8NMPGXIlVNZY/yFvumhLKy1T7Go8rQRe2OB+D6MxEVpHSGZ2UIycyMV2VpPyVM pbcM8/vz6xDPay+f8lwFjcRM90lLBJh4RACNs0Ya8ncPGYY0LnFegBPrBrzQF82UPstkRx/iy0P2 52avMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIG A1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQw NTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoC ggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJh rhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLd aIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P5 4ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO 8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwz GAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7i rYUYFpq4TyocQ7qpHdYASC+NV8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+ j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPW Ie57lyj0n3e1rTqTGIBIe9wjNnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/ W5kpAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2Nz cC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRy dXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAG AQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8v cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmww HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU sQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJ KoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py 9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdB ihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5Ux WdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QT KDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG 2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8 sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH 3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYm p7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZ dDq1kIHIw0vF4PBTVMZtMYICmTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UE AwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAPoMA5z/l/RYsixy5v8S2z8wCQYFKw4D AhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNTA0 MjAwMDMwWjAjBgkqhkiG9w0BCQQxFgQUV0NwmR2F5xruGsCFeena2P2iDNEwXgYJKwYBBAGCNxAE MVEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVh bCBDQSB2MgIRAPoMA5z/l/RYsixy5v8S2z8wYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA+gwDnP+X 9FiyLHLm/xLbPzANBgkqhkiG9w0BAQEFAASCAQBPhpEYg/yHvxf8qaonM4wLGTFlY/KD75oRPKA7 Ee5w9y2a6NV7Cem/QQyDyAfsHJZ8pofqPtjjVTCfJUOX95Y8CDyj/NpaOGjbwfGH79WIxv0bOUe7 y/JwqzccIqaOHVv7mzQFQ/A2Lb2C0PFeezimp76jWm/PbEZmso3W9/UDVM7rC7HUT22rc9PIlPvz hT4G9fKY552POKXunBYfKvxsrrOBWhz7tNFQOQHMUwVKMC1ihUZoMO9YYjmE+V71nVdTIWESYzmr zDNW1ySxmjmv45Gofz4vO6ZgZiqCkx1Q60iyuVUbNbs37GuArseRbmOKxe5c20Ejqc/A8lg+Ww9+ AAAAAAAA --Apple-Mail-62BD973E-EF1C-41FC-812C-4CCC217FC8D8-- From nobody Thu May 4 15:10:46 2017 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74249129B70; Thu, 4 May 2017 15:10:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149393584541.6920.14870493331779049767@ietfa.amsl.com> Date: Thu, 04 May 2017 15:10:45 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-07.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 22:10:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : Media Types for Sensor Measurement Lists (SenML) Authors : Cullen Jennings Zach Shelby Jari Arkko Ari Keranen Carsten Bormann Filename : draft-ietf-core-senml-07.txt Pages : 46 Date : 2017-05-04 Abstract: This specification defines media types for representing simple sensor measurements and device parameters in the Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), eXtensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use this media type in protocols such as HTTP or CoAP to transport the measurements of the sensor or to be configured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-senml-07 https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 5 00:48:03 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D6712946F for ; Fri, 5 May 2017 00:48:02 -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 tx01zWkzt0rI for ; Fri, 5 May 2017 00:48:00 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 302F512943D for ; Fri, 5 May 2017 00:48:00 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id 203so17370581ywe.0 for ; Fri, 05 May 2017 00:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pFKpdHoFhDDwhV2jEkFx1yxoX6hqjDTLAQKbrRAV9WU=; b=fzJubhmH4dbx77Q5pGARJrVGFSvBTYwLjVoxeIwEsGI60VSimANwV8tE6TSr/JeXOs IKMvP35voqTBxj3vc7dNgJZ3rZbNYsMYP9weHK2NZwkH7B7T+7zMGYkbMIZsifLgsOiX LH5HVRANJrPctFDdnTtjaQT4xDPwHfuqifPq6skfBaUgj6zRr6p8IsQjtD0LWVVr1ZbG Qr9dIDHnOLKkqGGBdcdr34pn4NE+tkTismESjQq98HpI05ILjssNRR928uUrKTTIf5zY 6fSXktdPc7vaO75675vs59rr1CcbIOBhImEshcRqftktbgDK/bDRarUtdVL71E6eGuOe 6ovQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pFKpdHoFhDDwhV2jEkFx1yxoX6hqjDTLAQKbrRAV9WU=; b=jMHR9GW0K37drsIRTz0PMUSstdbJxaP1ZZ8idWLE/TSZCpGgZJ31ZmMMQZwRXGWg5R RZ3Y0k6eorYfcLM48WqnoJi4BIQFvcIpxtb6CYdHobxbXtkglOaEBkCqi6TZeYFHEihm ScXrplgmTzZPknN64ERaE9vs5gjgLXFhCxWuwJWoF0JVFceZsFSHimxealkI3z4qdwSS 54/xhl8DopY3LFoTNqYfJsw6y6ctmWmDTF84d86Q7FTeY4bodKOsEFaA+qfYeDszOvfD GFyV59+SMjdvVFDqNlEmCvJ+fJ7o8L8CMAV+20Zs4diCikdisq1Ct7dhsdLRus/CNREG wUQg== X-Gm-Message-State: AN3rC/4/i21dpalFGeYJDeQcUOLorEGhxpQgyJF2rzKdUgD/vZt88+aA JfQSK62kKcGSag== X-Received: by 10.13.239.198 with SMTP id y189mr35959405ywe.198.1493970479458; Fri, 05 May 2017 00:47:59 -0700 (PDT) Received: from [10.0.0.14] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id n5sm2055293ywd.15.2017.05.05.00.47.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 05 May 2017 00:47:58 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <66658FD9-C767-4241-9946-6F9CF36BCF44@ericsson.com> Date: Fri, 5 May 2017 00:47:56 -0700 Cc: "Cullen Jennings (fluffy)" , core , =?utf-8?Q?Christian_Ams=C3=BCss?= Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170502104529.dqr3pbmrcmb5wlkm@hephaistos.amsuess.com> <5D6788C7-E1C9-4D52-B1CE-A98F29965BF4@ericsson.com> <89B55F28-2523-4EBB-ACC2-6CCD756E1A07@cisco.com> <0084DFA9-D26B-4ADA-AFA1-B5F617DC14CA@cisco.com> <66658FD9-C767-4241-9946-6F9CF36BCF44@ericsson.com> To: =?utf-8?Q?Ari_Ker=C3=A4nen?= X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [core] SenML and its use in core-interfaces (follow-up on bn/n URI clarification) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 07:48:02 -0000 Yes, I'd like to join the call Best regards, Michael > On May 4, 2017, at 1:00 PM, Ari Ker=C3=A4nen = wrote: >=20 > The 11th 16:00 CET works for me. If anyone else wants to join, please = let us know.=20 >=20 > Cheers, > Ari >=20 >> On 4 May 2017, at 5.32, Cullen Jennings (fluffy) = wrote: >>=20 >>=20 >>> On May 3, 2017, at 8:30 PM, Cullen Jennings = wrote: >>>=20 >>>=20 >>> OK, this sounds like a good path forward. I am still interests in = learing more about the issue and how we might solve it.=20 >>>=20 >>> 16:00 CEST is a good time for me generally but unfortunately on may = 9 I will be flying. I could do May 5, or 10. >>=20 >> Oops I sent that too soon. Turns out I can not do the 10th but I can = do the 11th.=20 >>=20 >>>=20 >>>=20 >>>> On May 3, 2017, at 3:19 PM, Ari Ker=C3=A4nen = wrote: >>>>=20 >>>> Hi Christian, >>>>=20 >>>> Thanks for the update! If we want to have a call it should probably = be US-friendly too, so late evening in Europe time zones. I'd suggest = 16:00 CEST (7 AM PST) on 9th of May. >>>>=20 >>>>=20 >>>> Cheers, >>>> Ari >>>>=20 >>>>> On 02 May 2017, at 13:45, Christian Ams=C3=BCss = wrote: >>>>>=20 >>>>> Hello Cullen, hello Ari, >>>>>=20 >>>>>> On Fri, Apr 14, 2017 at 10:07:11AM -0700, Cullen Jennings = (fluffy) wrote: >>>>>> I wonder why the senml in that draft can not have unique names in = the >>>>>> senml ? >>>>>=20 >>>>>> On Wed, Apr 19, 2017 at 08:55:57PM +0000, Ari Ker=C3=A4nen wrote: >>>>>> OK, maybe we can have the call later then. Do you refer to = Michael >>>>>> Koster's HSML draft below or something else? >>>>>=20 >>>>> I've talked to Michael and Carsten piggy-backing on a = resource-directory >>>>> call, and it'd be OK with Michael (whom I perceive to be the most = active >>>>> core-interfaces author recently) if that went from using plain = SenML to >>>>> using HSML (moving this from "blocking SenML" to "will need to = look at >>>>> SenML extensions"); possibly, it could also move to CORAL, or the >>>>> formats could even merge. >>>>>=20 >>>>> With that, the whole issue is probably not that pressing any more; = I'd >>>>> still be happy to discuss out the rationale behind using URI names = and >>>>> performance/scalability issues involved with it; if you're still >>>>> interested, most (UTC+0200-viable) times on May 3rd or 8th to 10th = would >>>>> work fine for me. >>>>>=20 >>>>> Best regards >>>>> Christian >>>>>=20 >>>>> --=20 >>>>> To use raw power is to make yourself infinitely vulnerable to = greater powers. >>>>> -- Bene Gesserit axiom >>>>=20 >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri May 5 06:10:35 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EC5127866 for ; Fri, 5 May 2017 06:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.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 RyvPhBbFvU5B for ; Fri, 5 May 2017 06:10:31 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0051.outbound.protection.outlook.com [104.47.0.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B62F1242F5 for ; Fri, 5 May 2017 06:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mUxvbySVK6gMABM9pIjDUmuQuO2DM/oQlQZK+MJ/noY=; b=llheLeCkrvgHiMUBtmgE9+kOkCJ1nGJYk3I0UEQX/DsW9KGs3xGhU6zY9Y8z5163oheag19JmxoJrI8Sav+vHu/YmJRLNTifkTeOSMMkM1uy/6486hzcV3MnVfE5C8XQIAjw4ukZ/teLSQOhlYFd0nws1dc7NHYwfBRcW0T2X9E= Received: from VI1PR0802MB2383.eurprd08.prod.outlook.com (10.172.14.135) by VI1PR0802MB2383.eurprd08.prod.outlook.com (10.172.14.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11; Fri, 5 May 2017 13:10:28 +0000 Received: from VI1PR0802MB2383.eurprd08.prod.outlook.com ([10.172.14.135]) by VI1PR0802MB2383.eurprd08.prod.outlook.com ([10.172.14.135]) with mapi id 15.01.1075.010; Fri, 5 May 2017 13:10:28 +0000 From: Lauri Piikivi To: "Dijk, Esko" , Carsten Bormann , "consultancy@vanderstok.org" CC: Core Thread-Topic: [core] Resource Directory: Simplifying Domains Thread-Index: AQHSugIlomWgM9dUiEyMoYiLvWdfR6HPZwQAgBUMZgCAAVp9AA== Date: Fri, 5 May 2017 13:10:27 +0000 Message-ID: References: <2688B534-A979-42F6-AC33-925817005F80@tzi.org> <75dc1a630fca3fd2e50fe13f867cb85b@xs4all.nl> <0bd0cd5aac2e444cbb625afc688f1c5f@AM3PR90MB0097.MGDPHG.emi.philips.com> In-Reply-To: <0bd0cd5aac2e444cbb625afc688f1c5f@AM3PR90MB0097.MGDPHG.emi.philips.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: philips.com; dkim=none (message not signed) header.d=none;philips.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0802MB2383; 7:AunnxMJzbtxotv8/+JSHD0aKfrg9X3ml1JHQ129zqv/WFk17e9qudnTP63SG6MbEebPmCyK/0B7jteSK4imxbdP6Pom0CmnID8iP83Y351bwLiy+J3/MCYHeoWXUUxpCh2o8kESiwu08OjILmt2nWmpCThAABljYNmuqxuvDUfaY7HM2/t4CumoZ3zs8SEhoqF+aTeyjrfRcJh49px3PmBN2vO8VYQT9CYKq8aviTSB9k3Ye5XkS/mqpbnhMHKzOsDz1Ahepjn1Ia3l/x6QLAe7nYdEQkhTUyl7OUsdkEeNi9Kj2/SQiYC/Ia4641QHhlDbhOXU+L0jEcJZMlGHNLA== x-ms-office365-filtering-correlation-id: 58390088-81da-4ccc-898d-08d493b819d2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:VI1PR0802MB2383; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(260087099026482); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(20161123558100)(6072148); SRVR:VI1PR0802MB2383; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0802MB2383; x-forefront-prvs: 02981BE340 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(39410400002)(39400400002)(39450400003)(39850400002)(39840400002)(374574003)(53754006)(377424004)(13464003)(85714005)(24454002)(40434004)(50986999)(8676002)(33656002)(229853002)(102836003)(6436002)(7736002)(54356999)(76176999)(3846002)(305945005)(5660300001)(6506006)(2906002)(3280700002)(4326008)(2950100002)(6486002)(77096006)(8936002)(2501003)(478600001)(5890100001)(81166006)(3660700001)(6116002)(36756003)(2900100001)(83716003)(6512007)(66066001)(53546009)(122556002)(99286003)(6246003)(53936002)(25786009)(82746002)(38730400002)(86362001)(189998001)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0802MB2383; H:VI1PR0802MB2383.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <196E2BEEFD4F6647A0041CE907D570A8@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2017 13:10:27.7762 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0802MB2383 Archived-At: Subject: Re: [core] Resource Directory: Simplifying Domains X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 13:10:34 -0000 DQpIaSBhbGxzLA0KDQpXZSBtYXkgaGF2ZSBzb21lIG1pc2FsaWduZWQgZGVmaW5pdGlvbiBmb3Ig ZG9tYWluLiBWMTAgb2YgdGhlIGRyYWZ0IHNheXMgaW4gZGVmaW5pdGlvbnM6DQogICAgICBUaGlz IHNwZWNpZmljYXRpb24gYXNzdW1lcyB0aGF0IHRoZSBsaXN0DQogICAgICBvZiBEb21haW5zIHN1 cHBvcnRlZCBieSBhbiBSRCBpcyBwcmUtY29uZmlndXJlZCBieSB0aGF0IFJELiAgV2hlbg0KICAg ICAgYSBkb21haW4gaXMgZXhwb3J0ZWQgdG8gRE5TLCB0aGUgZG9tYWluIHZhbHVlIGVxdWF0ZXMg dG8gdGhlIEROUw0KICAgICAgZG9tYWluIG5hbWUuDQoNCkJ1dCB0aGVuIHdlIGRvIGFsbG93IHRo ZSBkPSBwYXJhbWV0ZXIgZm9yIHJlZ2lzdHJhdGlvbnMuIEFsc28gdGhlcmUgc2VlbXMgdG8gYmUg c29tZSB3ZWFrbmVzcyBpbiB0aGUgdGV4dCB3aXRoIHRoZSBkb21haW4gYmVpbmcgaW4gdGhlIFVS SSwgYW5kIHRoZW4gdGhlIGxvY2F0aW9uIGluZm9ybWF0aW9uIGluIHRoZSByZXNwb25zZSBzaG91 bGQgaGF2ZSB0aGUgc2FtZSBkb21haW4/IEkgdGhpbmsgdGhlcmUgd291bGQgbmVlZCB0byBiZSBz b21lIGNsYXJpZmljYXRpb24gYWxzbyByZWdhcmRpbmcgdGhlIGF1dGhlbnRpY2F0aW9uIGFuZCBh Y2Nlc3MgY29udHJvbCBvZiB0aGUgZGV2aWNlLCBhcyBpdCB3b3VsZCBiZSB2ZXJ5IG5hdHVyYWwg dG8gcGxhY2UgYSBkZXZpY2UgaW4gY2VydGFpbiBkb21haW4gYmFzZWQgb24gdGhlIGNlcnRpZmlj YXRlLiBBY2Nlc3MgY29udHJvbCBtYXkgYmVjb21lIHZlcnkgaGFyZCwgaWYgdGhlcmUgYXJlIGFy Yml0cmFyeSBkb21haW5zLiBUaGVuIGFnYWluIG11bHRpcGxlIGdyb3VwcyBzZWVtIHRvIGJlIG5l ZWRlZCBmb3IgYSBtb3JlIGZpbmUgdHVuZWQgYWNjZXNzIGNvbnRyb2wNCg0KSW4gY2hhcHRlciAz IGl0IHNheXMgIlRoZSBkb21haW4gYW4gZW5kcG9pbnQgaXMgYXNzb2NpYXRlZCB3aXRoIGNhbg0K ICAgYmUgZGVmaW5lZCBieSB0aGUgUkQgb3IgY29uZmlndXJlZCBieSBhbiBvdXRzaWRlIGVudGl0 eS4gIFRoaXMNCiAgIGluZm9ybWF0aW9uIGhpZXJhcmNoeSBpcyBzaG93biBpbiBGaWd1cmUgMi4i DQpEb2VzIHRoYXQgbWVhbiB0aGF0IHRoZSBEZXZpY2UgY2FuIGNvbmZpZ3VyZSBpdCBhdCBydW4t dGltZT8gVGhlIEZpZ3VyZSAyIGNvdWxkIGJlIGNsYXJpZmllZCBpZiBtdWx0aXBsZSBkb21haW5z IG9yIGdyb3VwcyBhcmUgYWxsb3dlZC4gSXQgc2VlbXMgbXVsdGlwbGUgZ3JvdXBzIGFyZSBhbGxv d2VkLCBhbmQgYSBkZXZpY2UgY2FuIGJlIGluIG11bHRpcGxlIGdyb3VwcywgYXMgaW4gY2hhcHRl ciA3IHRoZXJlIGlzIGFuIGV4YW1wbGUgIlRoZSBmb2xsb3dpbmcgZXhhbXBsZSBzaG93cyBhIGNs aWVudCBwZXJmb3JtaW5nIGEgbG9va3VwIGZvciBhbGwgZ3JvdXBzIGFuIGVuZHBvaW50IGJlbG9u Z3MgdG8iDQoNCiBJIHdvdWxkIGxpa2UgdG8ga2VlcCBpdCBzaW1wbGUsIDEgZG9tYWluIHBlciBl bmRwb2ludCwgZGV2aWNlIGNhbiBwcm9wb3NlIGJ1dCBzZXJ2ZXIgZGljdGF0ZXMgYXMgdGhlIGVw IG11c3QgYmUgdW5pcXVlIGluIHRoZSBkb21haW4uU28gaWYgdGhlcmUgaXMgc29tZSBjb25maWd1 cmF0aW9uIGluIGRpcmVjdG9yeSBpdCBvdmVycmlkZXMgZGV2aWNlIHByb3Bvc2Fscy4gRm9yIHJl c3RmdWwgVVJJcywgdGhlIGRvbWFpbiBhbmQgZ3JvdXAgc2hvdWxkIGJlIGluIHRoZSBVUkkgIGZv ciBhIHJlc291cmNlIOKAlCB0aGUgbG9jYXRpb24gcmV0dXJuZWQgYnkgdGhlIGRpcmVjdG9yeS4g VGhhdCBtYWtlcyBpdCBhIGJpdCBjbHVua3kgdG8gaGF2ZSBtdWx0aXBsZSBncm91cHMgZm9yIGFu IGVuZHBvaW50LiBCdXQgaXQgaXMgcG9zc2libGUgaWYgd2Ugd2FudCBtdWx0aXBsZSBhbmQgYXJi aXRyYXJ5IGdyb3Vwcy4NCg0KQlINCi0gTGF1cmkNCg0KDQo+ICJPbiAwNCBNYXkgMjAxNywgYXQg MTk6MzAsIERpamssIEVza28gPGVza28uZGlqa0BwaGlsaXBzLmNvbT4gd3JvdGU6DQo+DQo+IEhl bGxvLA0KPg0KPiB0aGUgcHJvcG9zZWQgc2ltcGxpZmljYXRpb24gd291bGQgZGlmZmVyIGZyb20g dGhlIGN1cnJlbnQgRG9tYWluIGNvbmNlcHQuICBJbiB0aGUgY3VycmVudCBjb25jZXB0LCBhIHJl Z2lzdGVyaW5nIGVuZHBvaW50IChvciBhIHRvb2wgJ0NUJyBvbiBpdHMgYmVoYWxmKSBjYW4gY3Jl YXRlIGFyYml0cmFyeSBuZXcgZG9tYWlucyBieSBwdXR0aW5nIGluIGEgZD08c3RyaW5nPiBlaXRo ZXIgaW4gdGhlIFVSSSBvciBpbiB0aGUgaW5kaXZpZHVhbCBsaW5rcyBiZWluZyByZWdpc3RlcmVk LiBJbiB0aGUgcHJvcG9zZWQgY29uY2VwdCwgdGhlIERvbWFpbnMgYXJlIGxpbWl0ZWQgdG8gdGhl IHJlc291cmNlcyBhbHJlYWR5IHByZS1ob3N0ZWQgYXQgdGhlIFJELiAoRS5nLiAvcmQvZG9tYWlu MSwgL3JkL2RvbWFpbjIgLSBvbmx5IGNob2ljZSBiZXR3ZWVuIHRoZXNlIDIgZG9tYWlucyBhbmQg bm90IGFyYml0cmFyeSBvdGhlciBvbmVzLikNCj4NCj4gQWdyZWUgd2l0aCBQZXRlciB0aGF0IGZv ciB0aGUgY29uc3RyYWluZWQgZW5kcG9pbnQgKHRoYXQncyBlLmcuIGp1c3QgcmVnaXN0ZXJpbmcp IGl0IGlzIGVhc2llc3QgYXMgd3JpdHRlbiBjdXJyZW50bHkgLSBpdCBqdXN0IHJlZ2lzdGVycyB3 aXRob3V0IGQgcGFyYW1ldGVycyB0byB0aGUgZGVmYXVsdCBkb21haW47IHdpdGhvdXQgaGF2aW5n IHRvIGNob29zZSBiZXR3ZWVuIGRvbWFpbnMuDQo+DQo+IEVza28NCj4NCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIHBldGVyIHZhbiBkZXIgU3Rvaw0KPiBTZW50OiBGcmlkYXksIEFwcmls IDIxLCAyMDE3IDk6MDQNCj4gVG86IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPg0KPiBD YzogQ29yZSA8Y29yZUBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtjb3JlXSBSZXNvdXJjZSBE aXJlY3Rvcnk6IFNpbXBsaWZ5aW5nIERvbWFpbnMNCj4NCj4gSGkgQ2Fyc3RlbiwNCj4NCj4gbXkg aGlwIGd1biBzaG90IHJlYWN0aW9uLg0KPiBUaGUgYWx0ZXJuYXRpdmUgc2VlbXMgbW9yZSBjb21w bGV4IHRvIGhhbmRsZSB0aGFuIHRoZSBvcmlnaW5hbCBmcm9tIGFwcGxpY2F0aW9uIHBvaW50IG9m IHZpZXcuDQo+IEluIG15IG9waW5pb24sIHRoZSBhcHBsaWNhdGlvbiBlYXNlIG9mIHVzZSB0YWtl cyBwcmVjZWRlbmNlIGhlcmUuDQo+DQo+IFBldGVyDQo+DQo+IENhcnN0ZW4gQm9ybWFubiBzY2hy ZWVmIG9wIDIwMTctMDQtMjAgMjA6MTU6DQo+PiBJbiB0aGUgY3VycmVudCByZXNvdXJjZSBkaXJl Y3RvcnksIG11bHRpcGxlIGRvbWFpbnMgYXJlIHByZXR0eSBtdWNoDQo+PiBzaGlwcyBpbiB0aGUg bmlnaHQgdG8gZWFjaCBvdGhlcjsgZG9tYWlucyAiY29tcGFydG1lbnRhbGl6ZSIgdGhlIFJELg0K Pj4gQWZ0ZXIgd2UgaGFkIGEgZGlzY3Vzc2lvbiBvZiBSRCBkb21haW5zIGJldHdlZW4gdGhlIGF1 dGhvcnMsIEknbSBubw0KPj4gbG9uZ2VyIHN1cmUgd2UgYWN0dWFsbHkgbmVlZCBhbGwgdGhpcyBt ZWNoYW5pc20uDQo+PiBJbnN0ZWFkLCBlYWNoIHN1Y2ggY29tcGFydG1lbnQvZG9tYWluIGNvdWxk IGJlIG1vZGVsZWQgYXMgYSBzZXBhcmF0ZQ0KPj4gcmVzb3VyY2UgZGlyZWN0b3J5IG9mIGl0cyBv d24uDQo+PiBNdWx0aXBsZSBkb21haW5zIGNvdWxkIGJlIG9mZmVyZWQgYXMgbXVsdGlwbGUgcmVz b3VyY2UgZGlyZWN0b3JpZXMsDQo+PiBlLmcuIHVuZGVyDQo+Pg0KPj4gICAgL3JkL3tkb21haW59 DQo+Pg0KPj4gKFRoaXMgZG9lcyBub3QgbWVhbiB0aGF0IHRoZXJlIG5lZWQgdG8gYmUgbXVsdGlw bGUgY29waWVzIG9mIFJEDQo+PiBzb2Z0d2FyZSBydW5uaW5nIGV0Yy4sIGl0IGp1c3QgbWVhbnMg YSByZXNvdXJjZSBkaXJlY3RvcnkNCj4+IGltcGxlbWVudGF0aW9uIGNvdWxkIG9mZmVyIG11bHRp cGxlIG9mIHRoZSBlbnRyeSBwb2ludHMgY2FsbGVkDQo+PiAicmVzb3VyY2UgZGlyZWN0b3JpZXMi IHVuZGVyIGRpZmZlcmVudCBVUklzLikNCj4+DQo+PiBUaGUgcmVtYWluaW5nIHF1ZXN0aW9ucyBh cmUNCj4+DQo+PiAtLSBob3cgZG9lcyBhIGNsaWVudCBmaW5kIHRoZSByZXNvdXJjZSBkaXJlY3Rv cnkgZm9yIHRoZSBkb21haW4gaXQNCj4+ICAgd2FudHMgdG8gcmVnaXN0ZXIgdW5kZXIuDQo+PiAt LSBob3cgZG9lcyBhIGNsaWVudCBsaXN0IHRoZSByZXNvdXJjZSBkaXJlY3RvcmllcyBhbmQgZmlu ZCB0aGUNCj4+ICAgImRvbWFpbiIgZm9yIGVhY2guDQo+Pg0KPj4gTGlzdGluZyB0aGUgcmVzb3Vy Y2UgZGlyZWN0b3JpZXMgY291bGQgc2ltcGx5IGJlIGRvbmUgYnkgb2ZmZXJpbmcgYQ0KPj4gY29s bGVjdGlvbiBpbnRlcmZhY2UgdG8gdGhlbS4gIFRoZSBkb21haW4gcHJvcGVydHkgY291bGQgYmUg Y29udmVydGVkDQo+PiBpbnRvIGEgVVJJIGFuZCBsaXN0ZWQgaW4gdGhlIHJlc291cmNlIGRpcmVj dG9yeS4gIENvbnN0cnVjdGlvbiBvZiBhbg0KPj4gUkQgVVJJIGNvdWxkIGJlIHZpYSBhIHRlbXBs YXRlIGFzIHNob3duIGFib3ZlLg0KPj4NCj4+IEJlZm9yZSB3ZSBmdXJ0aGVyIGZsZXNoIG91dCB0 aGlzIGRlc2lnbiwgSSdkIGxpa2UgdG8ga25vdyB3aG8gaGFzDQo+PiBpbXBsZW1lbnRlZCBkb21h aW5zICh3aGljaCBhcmUgb3B0aW9uYWwgaW4gdGhlIGN1cnJlbnQgUkQpIGFuZCBob3cNCj4+IG11 Y2ggdGhleSB3b3VsZCBiZSBpbXBhY3RlZCBieSBzdWNoIGEgc2ltcGxpZmljYXRpb24uDQo+Pg0K Pj4gR3LDvMOfZSwgQ2Fyc3Rlbg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiBjb3JlIG1haWxpbmcgbGlzdA0KPj4gY29yZUBpZXRmLm9y Zw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo+DQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNvcmUgbWFp bGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jb3JlDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBjb25maWRl bnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LiBUaGUgbWVz c2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUocykuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQg YW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRo aXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBz ZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBvcmln aW5hbCBtZXNzYWdlLg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQpJTVBPUlRBTlQgTk9USUNFOiBU aGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRl bnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQg ZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQg Zm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkg bWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Fri May 5 07:14:19 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75C812940D for ; Fri, 5 May 2017 07:14:16 -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 vpA7pFFg4Z1u for ; Fri, 5 May 2017 07:14:14 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 BB00B129501 for ; Fri, 5 May 2017 07:14:09 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id b68so3397594ywe.3 for ; Fri, 05 May 2017 07:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7jAOpN63NuOK+FSaF9S7HnvDfSHesJd7AkGubZe6XRY=; b=P+RADM6ZZ1LpyjwY6wCyMc/hdn0x7DdwgkJqMu09ivQzo1eeb8DXoAn10Idm1KDkbQ V2e20Bop1uKqpCVg6wofj0xbhDBFzgMJIA6FFexLBiZP63Eg76pEfjuHlYc7eNxuZCWV H8HuXff38JwI062vZthmN0RkGTPiNJJjbST911ueT2XuBiWb8z2xy8HxdsA48GKJoJg9 EAxM20L/EbI1NsBHbILLzHRDNIi9msbprfCCJrWjXtMstrE72vW0xM1c3NmtkR0csMnq ec+M6JtpfLGQlvjoCkedjluG2QwkTOFk04unwHTkgLmmfoV1CFRRozQVt78NmZQIeS1c 9Yzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7jAOpN63NuOK+FSaF9S7HnvDfSHesJd7AkGubZe6XRY=; b=LKMNVgdqxmODNMG01KX1SmpvC0I7sng8lGMLsR5Qp0r5SYWnNIGLWtsrR/Cl2mLYxE 1PAVBa8W8eXPkK/2FmkcANrz88T77isuc61MmIzM9HPTd2MpU4wk6X6zYWOx5uQWhgYF /kHSBIYC8ttfgvb2ZpuQRoWTu+todGPMLB8olgkc4FDC4W4qfkTOfc+OrY6v2/zJ7ze3 Ku0iiE1/FgrIutPr4OlRaX18i2WpwJB0vUM6/8IWnJxucEmKPH18uWXVZR47CxJT5iSi Uuy2iJsHlPXg/K+dTi6yX//7Xw2CLx/BR0jzdJD6Rj08q7dvMDSDZnQgqg4kB7LYJaH5 +rTQ== X-Gm-Message-State: AN3rC/4zdokQTxRaYo3mb70VaoUb6x3qFMe7LeATYloG9by/1lBokVtm MBOTJZIqtA/srQ== X-Received: by 10.129.197.9 with SMTP id k9mr42055526ywi.69.1493993648859; Fri, 05 May 2017 07:14:08 -0700 (PDT) Received: from [10.0.0.14] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id v3sm2807852ywi.79.2017.05.05.07.14.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 05 May 2017 07:14:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: Date: Fri, 5 May 2017 07:14:05 -0700 Cc: "Dijk, Esko" , Carsten Bormann , "consultancy@vanderstok.org" , Core Content-Transfer-Encoding: quoted-printable Message-Id: References: <2688B534-A979-42F6-AC33-925817005F80@tzi.org> <75dc1a630fca3fd2e50fe13f867cb85b@xs4all.nl> <0bd0cd5aac2e444cbb625afc688f1c5f@AM3PR90MB0097.MGDPHG.emi.philips.com> To: Lauri Piikivi X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [core] Resource Directory: Simplifying Domains X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 14:14:17 -0000 Hi, It looks like we do not prohibit rd-lookup-* operations from returning = results from multiple domains.=20 I think one would need to use something like: GET /example/rd-lookup-res?d=3D"exampledomain"&rt=3Dcore.pubsub=20 to restrict results to one domain. Of course, one could have a policy that only allows particular = clients/users access to particular domains. I had not thought of the use case where registering with a domain ID = that doesn't exist would create it. We should explicity state in the = document if create-on-registration is optional, i.e. may be rejected = with a 4.xx code.=20 Best regards, Michael > On May 5, 2017, at 6:10 AM, Lauri Piikivi = wrote: >=20 >=20 > Hi alls, >=20 > We may have some misaligned definition for domain. V10 of the draft = says in definitions: > This specification assumes that the list > of Domains supported by an RD is pre-configured by that RD. When > a domain is exported to DNS, the domain value equates to the DNS > domain name. >=20 > But then we do allow the d=3D parameter for registrations. Also there = seems to be some weakness in the text with the domain being in the URI, = and then the location information in the response should have the same = domain? I think there would need to be some clarification also regarding = the authentication and access control of the device, as it would be very = natural to place a device in certain domain based on the certificate. = Access control may become very hard, if there are arbitrary domains. = Then again multiple groups seem to be needed for a more fine tuned = access control >=20 > In chapter 3 it says "The domain an endpoint is associated with can > be defined by the RD or configured by an outside entity. This > information hierarchy is shown in Figure 2." > Does that mean that the Device can configure it at run-time? The = Figure 2 could be clarified if multiple domains or groups are allowed. = It seems multiple groups are allowed, and a device can be in multiple = groups, as in chapter 7 there is an example "The following example shows = a client performing a lookup for all groups an endpoint belongs to" >=20 > I would like to keep it simple, 1 domain per endpoint, device can = propose but server dictates as the ep must be unique in the domain.So if = there is some configuration in directory it overrides device proposals. = For restful URIs, the domain and group should be in the URI for a = resource =E2=80=94 the location returned by the directory. That makes it = a bit clunky to have multiple groups for an endpoint. But it is possible = if we want multiple and arbitrary groups. >=20 > BR > - Lauri >=20 >=20 >> "On 04 May 2017, at 19:30, Dijk, Esko wrote: >>=20 >> Hello, >>=20 >> the proposed simplification would differ from the current Domain = concept. In the current concept, a registering endpoint (or a tool 'CT' = on its behalf) can create arbitrary new domains by putting in a = d=3D either in the URI or in the individual links being = registered. In the proposed concept, the Domains are limited to the = resources already pre-hosted at the RD. (E.g. /rd/domain1, /rd/domain2 - = only choice between these 2 domains and not arbitrary other ones.) >>=20 >> Agree with Peter that for the constrained endpoint (that's e.g. just = registering) it is easiest as written currently - it just registers = without d parameters to the default domain; without having to choose = between domains. >>=20 >> Esko >>=20 >> -----Original Message----- >> From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der = Stok >> Sent: Friday, April 21, 2017 9:04 >> To: Carsten Bormann >> Cc: Core >> Subject: Re: [core] Resource Directory: Simplifying Domains >>=20 >> Hi Carsten, >>=20 >> my hip gun shot reaction. >> The alternative seems more complex to handle than the original from = application point of view. >> In my opinion, the application ease of use takes precedence here. >>=20 >> Peter >>=20 >> Carsten Bormann schreef op 2017-04-20 20:15: >>> In the current resource directory, multiple domains are pretty much >>> ships in the night to each other; domains "compartmentalize" the RD. >>> After we had a discussion of RD domains between the authors, I'm no >>> longer sure we actually need all this mechanism. >>> Instead, each such compartment/domain could be modeled as a separate >>> resource directory of its own. >>> Multiple domains could be offered as multiple resource directories, >>> e.g. under >>>=20 >>> /rd/{domain} >>>=20 >>> (This does not mean that there need to be multiple copies of RD >>> software running etc., it just means a resource directory >>> implementation could offer multiple of the entry points called >>> "resource directories" under different URIs.) >>>=20 >>> The remaining questions are >>>=20 >>> -- how does a client find the resource directory for the domain it >>> wants to register under. >>> -- how does a client list the resource directories and find the >>> "domain" for each. >>>=20 >>> Listing the resource directories could simply be done by offering a >>> collection interface to them. The domain property could be = converted >>> into a URI and listed in the resource directory. Construction of an >>> RD URI could be via a template as shown above. >>>=20 >>> Before we further flesh out this design, I'd like to know who has >>> implemented domains (which are optional in the current RD) and how >>> much they would be impacted by such a simplification. >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >> ________________________________ >> The information contained in this message may be confidential and = legally protected under applicable law. The message is intended solely = for the addressee(s). If you are not the intended recipient, you are = hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message. >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sat May 6 12:57:01 2017 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F25120721; Sat, 6 May 2017 12:56:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-core-coap-tcp-tls@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149410061926.23090.18123119297312254432.idtracker@ietfa.amsl.com> Date: Sat, 06 May 2017 12:56:59 -0700 Archived-At: Subject: [core] Eric Rescorla's No Objection on draft-ietf-core-coap-tcp-tls-08: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 19:56:59 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-core-coap-tcp-tls-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Document: draft-ietf-core-coap-tcp-tls-08.txt TECHNICAL You need to specify MTI cipher suites. I don't think that the ones you specified in 7925 are very useful for TLS. Is this really really what you want? S 3.2. Having the lengths offset by 13 bytes is, IMO, pretty silly. I realize it avoids duplication, but it also makes the packets hard to read for not much value. As a practical matter, it expands the 1-byte length for the range 256-268, for a savings of less than .5% even on those packets and on average far less. S 4.1. The WebSocket client MUST include the subprotocol name "coap" in the list of protocols, which indicates support for the protocol defined in this document. Any later, incompatible versions of CoAP or CoAP over WebSockets will use a different subprotocol name. This doesn't make much sense, because you are willing to have incompatible protocols for TCP, where you use CSM to distinguish them, and you do the same thing with ALPN. S 5.5. These release semantics seem quite problematic. In particular, when people want an orderly close, they typically want the other side to process all the outstanding requests and then return them, but this doesn't seem to do that (note that just because the responses need to be *delivered* in order doesn't mean they need to be generated in order). So, for instance, say I have the following sequence of events: C S DB GET /a -> Request A -> Release -> FIN <- Response A It seems like the only difference between Abort and Release is that the sender is saying "don't expect that I processed any of your messages", but in at least a lot of scenarios (e.g., where the initiator is basically just a client), this doesn't actually tell the server much about sequence because the responses aren't ordered wrt Release AFAICT. Release message by closing the TCP/TLS connection. Messages may be in flight when the sender decides to send a Release message. The general expectation is that these will still be processed. This is not really useful language. For CoAP over reliable transports, the recipient rejects such messages by sending an Abort message and otherwise ignoring the message. No specific option has been defined for the Abort message in this case, as the details are best left to a diagnostic payload. I don't understand this text. Abort seems to mean "I'm done", but then how am I ignoring the message. S 6. I found this section pretty confusing. In 7959, when M=0 you need to stay *under* the block boundary but here you say: In descriptive usage, a BERT Option is interpreted in the same way as the equivalent Option with SZX == 6, except that the payload is also allowed to contain a multiple of 1024 bytes (non-final BERT block) or more than 1024 bytes (final BERT block). And your examples pretty clearly show it being >> 1024. What's the reasoning here In control usage, a BERT option is interpreted in the same way as the equivalent Option with SZX == 6, except that it also indicates the capability to process BERT blocks. But: Block-wise Transfer Option. If a Max-Message-Size Option is indicated with a value that is greater than 1152 (in the same or a different CSM message), the Block-wise Transfer Option also indicates support for BERT (see Section 6). Subsequently, if the Max-Message- Is this an instruction to set the BTO to be 7? Or redundancy? EDITORIAL S 3.2. Length (Len): 4-bit unsigned integer. A value between 0 and 12 directly indicates the length of the message in bytes starting I think you want to say "0 and 12 inclusive" S 5.3.1. These are not default values for the option, as defined in Section 5.4.4 in [RFC7252]. A default value would mean that an empty Capabilities and Settings message would result in the option being set to its default value. This is pretty confusing text. I take it that it means that if the base values of both A and B are 0, then: Start // A=0, B=0 CSM[A=1] // A=1, B=0 CSM[B=2] // A=1, B=2 Whereas if these were default values, then this would be: Start // A=0, B=0 CSM[A=1] // A=1, B=0 CSM[B=2] // A=0, B=2 <- A resets to default If that's so, perhaps you could say: These are not default values for the option, as defined in Section 5.4.4 in [RFC7252], because default values apply on a per-message basis and thus reset when the value is not present in a given CSM. From nobody Sat May 6 15:59:18 2017 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86788126BF0; Sat, 6 May 2017 15:59:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-core-coap-tcp-tls@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149411155754.23175.15150224037348429928.idtracker@ietfa.amsl.com> Date: Sat, 06 May 2017 15:59:17 -0700 Archived-At: Subject: [core] Eric Rescorla's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 22:59:17 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-core-coap-tcp-tls-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- After reading Mark Nottingham's review, I'm persuaded we should at least discuss the relationship of this work to the parallel work in HTTP. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Document: draft-ietf-core-coap-tcp-tls-08.txt TECHNICAL You need to specify MTI cipher suites. I don't think that the ones you specified in 7925 are very useful for TLS. Is this really really what you want? S 3.2. Having the lengths offset by 13 bytes is, IMO, pretty silly. I realize it avoids duplication, but it also makes the packets hard to read for not much value. As a practical matter, it expands the 1-byte length for the range 256-268, for a savings of less than .5% even on those packets and on average far less. S 4.1. The WebSocket client MUST include the subprotocol name "coap" in the list of protocols, which indicates support for the protocol defined in this document. Any later, incompatible versions of CoAP or CoAP over WebSockets will use a different subprotocol name. This doesn't make much sense, because you are willing to have incompatible protocols for TCP, where you use CSM to distinguish them, and you do the same thing with ALPN. S 5.5. These release semantics seem quite problematic. In particular, when people want an orderly close, they typically want the other side to process all the outstanding requests and then return them, but this doesn't seem to do that (note that just because the responses need to be *delivered* in order doesn't mean they need to be generated in order). So, for instance, say I have the following sequence of events: C S DB GET /a -> Request A -> Release -> FIN <- Response A It seems like the only difference between Abort and Release is that the sender is saying "don't expect that I processed any of your messages", but in at least a lot of scenarios (e.g., where the initiator is basically just a client), this doesn't actually tell the server much about sequence because the responses aren't ordered wrt Release AFAICT. Release message by closing the TCP/TLS connection. Messages may be in flight when the sender decides to send a Release message. The general expectation is that these will still be processed. This is not really useful language. For CoAP over reliable transports, the recipient rejects such messages by sending an Abort message and otherwise ignoring the message. No specific option has been defined for the Abort message in this case, as the details are best left to a diagnostic payload. I don't understand this text. Abort seems to mean "I'm done", but then how am I ignoring the message. S 6. I found this section pretty confusing. In 7959, when M=0 you need to stay *under* the block boundary but here you say: In descriptive usage, a BERT Option is interpreted in the same way as the equivalent Option with SZX == 6, except that the payload is also allowed to contain a multiple of 1024 bytes (non-final BERT block) or more than 1024 bytes (final BERT block). And your examples pretty clearly show it being >> 1024. What's the reasoning here In control usage, a BERT option is interpreted in the same way as the equivalent Option with SZX == 6, except that it also indicates the capability to process BERT blocks. But: Block-wise Transfer Option. If a Max-Message-Size Option is indicated with a value that is greater than 1152 (in the same or a different CSM message), the Block-wise Transfer Option also indicates support for BERT (see Section 6). Subsequently, if the Max-Message- Is this an instruction to set the BTO to be 7? Or redundancy? EDITORIAL S 3.2. Length (Len): 4-bit unsigned integer. A value between 0 and 12 directly indicates the length of the message in bytes starting I think you want to say "0 and 12 inclusive" S 5.3.1. These are not default values for the option, as defined in Section 5.4.4 in [RFC7252]. A default value would mean that an empty Capabilities and Settings message would result in the option being set to its default value. This is pretty confusing text. I take it that it means that if the base values of both A and B are 0, then: Start // A=0, B=0 CSM[A=1] // A=1, B=0 CSM[B=2] // A=1, B=2 Whereas if these were default values, then this would be: Start // A=0, B=0 CSM[A=1] // A=1, B=0 CSM[B=2] // A=0, B=2 <- A resets to default If that's so, perhaps you could say: These are not default values for the option, as defined in Section 5.4.4 in [RFC7252], because default values apply on a per-message basis and thus reset when the value is not present in a given CSM. From nobody Sat May 6 22:49:03 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@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: [core] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 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:07 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@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: [core] [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 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:27 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD02E1205F0 for ; Sun, 7 May 2017 21:52:26 -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 Mx_HKGHhHQ9U 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 22A5C128DF2 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: [core] [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 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:24 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@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: [core] [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 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:43:41 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29301243FE for ; Mon, 8 May 2017 00:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.079 X-Spam-Level: X-Spam-Status: No, score=0.079 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 MbmU26Q7TgTo for ; Mon, 8 May 2017 00:43:37 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A8A120724 for ; Mon, 8 May 2017 00:43:37 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:200]) by smtp-cloud6.xs4all.net with ESMTP id HjjU1v00F5W6tKc01jjUsM; Mon, 08 May 2017 09:43:29 +0200 Received: from 2001:983:a264:1:dc54:e466:7fb6:5f27 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 08 May 2017 09:43:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 08 May 2017 09:43:28 +0200 From: peter van der Stok To: Lauri Piikivi Cc: "Dijk, Esko" , Carsten Bormann , consultancy@vanderstok.org, Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <2688B534-A979-42F6-AC33-925817005F80@tzi.org> <75dc1a630fca3fd2e50fe13f867cb85b@xs4all.nl> <0bd0cd5aac2e444cbb625afc688f1c5f@AM3PR90MB0097.MGDPHG.emi.philips.com> Message-ID: <47fc672effd46a2f414c8eca1440d6cc@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [core] Resource Directory: Simplifying Domains X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 07:43:40 -0000 Hi Lauri, a partial response, > We may have some misaligned definition for domain. V10 of the draft > says in definitions: > This specification assumes that the list > of Domains supported by an RD is pre-configured by that RD. When > a domain is exported to DNS, the domain value equates to the DNS > domain name. Thanks for pointing this out. There clearly is confusion about the use of domain in the RD, and its eventual use as the DNS domain. I agree that this confusion must be removed. In my mind there are two domain concepts: the RD one and the DNS one. IMO, It is the responsibility of the RD to DNS mapping agent to specify restrictions if the RD domain is mapped to the DNS domain. Peter From nobody Mon May 8 00:49:14 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@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: [core] [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 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:38 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@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: [core] [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 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 00:50:30 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91701270B4 for ; Mon, 8 May 2017 00:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.onmicrosoft.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 zdAkhLtuzMYf for ; Mon, 8 May 2017 00:50:25 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50125.outbound.protection.outlook.com [40.107.5.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82B241252BA for ; Mon, 8 May 2017 00:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CgFYjVmLjgH7QVxCdYShWVr0zEOmlvAYs/J19PozQCI=; b=UVy0aEDH+I7e7tCm9o7nMCSW71d5BBlm8kn17izlMKBgGs3VKBdkskdsIW+1B2nMHwYdsShFlpUPvPXIVjV5FVQ/t0SvcYlWTW/Ox7skM1oyMoI5jEdspv0U6yfBm1HbK6P5qDItaleWmSXFmtesaI5oUWcwZV4/uhFnH2RrANU= Received: from HE1P122CA0011.EURP122.PROD.OUTLOOK.COM (2603:10a6:23:25::17) by VI1P122MB0045.EURP122.PROD.OUTLOOK.COM (2603:10a6:820:1c::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11; Mon, 8 May 2017 07:50:16 +0000 Received: from AM1FFO11FD025.protection.gbl (2a01:111:f400:7e00::111) by HE1P122CA0011.outlook.office365.com (2603:10a6:23:25::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11 via Frontend Transport; Mon, 8 May 2017 07:50:16 +0000 Authentication-Results: spf=neutral (sender IP is 23.103.228.36) smtp.mailfrom=philips.com; vanderstok.org; dkim=none (message not signed) header.d=none; vanderstok.org; dmarc=none action=none header.from=philips.com; Received-SPF: Neutral (protection.outlook.com: 23.103.228.36 is neither permitted nor denied by domain of philips.com) Received: from 011-smtp-out.Philips.com (23.103.228.36) by AM1FFO11FD025.mail.protection.outlook.com (10.174.64.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.9 via Frontend Transport; Mon, 8 May 2017 07:50:15 +0000 Received: from AM3PR90MB0097.MGDPHG.emi.philips.com (141.251.117.145) by AM3PR90MB0097.MGDPHG.emi.philips.com (141.251.117.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11; Mon, 8 May 2017 07:50:15 +0000 Received: from AM3PR90MB0097.MGDPHG.emi.philips.com ([141.251.117.145]) by AM3PR90MB0097.MGDPHG.emi.philips.com ([141.251.117.145]) with mapi id 15.01.1075.019; Mon, 8 May 2017 07:50:15 +0000 From: "Dijk, Esko" To: "consultancy@vanderstok.org" , Lauri Piikivi CC: Carsten Bormann , Core Thread-Topic: [core] Resource Directory: Simplifying Domains Thread-Index: AQHSugIoVokwIT4YwUqXPWdHbAWFSaHPZwQAgBUKTjCAAVyWgIAEW6MAgAAA2NA= Date: Mon, 8 May 2017 07:50:15 +0000 Message-ID: <0c5863c6f5d341c7af35e3147815e961@AM3PR90MB0097.MGDPHG.emi.philips.com> References: <2688B534-A979-42F6-AC33-925817005F80@tzi.org> <75dc1a630fca3fd2e50fe13f867cb85b@xs4all.nl> <0bd0cd5aac2e444cbb625afc688f1c5f@AM3PR90MB0097.MGDPHG.emi.philips.com> <47fc672effd46a2f414c8eca1440d6cc@xs4all.nl> In-Reply-To: <47fc672effd46a2f414c8eca1440d6cc@xs4all.nl> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.200.35.197] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 6e54618b-56c2-448d-9932-08d495e6dd95 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: AM3PR90MB0097.MGDPHG.emi.philips.com X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:23.103.228.36; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39400400002)(39850400002)(39860400002)(39450400003)(39410400002)(2980300002)(13464003)(374574003)(55904004)(85714005)(199003)(189002)(9170700003)(46406003)(2501003)(2906002)(66066001)(55016002)(33646002)(47776003)(105586002)(106466001)(50466002)(8936002)(38730400002)(8746002)(2950100002)(7696004)(4326008)(6116002)(3846002)(102836003)(23726003)(86362001)(5660300001)(53546009)(478600001)(6246003)(81166006)(356003)(305945005)(53936002)(108616004)(76176999)(54356999)(229853002)(97756001)(7736002)(50986999)(8676002)(93886004)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1P122MB0045; H:011-smtp-out.Philips.com; FPR:; SPF:Neutral; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD025; 1:ra/GjWoh3RqF5qmoI4SKPnpBy6aLCd3JPbj2sacEMw7nXHtKIfuSen6bpgoClvonH3rT59cY8fcsgdxMB20dSG9YXeM/xiWeeXd2fYSTFOI13D7FAvILS6288joIKZNo4qNnhPSXK9y4HK1XsgUtE9YcdW07S985juFPNajwuMMPS+MGDC66CAxa+Hn8dvndA/5v7A4HqbmGqLMcWJPlrWtQ/vP77UKzpo+SsFypCDccoRAfxAyNi7/881VRKcDPG+soJaDfazJupILapHb7Wb7hJgnYXiRhx7yWs+B7AYGwbydZpgvBErVG8awu3EGJ3XrtGThOi6byfCD93Td0+lhDC/en6px8NqppyyTPNAmLib9PbPAkxPLmHWT3dxevt8mJujyplryM3BUl8V9YrtGlXmhIyb9QMem0vNOiWtBDBZ6QwlAwUVoNboc0yTxlVmA3ZBucxeUN3sFOZOt32x3gtW00CRvHCAFdzCShx5CSt+n5f+Dj6o0IrEo36/Nh2omTyDdz3xNF1blnx4PpFajHoNf2NVjL8qg0oOQ75tw= X-CrossPremisesHeadersPromoted: AM1FFO11FD025.protection.gbl X-CrossPremisesHeadersFiltered: AM1FFO11FD025.protection.gbl X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1P122MB0045; X-Microsoft-Exchange-Diagnostics: 1; VI1P122MB0045; 3:RO1IhQy5VTplyz3q5orDv8PMMpIxPIZshwuC+zklM0k5MG3cbNSYIdMhUTEsDd3ziQGxS0Hf09S1pmlGDaDw8Y0zfble90r5XCn9i54xmIQ+jRIk749h0DzqUv8mUhEsEUeDL+v7zD6HegDsv50WcWdLr0WlH1Re0X81Q9JS8z6f3z5blSlxPWPB8R4PXGFBB48xNyZl88q75X8Xu1MguWJXah7UQUKm0QiNphJY3uCkvpk5bvojZdX5inNypg0mCDLbIVHSGxA1K2IGSAQO+EiZBGSt+fSy9iAVA5doHN9L3OxN21svfXDz/MrVnqeFqBgfufdL72g0vT8QyXu+syw2XVMQSBaUaQ5Fc4UKYEGgS9gegwVsNKl7BoTxcPkYFSOMfJpCdUOSlitKj6usK+a1RtZO8KWGPmjMKQjJ2iVV0AOQxh2QCCpe5w6n/EhdafCdvi4F4h1P+In9BC4fLLe4Y6a2N0HoCAHA6x4ShqDgmAtlXWpM/rzRJ8fW+bF4 X-Microsoft-Exchange-Diagnostics: 1; VI1P122MB0045; 25:MGZ7ecpzZeBRXEXsw8jUFR1uNWChAz9xrfsAYL5UJHoK/XMnR5zhTTpovid1dRDdvhPpugg9tkVgkYdiCJFaj+2icMLNX5q5anNx/1SIJTtm7B5XSVbxRVI3hVajKiAcagt0nb05VRiwICXPADy1eD8EjMv46hkECNrvaNYQadayzfcFGl3KW9hnBfQI9DLpqh6CFwCtVb1HHKRZpS+y846FT47zZ77DCEEY9BodL+3aeeN8w/ZjBZpklsvFiT2TUh3NI7hU8rBy7g9dQVZ6UhKHanZ84FTA35RKzGLXqQq7Xn1+rDJqkXVEHXI4yp8FddSnp3Y4wQ+OjC6596+R00yN8PKJzFui1gbPs5oI5x342fc5uMy5eq3HfeBBjC/sECzghz+6SZBGamqGos6EXhXfmYmcIxn8yjmTbFvwECn2b/uU9SuBNTumgH2sRXE1kFRl+166fQO+eC9Lcup5atiJlEq1/AqhW6JjD4suacY=; 31:mvvQCEF7CfuaWjc+KOOkjnkxzQQFPYXIzCpI+hfDg+/uOjYIGF9HSDSTVUGPeusXC2uTjdcfyavk2l2/F23cBDnhJ6hXwIYg7qUZtX+ujjKZw407//KuBc6uZ6ec8sd9Bb6Egt14uNljI8royeqVGjckcdGshfXZPm9MJNee85AKhs9AW7Hxm+cxCAX0ZN98pcw3W+vc0ODWagw84uI/m9eJ+Rs2R/sQHzZrKnSssddSPKmCtKdYH14bY+tamf3jHtBnIJaVCJrOS1YlqfwXbQ== X-Microsoft-Exchange-Diagnostics: 1; VI1P122MB0045; 20:6dUCN4a8aK8Ts2ob+IVHSDHCUIDZjp5nn0MoWWy4dICB3708QRCd0jGAyOHii7s7CzEvE0QbEY6ONwZcRLYavw1g0+zISXGJw4Xokm68uV2GcFEQSsAW5rfoElOth6Ji84dd5iuBWCHx6api7xRGk3dcl+atMYGFZnGI63MPkRkhZWHe6KSaW4JTRzXPKP09uLDS1o3wV8vj5b6EHvLAZRc0U8HwhBIjY3ClYzwIKCR+zyr2LexBPLtQli6TZZ9En9n3v46M63lWYCgTh40XgxraoNyAM3MUCr9kWxyoe0mhgCyYnf8Kk1GQdVfUWStXEY6fltmBeW6LOiJ/bOg4uPDI0walcVTUk7eNVtttchJYt+x8WPk6I1KxuTLh5oKVnewnqvtUPUvnFVivVQ5lkS+G9l+05KDQ7nyK1thT5ed+KoR9Rm2KlVWlnxLXs9B7T5LeQKKEvimGHwAIcc6/1IvRdPfBhWQ99hoeR55uzNajPS2Edbm+Y1l6Ouzm3Fqa X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(180628864354917)(260087099026482); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(13018025)(5005006)(8121501046)(13016025)(93006095)(93003095)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:VI1P122MB0045; BCL:0; PCL:0; RULEID:; SRVR:VI1P122MB0045; X-Microsoft-Exchange-Diagnostics: 1; VI1P122MB0045; 4:jS4sDQENp9ot+Zvu0drW07RxwlpGARoQUDJEX3tUAXYCyGCYG3OfvJOBtn3QfYVtzxoAQRq5ALk8qE0ep5ZYoVBngw2K+GA6dFJNQFISx8Co5W47COFjat3YTx+zudYcl8YGoOmFC9HqdvYaC7PxSyF95FlYXkHYHqOgLElaeFahACkUlikzdOHGl8+sS7X3z2cC5vYXTWSvDnWd/5GAe1rKrIiW37GQfvhn78wjq8W6NobIKeFc2WUdXNeceAYNoX/BQ5zdizCbtNaDBkV++AhFZfn783rQwvV/q15ES4zxgFBXrrIthSH+WlhZbnc1qqgcNymlWcUdqYVnrOpj0ArRLe1FxVtnpzEqSIW17mbaCM05giaJOrrqxrH3/w8bM4TkHI5dBJYPwjykTZTrgZBSSt2abUvQJ65IJNFNJrXJJS+O3Z02PwFasB86CH3DRS8XxlEORveeCz+aNY9ECgH4+KPWRPCFXX23Voam+EHIEFj4qpkMSWg7PlOsEiUSYNx0Z/st63MEkZfqe471FHbZmT+6Xbl5acENzxHSAQyDGBIoMIwk50HOypX8FdX6W7tY9SEUUpmHjcBTnheohErK2WOsSGcmbAup4y83YTDLYzePziMOh5Ta+jKmzSZ9gL4k0UiQmpRmuUmTvpRRwU8vGlnQ+bwnT+HlZ7tYRi9Skja6twymrCpWfBE/4WUfABoKCavgepoGDEYmOM+9pHiMCjS2cnHHhDGcxlYLxx+33q+nJL3ZdNY1VpPSgBfBL5EgKuRMmRBfuhSZpl5neqw0UjtsknaxImqO/Jkv6G8X7xkXH5PxS4HkbFh4MbpkYCHWE+KnCGOv3BsaRwXG7fjRPIEXQ1Z/nbUH8JegRBSk03cR1rLTLWj3cqxKH4DDeCSlnuN4bA9UHU2eXSNzJw== X-Forefront-PRVS: 0301360BF5 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1P122MB0045; 23:ILQ0qqt/oUV4OUAddFP3yUzoNAYDtQlX0wGtCPzER?= =?us-ascii?Q?5dpjic0Eu/+bGCIAsV0ugSll2ldczmCqJyqj+MpMj4ykx9uB5bo+PIjopyzi?= =?us-ascii?Q?wL5ZFa9uV3wnOGOKSbpFTdieeUhVT4bU4gdbuK3xVhJYacKV0A7DeeJ7jhKM?= =?us-ascii?Q?0cx+2m2clkK3FGLZRrSi2z9wdKpdyrGLEbHxWETEWj6BhyYiNyDi/aTGwlEJ?= =?us-ascii?Q?6o6DoOPsThKuD61Y43nFMfFmOUAcswlVl6OQ860hPkSujsVKbo+7uQbaxszi?= =?us-ascii?Q?Lf29NkpHq+eSid41Qs8xpoDX7qj5UaslhGMyCgvlnX6t1U8JXm7AT+8OIDFR?= =?us-ascii?Q?f+CsmGXd1A5x6ResLvkjFbCUYUlfFESvOyQQKF4xY5cyNFvep1Iz3Dpc6ZqV?= =?us-ascii?Q?rqRjJS3J/CjNvL036dr+kKNwd7xSgNJ8+KVo4itL13TyKfIz5DbdB9BMeOAY?= =?us-ascii?Q?vI9PdoPXhE6Z5UruH4pAuePUdh7ti6If2KDOlnv9PmbScKmt0qxvO+ttrnkG?= =?us-ascii?Q?FV6+gZ3iPf1TZ/7dKjlx9QDXI8nNOnRSvJB/FpUux75RtOkD6qslIxoX38Qa?= =?us-ascii?Q?Z5hlBlAETNQ52O1yF20Qd+mCiFUHOFTDA67Nv/xvpPXBIrQRCUeH/+xZKjF8?= =?us-ascii?Q?qx0dcUU6sfu7cen0glozUp8KZBYjB5RBEmDwBN3yHf9UBAxObghtYS08rcot?= =?us-ascii?Q?25onUDrSrLJ5p+n8UUuuD4rcuy/pkzUIo6e26BLFcpmOiqHydTOHWFrl+eyu?= =?us-ascii?Q?8XTWbbE57E6UThEcEMP53JOLFZIl3RxR2AXHuJ7II/ZWU63SJAtWR0bwtF2N?= =?us-ascii?Q?QJuLtkeh2VAqBfjH7oHhuKPDKA2TCjDu26yaihyEOW96W76XA8LtcpsmwURd?= =?us-ascii?Q?enjqm1tX8kRpjvHEhEuBhufq/gO5EeQG2zAiL9/vpCel/d1qvXR7Xzq2lXcP?= =?us-ascii?Q?Sprb0jHCc/tZXe7dSPweFjJbQGrpRR4EkTjK1NOBKv4SooV9m7Q1H8yL9y9r?= =?us-ascii?Q?Vk/xg9Ezv9jzs2pNNfKQja89C/4qg0aiPMgBuvhzzf1K0wDaeCdbxj+rTiOc?= =?us-ascii?Q?QjmvlimU7hrGvmHdH8sTEQoMUd/N23jNLmGG5EJ1ws55LBtbUm8uPc3Ch3IJ?= =?us-ascii?Q?PsDY/z4iMptvAURhN6lOMci7vo4cziwtTiF4QUHts9g0A294Fmz7Q7BLoDEU?= =?us-ascii?Q?SKu+5eXCXw1QjQKf8SZ5YDKCdGDUP+mR/KaMAJUpWGOier15M4uCSLf+t2/m?= =?us-ascii?Q?aq0qUbr6fVKh2FRQHhBWN6rwfzimBu4ggVp7wjeUEhkivnc4ext/13Vtvcca?= =?us-ascii?Q?Ucbpn5JQkf/PiwHnuqSNTY=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1P122MB0045; 6:2Ch36Zkiw1q096kma56eYW9jbXdtuvfNxfNOZYnwE/XzXSYQ6LA6urlJWyNXojKeAHGm4sHoHYyszTfnCL7tSMoYhp+96HU4e0v4o92nyuP/oJHlV9ACC8OWObD8AJltluWw3WQfbfAIBr/HcoXt1vpf3YsqJc3AxBt5atzNiLeMG7IpfjZcWMn8LTBSciRxID9mq1dwpb2a5WK/Ro6kWpdpBfaNwMhTB4up8Ws/Jrr5re87PCAninaTlta9iku4Ojqk/e0hIAI0Ae89tZ8FYlmqsbw5NU4eMOheM5F7xzhIzTAvgpvr29z65CBPY+NjkqYOi/PFt0Eupe6j1kBkD+nAm13/E3D5Xp+zrCi++Q8/HVPDZiGHTpqjhEPQuUX5DlVX2LjZKC7YaXWPQ96KSh4a00XGKZhqZkr4/Lqw9S8znnmATgN4dQ6XPUcSwpom1QY6nCJCr81J/9215cSyCxbuUa8aXA5/3ILSQ1SJdrSeBSOcNVgglpC+5Zz/U6fIhXXIYtxbsJmNcIzEzlhI7I2q/YiR9VMSR/r82ZKGJQA=; 5:HovBpx/lrIy8CerKCIsGe5YwPV5izJ05y+aQEhBQ0M17+UiS9F95rUoOrkOiFtxAq1TGudTrDXN4kkj0Y4kIxaf1dS56DBx7TzhCzDX4AOQkbOtsZaFcjInD0VC0dXyYJwgm1CTxgInIT1sunzcYSg==; 24:c1qNXuTVyxohhraSwLSwG2HdAEtjZVmDarF2t3io5FM1njjvP3M+o6jMFjsgY6olhNQ487hb0R5KA090otfKMGtP9yVPY+N3EqCi/5nqPns= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1P122MB0045; 7:OU9SdS5he1GZtoLn6Zv2ZTluiPExBvfGea8SBKCqBPK+I7ozzuIhqENbWncI55FxrB3RB1ottMprgAF8okg1u25K5E00ElwDKip/c3gpGz8J5uGtPKuRyLikbiOqJsgttRj5cjzQrfZIezRpysl0WXZAFlG9py/8kOwRXH3Zb5OU12zQeKkOH75Ta97rjGqK5oNZlYpJ9l8sEpGY9cMH2Ywwwo9zbT1bhBLA95FF4eXrEOqKL9UR5vSFignaSj9V0cY/LYWN1lPEbFngoCw6DnPByOMKbg93BeTjVrn2lnDjGzJ/lhIN9I3SWb2cee80xZtohj1MmyFB6Jztt8ygsg== X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 May 2017 07:50:15.7732 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.228.36]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P122MB0045 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: AM3PR90MB0097.MGDPHG.emi.philips.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 89.200.35.197 X-MS-Exchange-CrossPremises-transporttraffictype: Email X-MS-Exchange-CrossPremises-transporttrafficsubtype: X-MS-Exchange-CrossPremises-disclaimer-hash: 7fd5309d68bb4378c576a4d2c2ad972d336f5eb0475879c2a0b14da1aac98972 X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-OrganizationHeadersPreserved: VI1P122MB0045.EURP122.PROD.OUTLOOK.COM Archived-At: Subject: Re: [core] Resource Directory: Simplifying Domains X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 07:50:28 -0000 Michael, currently the ad-hoc creation of domains follows from the text e.g. the exa= mples on page 40 . There each room in a building gets its own Domain in the= RD. Now the RD can't possibly know these room IDs beforehand, so these are= created on-the-fly. A Commissioning Tool (CT) as in that example would typically know which Dom= ain a device is to be assigned to, however the endpoint itself (if doing th= e registration itself) would typically not know this - so it would use the = default domain. @Peter, agree that in the way currently Domains are defined and used , some infrast= ructure entity (the RD itself?) is responsible for mapping it do a DNS doma= in. E.g. if the CT register a node under domain d=3DR2-4-015 then this enti= ty would know that it maps to DNS 'R2-4-015.building.example.com' for exa= mple. But the 'RD to DNS mapping agent' is not mentioned in the I-D so ma= y be good to clarify this more. (Also where this entity resides.) Esko -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl] Sent: Monday, May 08, 2017 9:43 To: Lauri Piikivi Cc: Dijk, Esko ; Carsten Bormann ; con= sultancy@vanderstok.org; Core Subject: Re: [core] Resource Directory: Simplifying Domains Hi Lauri, a partial response, > We may have some misaligned definition for domain. V10 of the draft > says in definitions: > This specification assumes that the list > of Domains supported by an RD is pre-configured by that RD. When > a domain is exported to DNS, the domain value equates to the DNS > domain name. Thanks for pointing this out. There clearly is confusion about the use of domain in the RD, and its event= ual use as the DNS domain. I agree that this confusion must be removed. In my mind there are two doma= in concepts: the RD one and the DNS one. IMO, It is the responsibility of the RD to DNS mapping agent to specify res= trictions if the RD domain is mapped to the DNS domain. Peter ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From nobody Mon May 8 02:39:32 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F80128C84 for ; Mon, 8 May 2017 02:39:23 -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 5TjXdPcHRGhV for ; Mon, 8 May 2017 02:39:21 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6E45F1292FD 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: [core] [Tsv-art] TSV-ART review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 09:39:23 -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 21:51:26 2017 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD58129AB6; Mon, 8 May 2017 21:51:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-core-coap-tcp-tls@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149430548476.30014.11810513211435340238.idtracker@ietfa.amsl.com> Date: Mon, 08 May 2017 21:51:24 -0700 Archived-At: Subject: [core] Adam Roach's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 04:51:25 -0000 Adam Roach has entered the following ballot position for draft-ietf-core-coap-tcp-tls-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- - Part of the document is outside the scope of the charter of the WG which requested its publication While I understand that this document requires a WebSockets mechanism for .well-known, and that such a mechanism doesn鈥檛 yet exist, it seems pretty far out of scope for the CORE working group to take on defining this itself (unless I missed something in its charter, which is entirely possible: it鈥檚 quite long). Specifically, I fear that this venue is unlikely to bring such a change to the attention of those people best positioned to comment on whether .well-known is appropriate for WebSockets. Even if this is in scope for CORE, it really needs to be its own document. If some future document comes along at a later point and wants to make use of its own .well-known path with WebSockets, it would be really quite strange to require it to reference this document in describing .well-known for WS. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- General 鈥 this is a very bespoke approach to what could have been mostly solved with a single four-byte 鈥渓ength鈥 header; it is complicated on the wire, and in implementation; and the format variations among CoAP over UDP, coap+tls, and coap+ws are going to make gateways much harder to implement and less efficient (as they will necessarily have to disassemble messages and rebuild them to change between formats). The protocol itself mentions gateways in several places, but does not discuss how they are expected to map among the various flavors of CoAP defined in this document. Some of the changes seem unnecessary, but it could be that I鈥檓 missing the motivation for them. Ideally, the introduction would work harder at explaining why CoAP over these transports is as different from CoAP over UDP as it is, focusing in particular on why the complexity of having three syntactically incompatible headers is justified by the benefits provided by such variations. Additionally, it鈥檚 not clear from the introduction what the motivation for using the mechanisms in this document is as compared to the techniques described in section 10 (and its subsections) of RFC 7252. With the exception of subscribing to resource state (which could be added), it seems that such an approach is significantly easier to implement and more clearly defined than what is in this document; and it appears to provide the combined benefits of all four transports discussed in this document. My concern here is that an explosion of transport options makes it less likely that a client and server can find two in common: the limit of the probability of two implementations having a transport in common as the number of transports approaches infinity is zero. Due to this likely decrease in interoperability, I鈥檇 expect to see some pretty powerful motivation in here for defining a third, fourth, fifth, and sixth way to carry CoAP when only TCP is available (I count RFC 7252 http and https as the first and second ways in this accounting). I鈥檓 also a bit puzzled that CoAP already has an inherent mechanism for blocking messages off into chunks, which this document circumvents for TCP connections (by allowing Max-Message-Size to be increased), and then is forced to offer remedies for the resultant head-of-line blocking issues. If you didn鈥檛 introduce this feature, messages with a two-byte token add six bytes of overhead for every 1024 bytes of content 鈥 less than 0.6% size inflation. It seems like a lot of complicated machinery 鈥 which has a built-in foot-gun that you have to warn people about misusing 鈥 for a very tiny gain. I know it鈥檚 relatively late in the process, but if these trade-offs haven't had a lot of discussion yet, it鈥檚 probably worth at least giving them some additional thought. I鈥檒l note that the entire BERT mechanism seems to fall into the same trap of adding extra complexity for virtually nonexistent savings. CoAP headers are, by design, tiny. It seems like a serious over-optimization to try to eliminate them in this fashion. In particular, you鈥檙e making the actual implementation code larger to save a trivial number of bits on the wire; I was under the impression that many of the implementation environments CoAP is intended for had some serious on-chip restrictions that would point away from this kind of additional complexity. Specific comments follow. Section 3.3, paragraph 3 says that an initiator may send messages prior to receiving the remote side鈥檚 CSM, even though the message may be larger than would be allowed by that CSM. What should the recipient of an oversized message do in this case? In fact, I don鈥檛 see in here what a recipient of a message larger than it allowed for in its CSM is supposed to do in response at *any* stage of the connection. Is it an error? If so, how do you indicate it? Or is the Max-Message-Size option just a suggestion for the other side? This definitely needs clarification. (Aside 鈥 it seems odd and somewhat backwards that TCP connections are provided an affordance for fine-grained control over message sizes, while UDP communications are not.) Section 4.4 has a prohibition against using WebSockets keepalives in favor of using CoAP ping/pong. Section 3.4 has no similar prohibition against TCP keepalives, while the rationale would seem to be identical. Is this asymmetry intentional? (I鈥檒l also note that the presence of keepalive mechanisms in both TCP and WebSockets would seem to make the addition of new CoAP primitives for the same purpose unnecessary, but I suspect this has already been debated). Section 5 and its subsections define a new set of message types, presumably for use only on connection-oriented protocols, although this is only implied, and never stated. For example, some implementors may see CSM, Ping, and Pong as potentially useful in UDP; and, finding no prohibition in this document against using them, decide to give it a go. Is that intended? If not, I strongly suggest an explicit prohibition against using these in UDP contexts. Section 5.3.2 says that implementations supporting block-wise transfers SHOULD indicate the Block-wise Transfer Option. I can't figure out why this is anything other than a "MUST". It seems odd that this document would define a way to communicate this, and then choose to leave the communicated options as 鈥淵ES鈥 and 鈥淵OUR GUESS IS AS GOOD AS MINE鈥 rather than the simpler and more useful 鈥淵ES鈥 and 鈥淣O鈥. I find the described operation of the Custody Option in the operation of Ping and Pong to be somewhat problematic: it allows the Pong sender to unilaterally decide to set the Custody Option, and consequently quarantine the Pong for an arbitrary amount of time while it processes other operations. This seems impossible to distinguish from a failure-due-to-timeout from the perspective of the Ping sender. Why not limit this behavior only to Ping messages that include the Custody Option? I find the unmotivated definition of the default port for 鈥渃oaps+tcp鈥 to 443 鈥 a port that is already assigned to https 鈥 to be surprising, to put it mildly. This definitely needs motivating text, and I suspect it's actually wrong. I am similarly perplexed by the hard-coded 鈥渕ust do ALPN *unless* the designated port takes the magical value 5684鈥 behavior. I don鈥檛 think I鈥檝e ever seen a protocol that has such variation based on a hard-coded port number, and it seems unlikely to be deployed correctly (I鈥檓 imaging the frustration of: 鈥淚 changed both the server and the client configuration from the default port of 5684 to 49152, and it just stopped working. Like, literally the *only* way it works is on port 5684. I've checked firewall settings everywhere and don't see any special handling for that port -- I just can't figure this out, and it's driving me crazy.鈥). Given the nearly universal availability of ALPN in pretty much all modern TLS libraries, it seems much cleaner to just require ALPN support and call it done. Or *don鈥檛* require ALPN at all and call it done. But *changing* protocol behavior based on magic port numbers seems like it鈥檚 going to cause a lot of operational heartburn. The final paragraph of section 8.1 is very confusing, making it somewhat unclear which of the three modes must be implemented on a CoAP client, and which must be implemented on a CoAP server. Read na茂vely, this sounds like clients are required to do only one (but one of their choosing) of these three, while servers are required to also do only one (again, of their choosing). It seems that the chance of finding devices that could interoperate under such circumstances is going to be relatively low: to work together, you would have to find a client and a server that happened to make the same implementation choice among these three. What I鈥檓 used to in these kinds of cases is: (a) server must implement all, client can choose to implement only one (or more), (b) client must implement all, server can choose to implement only one (or more), or (c) client and server must implement a specifically named lowest-common denominator, and can negotiate up from there. Pretty much anything else (aside from strange 鈥渆veryone must implement two of three鈥 schemes) will end up with interop issues. Although the document clearly expects the use of gateways and proxies between these connection-oriented usages of CoAP and UDP-based CoAP, Appendix A seems to omit discussion or consideration of how this gatewaying can be performed. The following list of problems is illustrative of this larger issue, but likely not exhaustive. (I'll note that all of these issues evaporate if you move to a simpler scheme that merely frames otherwise unmodified UDP CoAP messages) Section A.1 does not indicate what gateways are supposed to do with out-of-order notifications. The TCP side requires these to be delivered in-order; so, do this mean that gateways observing a gap in sequence numbers need to quarantine the newly received message so that it can deliver the missing one first? Or does it deliver the newly-received message and then discard the 鈥渟tale鈥 one when it arrives? I don鈥檛 think that leaving this up to implementations is particularly advisable. Section A.3 is a bit more worrisome. I understand the desired optimization here, but where you reduce traffic in one direction, you run the risk of exploding it in the other. For example, consider a coap+tcp client connecting to a gateway that communicates with a CoAP-over-UDP server. When that client wants to check the health of its observations, it can send a Ping and receive a Pong that confirms that they are all alive and well. In order to be able to send a Pong that *means* 鈥渁ll your observations are alive and well,鈥 the gateway has to verify that all the observations are alive and well. A simple implementation of a gateway will likely check on each observed resource individually when it gets a Ping, and then send a Pong after it hears back about all of them. So, as a client, I can set up, let鈥檚 say, two dozen observations through this gateway. Then, with each Ping I send, the gateway sends two dozen checks towards the server. This kind of message amplification attack is an awesome way to DoS both the gateway and the server. I believe the document needs a treatment of how UDP/TCP gateways handle notification health checks, along with techniques for mitigating this specific attack. Section A.4 talks about the rather different ways of dealing with unsubscribing from a resource. Presumably, gateways that get a reset to a notification are expected to synthesize a new GET to deregister on behalf of the client? Or is it okay if they just pass along the reset, and expect the server to know that it means the same thing as a deregistration? Without explicit guidance here, I expect server and gateway implementors to make different choices and end up with a lack of interop. >From i-d nits (this appears to be in reference to Figure 1): ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. From nobody Tue May 9 01:10:11 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4D41243F3; Tue, 9 May 2017 01:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.901 X-Spam-Level: X-Spam-Status: No, score=-4.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, 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 QXbvrSLjqvug; Tue, 9 May 2017 01:10:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 3D8BE127369; Tue, 9 May 2017 01:10:06 -0700 (PDT) Received: from [192.168.91.191] ([80.92.121.214]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LhNwC-1dlgcl14Ay-00mam9; Tue, 09 May 2017 10:09:55 +0200 To: Adam Roach , The IESG References: <149430548476.30014.11810513211435340238.idtracker@ietfa.amsl.com> Cc: core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <042ec343-be37-9e78-352a-8507c77c3205@gmx.net> Date: Tue, 9 May 2017 10:09:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149430548476.30014.11810513211435340238.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RqIEUurLPN6cTLcWCMCMTdV1pN4fJMvQp" X-Provags-ID: V03:K0:i120JTXQGi2qlPuZ8miAwotjfhaNEzc/RxdQoWJrdUXX1S4CNfn Wz9hh2Cg9R0+aGbPAs0OTBvNuDf/2tuOoOq7eVfAYqnuxe4V6d9UbHzfhjkGc0jKb7ieLYJ NnIwqf/MaqAEjwWX6hBrwa6tUhAf1+3P2DImEhG4FgRZSycbG55MPmI7kZ9BXutK1dIWlse 2x0AqeERaRT9agXlkiqnw== X-UI-Out-Filterresults: notjunk:1;V01:K0:TuL304TRFkM=:aY0kSwY5lPiGZnMc8xYDnN BNx/+/NoaZdXZFeVFYBAWaLnsXunmctr3zyi4lbwpCCsTh1ximcWuX0k1R3wJIDkp96ekrVhP 6B8M19FworlfyEAXy9QETEpIIJFxoKgiPiVZ7e8nAVoBNUTlyVQxXJ8ZFHb8QCwNIOiOkDeqe fD8MX79oahcNzEA7zl8JJZqonzj0yezxB5yWBDCvqqUzCW6OwsWweXn/ncY84qiYeGJdDlrmd /+503k8Z8D4lUNowXkPHtqxjvB/JW6KE/LVV/5uvRubulLMo9QRNF7eanE+rsOlEx62xq0tL7 VypJdF7WlwQ/7CTVzWK1KzFvzJRnHJiLEGS8UlXoXUYYcSKYingH9AyjAe4QXT+ULkgsAOXWb Y7i+SCEQepNf/p4vjlxIMB4fYz4LLjqRjdI2Hnx6yFZMgO703oI4k4FS/SBiYn9mt/feV/dZ+ j7SPpiNGwAZxVuj28frRydSIrTojresGn3PcBpjWaY8HTvrjpWoZFnlxVbAfgYVR+Lm16fCr7 EJJ04E0dw0puzplzBtUIV3ieQVPU4iJVHjcz539tFBvMEBqSaJDKZOBju5pOM2kee/0QiOIUB hCHptWWGKrIbLcBssi1dqhIVWD3YS+g6cAtdd66hzHL3gfgI26zmCXa5T90cew45I57OlgtnF RyOW3TfJBoViufPjbULq1LHbRtGj26lsVFxxpwh62NfznNyMlAidGAMqpkHaPM7sCjrLI+cQ8 o1jJOUAO90VhrR+fLSJhF1De/GOSX8UXAFvveE94/48sGkbOkB3Tyf+sJr8= Archived-At: Subject: Re: [core] Adam Roach's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 08:10:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RqIEUurLPN6cTLcWCMCMTdV1pN4fJMvQp Content-Type: multipart/mixed; boundary="6cQtA4Ee4nd83cUQKC68M6C1Wiu08SO1d"; protected-headers="v1" From: Hannes Tschofenig To: Adam Roach , The IESG Cc: core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org Message-ID: <042ec343-be37-9e78-352a-8507c77c3205@gmx.net> Subject: Re: [core] Adam Roach's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT) References: <149430548476.30014.11810513211435340238.idtracker@ietfa.amsl.com> In-Reply-To: <149430548476.30014.11810513211435340238.idtracker@ietfa.amsl.com> --6cQtA4Ee4nd83cUQKC68M6C1Wiu08SO1d Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Adam, thanks for your review. A few comments inline: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > - Part of the document is outside the scope of the charter of the WG > which requested its publication >=20 > While I understand that this document requires a WebSockets mechanism f= or > .well-known, and that such a mechanism doesn=E2=80=99t yet exist, it se= ems pretty > far out of scope for the CORE working group to take on defining this > itself (unless I missed something in its charter, which is entirely > possible: it=E2=80=99s quite long). Specifically, I fear that this venu= e is > unlikely to bring such a change to the attention of those people best > positioned to comment on whether .well-known is appropriate for > WebSockets. >=20 > Even if this is in scope for CORE, it really needs to be its own > document. If some future document comes along at a later point and want= s > to make use of its own .well-known path with WebSockets, it would be > really quite strange to require it to reference this document in > describing .well-known for WS. >=20 The authors of the document have different views about the inclusion of the support of WebSockets in the document. I leave it to the responsible AD to decide what the best document structure is and what is indeed covered as part of the CORE working group charter. >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- You have a couple of comments, namely * Variable length format The group decided to have a variable length format. I argued for a fixed size length format and lost the argument. * Gateways and their complexity We are using gateway functionality today in our deployments but they are not just simple protocol translations, as described in RFC 7252 or in RFC 8075. Instead they two protocols on each side of the gateway have different semantic and functionality. As such, the considerations in those two RFCs don't apply to us and we are not seeing any of that complexity. * Too many transport options We care only about CoAP over TLS. We are not going to use the WebSockets part of the document. In practice for many companies there will not be a problem with too many transports since they will only use specific ones in their deployment. * Block-wise transport with CoAP over TCP Maybe this needs to be better explained but CoAP is tailored to small data transmissions only. Unfortunately, there are some larger payloads to be shuffled around as well, particularly firmware updates. When RFC 7959 is used with TCP we found out that the performance is quite bad since the block-wise transfer spec limits the size of the chunks to a really small size (2048 bytes). The addition in this spec is to increase the size of the chunks. I will see whether the text can be improved to get his message across. More below on your specific comments: >=20 > General =E2=80=94 this is a very bespoke approach to what could have be= en mostly > solved with a single four-byte =E2=80=9Clength=E2=80=9D header; it is c= omplicated on the > wire, and in implementation; and the format variations among CoAP over > UDP, coap+tls, and coap+ws are going to make gateways much harder to > implement and less efficient (as they will necessarily have to > disassemble messages and rebuild them to change between formats). The > protocol itself mentions gateways in several places, but does not discu= ss > how they are expected to map among the various flavors of CoAP defined = in > this document. Some of the changes seem unnecessary, but it could be th= at > I=E2=80=99m missing the motivation for them. Ideally, the introduction = would work > harder at explaining why CoAP over these transports is as different fro= m > CoAP over UDP as it is, focusing in particular on why the complexity of= > having three syntactically incompatible headers is justified by the > benefits provided by such variations. >=20 > Additionally, it=E2=80=99s not clear from the introduction what the mot= ivation > for using the mechanisms in this document is as compared to the > techniques described in section 10 (and its subsections) of RFC 7252. > With the exception of subscribing to resource state (which could be > added), it seems that such an approach is significantly easier to > implement and more clearly defined than what is in this document; and i= t > appears to provide the combined benefits of all four transports discuss= ed > in this document. My concern here is that an explosion of transport > options makes it less likely that a client and server can find two in > common: the limit of the probability of two implementations having a > transport in common as the number of transports approaches infinity is > zero. Due to this likely decrease in interoperability, I=E2=80=99d expe= ct to see > some pretty powerful motivation in here for defining a third, fourth, > fifth, and sixth way to carry CoAP when only TCP is available (I count > RFC 7252 http and https as the first and second ways in this > accounting). >=20 > I=E2=80=99m also a bit puzzled that CoAP already has an inherent mechan= ism for > blocking messages off into chunks, which this document circumvents for > TCP connections (by allowing Max-Message-Size to be increased), and the= n > is forced to offer remedies for the resultant head-of-line blocking > issues. If you didn=E2=80=99t introduce this feature, messages with a t= wo-byte > token add six bytes of overhead for every 1024 bytes of content =E2=80=94= less > than 0.6% size inflation. It seems like a lot of complicated machinery = =E2=80=94 > which has a built-in foot-gun that you have to warn people about misusi= ng > =E2=80=94 for a very tiny gain. I know it=E2=80=99s relatively late in = the process, but > if these trade-offs haven't had a lot of discussion yet, it=E2=80=99s p= robably > worth at least giving them some additional thought. >=20 > I=E2=80=99ll note that the entire BERT mechanism seems to fall into the= same trap > of adding extra complexity for virtually nonexistent savings. CoAP > headers are, by design, tiny. It seems like a serious over-optimization= > to try to eliminate them in this fashion. In particular, you=E2=80=99re= making > the actual implementation code larger to save a trivial number of bits = on > the wire; I was under the impression that many of the implementation > environments CoAP is intended for had some serious on-chip restrictions= > that would point away from this kind of additional complexity. >=20 > Specific comments follow. >=20 > Section 3.3, paragraph 3 says that an initiator may send messages prior= > to receiving the remote side=E2=80=99s CSM, even though the message may= be larger > than would be allowed by that CSM. What should the recipient of an > oversized message do in this case? In fact, I don=E2=80=99t see in here= what a > recipient of a message larger than it allowed for in its CSM is suppose= d > to do in response at *any* stage of the connection. Is it an error? If > so, how do you indicate it? Or is the Max-Message-Size option just a > suggestion for the other side? This definitely needs clarification. > (Aside =E2=80=94 it seems odd and somewhat backwards that TCP connectio= ns are > provided an affordance for fine-grained control over message sizes, whi= le > UDP communications are not.) I personally would set a minimum requirement for the size of message the remote site needs to support. Thereby, the initiator can be sure that messages up to a certain size are supported. If it wants to send larger messages then it has to wait till the remote site provides their CSM. In our environment this would not be a problem with the TCP server is actually not on the IoT device but rather on the cloud-based (or on-premise-based) server instead. The TCP client is running on the IoT device. >=20 > Section 4.4 has a prohibition against using WebSockets keepalives in > favor of using CoAP ping/pong. Section 3.4 has no similar prohibition > against TCP keepalives, while the rationale would seem to be identical.= > Is this asymmetry intentional? (I=E2=80=99ll also note that the presenc= e of > keepalive mechanisms in both TCP and WebSockets would seem to make the > addition of new CoAP primitives for the same purpose unnecessary, but I= > suspect this has already been debated). The issue was that TCP keepalives are sometimes getting blocked or modified by firewalls whereas the CoAP ping/pong on top of TLS won't >=20 > Section 5 and its subsections define a new set of message types, > presumably for use only on connection-oriented protocols, although this= > is only implied, and never stated. For example, some implementors may s= ee > CSM, Ping, and Pong as potentially useful in UDP; and, finding no > prohibition in this document against using them, decide to give it a go= =2E > Is that intended? If not, I strongly suggest an explicit prohibition > against using these in UDP contexts. I believe a similar issue came up recently (provided by Jim) when he was asking whether this mechanism is also applicable to a transport over SMS.= If there is functionality in the document that is useful for other transports in the future then that's great. I wouldn't rule out such use just because we cannot imagine it today. >=20 > Section 5.3.2 says that implementations supporting block-wise transfers= > SHOULD indicate the Block-wise Transfer Option. I can't figure out why > this is anything other than a "MUST". It seems odd that this document > would define a way to communicate this, and then choose to leave the > communicated options as =E2=80=9CYES=E2=80=9D and =E2=80=9CYOUR GUESS I= S AS GOOD AS MINE=E2=80=9D rather > than the simpler and more useful =E2=80=9CYES=E2=80=9D and =E2=80=9CNO=E2= =80=9D. Sounds reasonable to me. >=20 > I find the described operation of the Custody Option in the operation o= f > Ping and Pong to be somewhat problematic: it allows the Pong sender to > unilaterally decide to set the Custody Option, and consequently > quarantine the Pong for an arbitrary amount of time while it processes > other operations. This seems impossible to distinguish from a > failure-due-to-timeout from the perspective of the Ping sender. Why not= > limit this behavior only to Ping messages that include the Custody > Option? I push this to Carsten, who I believe wrote this text. >=20 > I find the unmotivated definition of the default port for =E2=80=9Ccoap= s+tcp=E2=80=9D to > 443 =E2=80=94 a port that is already assigned to https =E2=80=94 to be = surprising, to put > it mildly. This definitely needs motivating text, and I suspect it's > actually wrong. If we don't do this then we do not get through firewalls. >=20 > I am similarly perplexed by the hard-coded =E2=80=9Cmust do ALPN *unles= s* the > designated port takes the magical value 5684=E2=80=9D behavior. I don=E2= =80=99t think > I=E2=80=99ve ever seen a protocol that has such variation based on a ha= rd-coded > port number, and it seems unlikely to be deployed correctly (I=E2=80=99= m imaging > the frustration of: =E2=80=9CI changed both the server and the client > configuration from the default port of 5684 to 49152, and it just stopp= ed > working. Like, literally the *only* way it works is on port 5684. I've > checked firewall settings everywhere and don't see any special handling= > for that port -- I just can't figure this out, and it's driving me > crazy.=E2=80=9D). Given the nearly universal availability of ALPN in pr= etty much > all modern TLS libraries, it seems much cleaner to just require ALPN > support and call it done. Or *don=E2=80=99t* require ALPN at all and ca= ll it > done. But *changing* protocol behavior based on magic port numbers seem= s > like it=E2=80=99s going to cause a lot of operational heartburn. It is fine for me to require ALPN always. >=20 > The final paragraph of section 8.1 is very confusing, making it somewha= t > unclear which of the three modes must be implemented on a CoAP client, > and which must be implemented on a CoAP server. Read na=C3=AFvely, this= sounds > like clients are required to do only one (but one of their choosing) of= > these three, while servers are required to also do only one (again, of > their choosing). It seems that the chance of finding devices that could= > interoperate under such circumstances is going to be relatively low: to= > work together, you would have to find a client and a server that happen= ed > to make the same implementation choice among these three. What I=E2=80=99= m used > to in these kinds of cases is: (a) server must implement all, client ca= n > choose to implement only one (or more), (b) client must implement all, > server can choose to implement only one (or more), or (c) client and > server must implement a specifically named lowest-common denominator, a= nd > can negotiate up from there. Pretty much anything else (aside from > strange =E2=80=9Ceveryone must implement two of three=E2=80=9D schemes)= will end up with > interop issues. This follows of what is being said in CoAP. Even the HTTP-spec does not go into such a level of detail. In terms of interoperability clearly IoT devices that implement pre-shared secrets are not going to talk to devices that only implement certificates. This is, however, not a real interoperability issue since the use of CoAP will most likely be part of a device management framework like LwM2M or stuff the OIC is working on. Companies deploying IoT devices then need to figure out what they want to accomplish and what security threats they care about. >=20 > Although the document clearly expects the use of gateways and proxies > between these connection-oriented usages of CoAP and UDP-based CoAP, > Appendix A seems to omit discussion or consideration of how this > gatewaying can be performed. The following list of problems is > illustrative of this larger issue, but likely not exhaustive. (I'll not= e > that all of these issues evaporate if you move to a simpler scheme that= > merely frames otherwise unmodified UDP CoAP messages) As mentioned before, I personally don't see any issue with this at all since we not shuffling CoAP over UDP on one side to CoAP over TCP on the other side. In fact, I don't know anyone doing that. ~snip~ Ciao Hannes --6cQtA4Ee4nd83cUQKC68M6C1Wiu08SO1d-- --RqIEUurLPN6cTLcWCMCMTdV1pN4fJMvQp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJZEXlQAAoJEGhJURNOOiAtOHAH/jTXO6gwUymnfCFcHJe0W1KC UWa3/ldACkV+UymW6/qxFFBU/d5EzUHc91oqBZRdUcIxMA1ttbF3YPr29T39ogYe jnUnEQHoRtEfMhNIOkyU+VDaGhjKWOQkJow4BntaNUfaIGD2mPiREtSHeAWIkWeT 4WcGuqjoWHZuAz6U0M5NtuRYLTLg0rDNAwBeSZZh7rkO1qVfnrric985fekScXuP C/wdAuCQmHjP1khgMhQrLotykKKBMb9it6lD8dRU8sWabBdXQE8naCTc4+Frfjiy wkfqxrUKLRxknnD8QiowDGmAq20fU+z5uhdXx7vuQZw2W7r8mCUbBH/Q1W6CB8s= =Oz+C -----END PGP SIGNATURE----- --RqIEUurLPN6cTLcWCMCMTdV1pN4fJMvQp-- From nobody Tue May 9 03:21:53 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD75129BC6; Tue, 9 May 2017 03:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=Sv4Wbmsz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dpkHvhhe 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 2MVkXvZHZSzd; Tue, 9 May 2017 03:21:48 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F614129BC4; Tue, 9 May 2017 03:21:48 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C9EF020C3C; Tue, 9 May 2017 06:21:47 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Tue, 09 May 2017 06:21:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=2SNdkcm/gGyCsIMAH2ypVj4gKmUBB ilRlG1cgQrkggM=; b=Sv4WbmszvAaOI7x9+HJNPKsKTVCyHKKe8gn1IpsaNkfCz e/LMNmQtFFS1XNCwwol0WlAW/+l6LsphnK5BBdGdJcmefEQ24VDuROs36qBUSyMd kawUGL7oriIVC2Frg8fySAB637EDz1mmYobSG+A1aA7KdHg6b4zsWVp8G1ML7V/h AltL5JP5vnPR0D4DN86Ab1f/k91rUdce+Y7MkuPoD/Vf7MvdkhZ1hxlJhsi14j9D Sy3m5PlCc6nc7fEwluiniMkYIncfoH9YyjATO27td9WY1bD/DKJYP/ewKNHtpoRY aX9BUk8IMjHOr8TQKSZKMy3icWcZ71MTlIkCAp7Tw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=2SNdkc m/gGyCsIMAH2ypVj4gKmUBBilRlG1cgQrkggM=; b=dpkHvhheW68EuTNqYeVSAJ 8yyiLd0a8oZr6pjssWkuxf6NVa15hB/OH6iNJWYFa4Et/H8/fx8Uvp5E0MG00KiO PPpLVNpA8agqxCpCYMpsFF6uj1qgG6IsgZMNmo3F5eyEbJ9pCTRZy5T6UzHAI2Nr yZDP41U6BeZZyps9kVjXC482YBByxQB4zAZSGCARKy/yWWGdHjBxJ4JcRN4vqPWx nI7ZskoPXFkOlrs0hpdLZIPXlWvKemo2t21+uvrzbVyD47SpjbuTl4BtBv13gMIc I9lChoVzXdbbmX63tk9Gkp4sv7HsXEtbBGbhz9ZYFq6POGSAm9YJh4jb1A2w9M7A == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 994779E290; Tue, 9 May 2017 06:21:47 -0400 (EDT) Message-Id: <1494325307.10771.970566837.6723DA3D@webmail.messagingengine.com> From: Alexey Melnikov To: Adam Roach , The IESG Cc: jaime.jimenez@ericsson.com, core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-6cc55fe1 References: <149430548476.30014.11810513211435340238.idtracker@ietfa.amsl.com> In-Reply-To: <149430548476.30014.11810513211435340238.idtracker@ietfa.amsl.com> Date: Tue, 09 May 2017 11:21:47 +0100 Archived-At: Subject: Re: [core] Adam Roach's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 10:21:51 -0000 Hi Adam, On Tue, May 9, 2017, at 05:51 AM, Adam Roach wrote: > Adam Roach has entered the following ballot position for > draft-ietf-core-coap-tcp-tls-08: Discuss [snip] > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > - Part of the document is outside the scope of the charter of the WG > which requested its publication >=20 > While I understand that this document requires a WebSockets mechanism for > .well-known, and that such a mechanism doesn=E2=80=99t yet exist, it seem= s pretty > far out of scope for the CORE working group to take on defining this > itself (unless I missed something in its charter, which is entirely > possible: it=E2=80=99s quite long). Specifically, I fear that this venue = is > unlikely to bring such a change to the attention of those people best > positioned to comment on whether .well-known is appropriate for > WebSockets. Mark Nottingham's review pointed out that .well-known is not registered for ws:/wss:, so the obvious fix was to define it.=20 The WG working on WebSockets is closed. Carsten emailed the HYBI mailings list (WebSocket WG mailing list) about this change: https://www.ietf.org/mail-archive/web/hybi/current/msg10768.html There was no objection. I was one of the two editors of the WebSocket RFC, so I thought just defining .well-known for WebSockets was a sensible thing to do. > Even if this is in scope for CORE, it really needs to be its own > document. If some future document comes along at a later point and wants > to make use of its own .well-known path with WebSockets, it would be > really quite strange to require it to reference this document in > describing .well-known for WS. I didn't push for a separate document just for that (it will be 1 page), but if IESG really likes a separate document we will do that. From nobody Tue May 9 09:35:54 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E54126BF6 for ; Tue, 9 May 2017 09:35:52 -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 FqKaacrSjLt1 for ; Tue, 9 May 2017 09:35:50 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 00C60129B95 for ; Tue, 9 May 2017 09:35:49 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id 64so2335590pgb.3 for ; Tue, 09 May 2017 09:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=AhB6p3QtDHjFHXjs3XTssadxG6WBfXaptZJ0ey6xIfE=; b=WD8eo8GDuogcV5leQUlosgeOgpPBVyBu43gJwnhv+Voyxz5hE6F4SITlYWV09eSkrK Kv9X085gEvsYNKzpwxVQ0neOjBJX6U7yNizpQZFVEoxIcdJA2lPs/7nksHUUPgTCAdQR uMDgjUZvQh3D7BThV9YI34/lmbkeIRvPou9A3egAkV85iz37NbxFee1oSnDuqn+lFjly qXVEj25sw5HwkRxymDHLORnWDLSu3k+rBTRbO9DoPAcUysXvHl6IFgTEQH2zT+aYA/Co tOPZffdNCSAobDb+t2QPsJ3w1a0LoOdQ12TiG2eJ5WcXbHh99+RnUhxAbVU44bTmMUGN uFBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=AhB6p3QtDHjFHXjs3XTssadxG6WBfXaptZJ0ey6xIfE=; b=fLC4wOAD9C2TEirXTk0Acb/2PxzMNKd9OLnFGVfs1uCBchioFP4U3kZEXFhrTnwuqW E2GaNr8M7WpkR+PnABUEFWsepxi6AzXcz5yOCng5wFIJStrnIvV/SxhQgBHrE6ou3rcN K6az3dLvUzs+CVZbgTufkSSSdTsVBeFojIAElo/gdqMiJl/8nibCgfCPdW1BU/gu85Sj nYUSNSYK5jJiXB+8Bz4SzpaJVNN0q2fZlPVAJxC+/F5NBGQgZM3AYnLn5VtGZFYdRP3a Flx5RDq1kt/TefQzTyiOc9G8KL4/xpVay0VfsywOtZWYlqOhZbs4vqCO7R7ZHyxzu2rB wnGg== X-Gm-Message-State: AODbwcAgFcE7X2yHxqhIifWhclusWYTtzScsEdLwis7FVR5iPIeGAmOm F9z/3I2T4MkrQQ== X-Received: by 10.84.135.34 with SMTP id 31mr1352174pli.99.1494347749551; Tue, 09 May 2017 09:35:49 -0700 (PDT) Received: from [10.0.0.14] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id y190sm760115pgd.25.2017.05.09.09.35.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 09 May 2017 09:35:48 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_EF64DD4D-37DF-4FCF-9964-421B21F0FAF1" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Koster In-Reply-To: <0c5863c6f5d341c7af35e3147815e961@AM3PR90MB0097.MGDPHG.emi.philips.com> Date: Tue, 9 May 2017 09:35:46 -0700 Cc: "consultancy@vanderstok.org" , Lauri Piikivi , Core Message-Id: References: <2688B534-A979-42F6-AC33-925817005F80@tzi.org> <75dc1a630fca3fd2e50fe13f867cb85b@xs4all.nl> <0bd0cd5aac2e444cbb625afc688f1c5f@AM3PR90MB0097.MGDPHG.emi.philips.com> <47fc672effd46a2f414c8eca1440d6cc@xs4all.nl> <0c5863c6f5d341c7af35e3147815e961@AM3PR90MB0097.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [core] Resource Directory: Simplifying Domains X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 16:35:52 -0000 --Apple-Mail=_EF64DD4D-37DF-4FCF-9964-421B21F0FAF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Esko, I didn't realize the example was creating domains upon first = registration.=20 I guess we should review the text in the draft: Sec. 2 has this: Domain In the context of a Resource Directory, a domain is a logical grouping of endpoints. This specification assumes that the list of Domains supported by an RD is pre-configured by that RD. When a domain is exported to DNS, the domain value equates to the DNS domain name. Sec. 3: An RD can be logically segmented by the use of Domains. =20 The domain an endpoint is associated with can be defined=20 by the RD or configured by an outside entity. This information=20 hierarchy is shown in Figure 2. If we want to allow creation on registrtion, we will need to rework this = text and probably add some explicit description to section 5. Best regards, Michael > On May 8, 2017, at 12:50 AM, Dijk, Esko wrote: >=20 > Michael, >=20 > currently the ad-hoc creation of domains follows from the text e.g. = the examples on page 40 . There each room in a building gets its own = Domain in the RD. Now the RD can't possibly know these room IDs = beforehand, so these are created on-the-fly. > A Commissioning Tool (CT) as in that example would typically know = which Domain a device is to be assigned to, however the endpoint itself = (if doing the registration itself) would typically not know this - so it = would use the default domain. >=20 > @Peter, >=20 > agree that in the way currently Domains are defined and used , some = infrastructure entity (the RD itself?) is responsible for mapping it do = a DNS domain. E.g. if the CT register a node under domain d=3DR2-4-015 = then this entity would know that it maps to DNS = 'R2-4-015.building.example.com ' = for example. But the 'RD to DNS mapping agent' is not mentioned in = the I-D so may be good to clarify this more. (Also where this entity = resides.) >=20 > Esko >=20 > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl = ] > Sent: Monday, May 08, 2017 9:43 > To: Lauri Piikivi > > Cc: Dijk, Esko >; = Carsten Bormann >; = consultancy@vanderstok.org ; Core = > > Subject: Re: [core] Resource Directory: Simplifying Domains >=20 > Hi Lauri, >=20 > a partial response, >=20 >> We may have some misaligned definition for domain. V10 of the draft >> says in definitions: >> This specification assumes that the list >> of Domains supported by an RD is pre-configured by that RD. = When >> a domain is exported to DNS, the domain value equates to the DNS >> domain name. > Thanks for pointing this out. > There clearly is confusion about the use of domain in the RD, and its = eventual use as the DNS domain. > I agree that this confusion must be removed. In my mind there are two = domain concepts: > the RD one and the DNS one. >=20 > IMO, It is the responsibility of the RD to DNS mapping agent to = specify restrictions if the RD domain is mapped to the DNS domain. >=20 > Peter >=20 > ________________________________ > The information contained in this message may be confidential and = legally protected under applicable law. The message is intended solely = for the addressee(s). If you are not the intended recipient, you are = hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message. >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core = --Apple-Mail=_EF64DD4D-37DF-4FCF-9964-421B21F0FAF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Esko,

I = didn't realize the example was creating domains upon first = registration. 

I = guess we should review the text in the draft:

Sec. 2 has this:
  =  Domain
      In the context of = a Resource Directory, a domain is a logical
  =     grouping of endpoints.  This specification assumes = that the list
      of Domains = supported by an RD is pre-configured by that RD.  When
      a domain is exported to DNS, the domain = value equates to the DNS
      = domain name.

Sec. 3:

An RD can be logically segmented by the use = of Domains.  
The domain an endpoint is = associated with can be defined 
by the RD or = configured by an outside entity.  This information 
hierarchy is shown in Figure 2.

If we want to allow creation on = registrtion, we will need to rework this text and probably add some = explicit description to section 5.

Best regards,

Michael


On May 8, 2017, at 12:50 AM, = Dijk, Esko <esko.dijk@philips.com> wrote:

Michael,

currently the ad-hoc creation of domains follows = from the text e.g. the examples on page 40 . There each room in a = building gets its own Domain in the RD. Now the RD can't possibly know = these room IDs beforehand, so these are created on-the-fly.
A Commissioning Tool (CT) as in that example = would typically know which Domain a device is to be assigned to, however = the endpoint itself (if doing the registration itself) would typically = not know this - so it would use the default domain.

@Peter,

agree that in the way currently Domains are = defined and used , some infrastructure entity (the RD itself?) is = responsible for mapping it do a DNS domain. E.g. if the CT register a = node under domain d=3DR2-4-015 then this entity would know that it maps = to DNS 'R2-4-015.building.example.com'   for example.   But the = 'RD to DNS mapping agent' is not mentioned in the I-D so may be good to = clarify this more. (Also where this entity resides.)

Esko

-----Original = Message-----
From: peter van der Stok = [mailto:stokcons@xs4all.nl]
Sent: Monday, May 08, 2017 = 9:43
To: Lauri Piikivi = <Lauri.Piikivi@arm.com>
Cc: Dijk, Esko = <esko.dijk@philips.com>; Carsten Bormann <cabo@tzi.org>; consultancy@vanderstok.org; Core <core@ietf.org>
Subject: Re: [core] = Resource Directory: Simplifying Domains

Hi Lauri,

a partial response,

We may have some = misaligned definition for domain. V10 of the draft
says in = definitions:
     This = specification assumes that the list
     of Domains supported by an RD = is pre-configured by that RD.  When
     a domain is exported to DNS, = the domain value equates to the DNS
     domain name.
Thanks for pointing = this out.
There clearly is confusion = about the use of domain in the RD, and its eventual use as the DNS = domain.
I agree that this = confusion must be removed.  In my mind there are two domain = concepts:
the RD one and the DNS = one.

IMO, It is the = responsibility of the RD to DNS mapping agent to specify restrictions if = the RD domain is mapped to the DNS domain.

Peter

________________________________
The information contained in this message may be = confidential and legally protected under applicable law. The message is = intended solely for the addressee(s). If you are not the intended = recipient, you are hereby notified that any use, forwarding, = dissemination, or reproduction of this message is strictly prohibited = and may be unlawful. If you are not the intended recipient, please = contact the sender by return e-mail and destroy all copies of the = original message.

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

= --Apple-Mail=_EF64DD4D-37DF-4FCF-9964-421B21F0FAF1-- From nobody Tue May 9 14:30:49 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2066F129A9C; Tue, 9 May 2017 14:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 6x7EUvCv7wvd; Tue, 9 May 2017 14:30:45 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 58C12127977; Tue, 9 May 2017 14:30:45 -0700 (PDT) Received: from [192.168.1.14] (unknown [124.189.96.43]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 435BF22E2B7; Tue, 9 May 2017 17:30:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> Date: Wed, 10 May 2017 07:30:35 +1000 Cc: art@ietf.org, draft-ietf-core-coap-tcp-tls.all@ietf.org, ietf@ietf.org, core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <767F913A-586B-42A2-B021-F9AC5C478702@mnot.net> References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 21:30:48 -0000 > On 10 Apr 2017, at 7:46 pm, Carsten Bormann wrote: >=20 >> Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://" >> URI, using a well-known URI in the "wss" scheme. However, "wss" is = not >> defined to use well-known URIs, so this is an invalid use.=20 >=20 > This incorrect use of RFC 5785 is indeed embarrassing. More about = that later. To close this loop -- the change in -08 isn't sufficiently prominent = IME; while the general nature of the change is listed in the Abstract, = the actual normative text is very hard to find. Given that this is a = pretty fundamental change in the operation of a URI scheme, I'd think it = at least deserves its own section, if not a separate document. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Tue May 9 19:25:57 2017 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D3112EBC2; Tue, 9 May 2017 19:25:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-core-coap-tcp-tls@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149438315533.29515.17605324258067615896.idtracker@ietfa.amsl.com> Date: Tue, 09 May 2017 19:25:55 -0700 Archived-At: Subject: [core] Ben Campbell's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 02:25:55 -0000 Ben Campbell has entered the following ballot position for draft-ietf-core-coap-tcp-tls-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1) This draft removes the reliability and ordering features COAP when used over reliable transports, under the assumption that the transport will provide. But the draft also includes the assumption that COAP proxies exist. This has the potential for creating a problem, since the transport can only provide guaranty reliable delivery and ordering to the next hop. Once you have a proxy in play, you loose that guaranty end to end. This is further complicated because this draft contemplates cross-transport proxies, where one side may be over WebSocket (and I assume might be over TCP) and the other side over UDP. If the client sends via TCP but a proxy changes it to UDP, the client has no way to specify the reliability properties to be used on the UDP connection. If one imagines a client that uses UDP to a forward proxy, which speaks TCP to a reverse-proxy, which then switches back to UDP, any reliability properties specified by the client will get lost. Also, a proxy can potentially reorder messages, even if it uses TCP on both sides. If one leaves ordering to the transport, then one needs to add rules about proxies maintaining that order. 2) It seems problematic to encode the transport choice in the URI scheme. Since the draft specifies that each scheme. Section 7 says "They are hosted in distinct namespaces because each URI scheme implies a distinct origin server." IIUC, this means any given resource can only be reached over a specific transport. That seems to break the idea of cross-transport proxies as discussed in section 7. It also does not seem to fit with a primary motivation for this draft. That is, one might want to use TCP because of local NAT/FW issues. But if there is a resource with a "coap" scheme, I cannot switch to TCP when I'm behind a problematic middlebox, and have an expectation of reaching the same resource. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Subtantive: 3.2: I agree with Adam that this length scheme seems very complex for the return 3.3: Since the initiator can start sending messages before receiving a CSM from the responder, how long should the initiator wait for a CSM before bailing? 3.4: Can you offer any guidance about how often to send keep-alives? I note that these keepalives are not necessarily bi-directional. Aren't there some NAT/FW cases where bi-directional traffic is needed to keep bindings from timing out? This and other places explicitly mention that in-flight messages may be lost when the transport is closed or reset. This creates uncertainty about whether such messages have been processed or not. Is that really okay? 4: After the discussion resulting from Mark's Art-Art review, I expected to see more emphasis about WebSocket being intended for browser-based clients. There's a couple of in-passing mentions of browser-clients buried in the text; I would have expected something more up front. 4.2: Is it really worth making the framing code behave differently for WebSocket than for TCP? 5.3: Do I understand correctly that once an option is established, it cannot be removed unless replaced? (Short of tearing down the connection and starting over, anyway.) 7.2: The text mentions 443 as a default port, but really seems to make 5684 the default. If 443 is really a default, then this needs discussion about why and why it's okay to squat on HTTPS. The text about whether ALPN is required is confusing. Why not just require ALPN and move one, rather than special casing it by port choice? (There seems to be some circular logic about requiring 5685 to support clients that don't do ALPN, then saying clients MUST do ALPN unless they are using port 5685.) 7.3: I agree with Adam's DISCUSS comment. And even if people decide that the well-known bit can be specified in CORE, I think it does future users of a well-known URIs for ws a disservice to make them dig through this spec to find the update to 6455. It would be better to pull that into a separate draft. That's also a material addition post IETF last call, so we should consider repeating the LC. 10.2: Is the registration policy "analogous to" that of [RFC7252] S12.2, or "identical to" it. If the answer is not "identical", then the policy should be detailed here. Editorial: Figures 7 and 8: "Payload (if any)" - Can we assume that if one uses either extended length format, one has a payload? 3.3: Is the guidance about what errors to return if you don't implement a server any different here than for UDP? 4.3 and 4.4 seem to primarily repeat details that are the same for WS as for TCP, even though the introduction to the WS part says that it won't do that :-) 5.3: "One CSM MUST be sent by both endpoints...": s/both/each 7.6: The "updates" in this section are confusing. I understand this to mean that the procedures for TCP and WS are identical to those for UDP except for the mentioned steps. But the language of the form of "This step from [RFC7252] is updated to:" makes it sound like this intends to actually change the language in 7252 to this new language. If the latter, then that effectively removes UDP support from 7252 as updated. This could easily be fixed by changing that to something to the effect of "When using TCP, this step changes to ..." Appendix A: Why is this an appendix? Updates to a standards track RFC seem to warrant a more prominent position in the draft. From nobody Tue May 9 19:27:03 2017 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C39A12EBB6; Tue, 9 May 2017 19:27:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-core-coap-tcp-tls@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149438322150.24264.16123907495920056718.idtracker@ietfa.amsl.com> Date: Tue, 09 May 2017 19:27:01 -0700 Archived-At: Subject: [core] Ben Campbell's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 02:27:01 -0000 Ben Campbell has entered the following ballot position for draft-ietf-core-coap-tcp-tls-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1) This draft removes the reliability and ordering features COAP when used over reliable transports, under the assumption that the transport will provide. But the draft also includes the assumption that COAP proxies exist. This has the potential for creating a problem, since the transport can only provide guaranty reliable delivery and ordering to the next hop. Once you have a proxy in play, you loose that guaranty end to end. This is further complicated because this draft contemplates cross-transport proxies, where one side may be over WebSocket (and I assume might be over TCP) and the other side over UDP. If the client sends via TCP but a proxy changes it to UDP, the client has no way to specify the reliability properties to be used on the UDP connection. If one imagines a client that uses UDP to a forward proxy, which speaks TCP to a reverse-proxy, which then switches back to UDP, any reliability properties specified by the client will get lost. Also, a proxy can potentially reorder messages, even if it uses TCP on both sides. If one leaves ordering to the transport, then one needs to add rules about proxies maintaining that order. 2) It seems problematic to encode the transport choice in the URI scheme. Section 7 says "They are hosted in distinct namespaces because each URI scheme implies a distinct origin server." IIUC, this means any given resource can only be reached over a specific transport. That seems to break the idea of cross-transport proxies as discussed in section 7. It also does not seem to fit with a primary motivation for this draft. That is, one might want to use TCP because of local NAT/FW issues. But if there is a resource with a "coap" scheme, I cannot switch to TCP when I'm behind a problematic middlebox, and have an expectation of reaching the same resource. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Subtantive: 3.2: I agree with Adam that this length scheme seems very complex for the return 3.3: Since the initiator can start sending messages before receiving a CSM from the responder, how long should the initiator wait for a CSM before bailing? 3.4: Can you offer any guidance about how often to send keep-alives? I note that these keepalives are not necessarily bi-directional. Aren't there some NAT/FW cases where bi-directional traffic is needed to keep bindings from timing out? This and other places explicitly mention that in-flight messages may be lost when the transport is closed or reset. This creates uncertainty about whether such messages have been processed or not. Is that really okay? 4: After the discussion resulting from Mark's Art-Art review, I expected to see more emphasis about WebSocket being intended for browser-based clients. There's a couple of in-passing mentions of browser-clients buried in the text; I would have expected something more up front. 4.2: Is it really worth making the framing code behave differently for WebSocket than for TCP? 5.3: Do I understand correctly that once an option is established, it cannot be removed unless replaced? (Short of tearing down the connection and starting over, anyway.) 7.2: The text mentions 443 as a default port, but really seems to make 5684 the default. If 443 is really a default, then this needs discussion about why and why it's okay to squat on HTTPS. The text about whether ALPN is required is confusing. Why not just require ALPN and move one, rather than special casing it by port choice? (There seems to be some circular logic about requiring 5685 to support clients that don't do ALPN, then saying clients MUST do ALPN unless they are using port 5685.) 7.3: I agree with Adam's DISCUSS comment. And even if people decide that the well-known bit can be specified in CORE, I think it does future users of a well-known URIs for ws a disservice to make them dig through this spec to find the update to 6455. It would be better to pull that into a separate draft. That's also a material addition post IETF last call, so we should consider repeating the LC. 10.2: Is the registration policy "analogous to" that of [RFC7252] S12.2, or "identical to" it. If the answer is not "identical", then the policy should be detailed here. Editorial: Figures 7 and 8: "Payload (if any)" - Can we assume that if one uses either extended length format, one has a payload? 3.3: Is the guidance about what errors to return if you don't implement a server any different here than for UDP? 4.3 and 4.4 seem to primarily repeat details that are the same for WS as for TCP, even though the introduction to the WS part says that it won't do that :-) 5.3: "One CSM MUST be sent by both endpoints...": s/both/each 7.6: The "updates" in this section are confusing. I understand this to mean that the procedures for TCP and WS are identical to those for UDP except for the mentioned steps. But the language of the form of "This step from [RFC7252] is updated to:" makes it sound like this intends to actually change the language in 7252 to this new language. If the latter, then that effectively removes UDP support from 7252 as updated. This could easily be fixed by changing that to something to the effect of "When using TCP, this step changes to ..." Appendix A: Why is this an appendix? Updates to a standards track RFC seem to warrant a more prominent position in the draft. From nobody Tue May 9 21:31:16 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332DD12EAB2; Tue, 9 May 2017 21:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, 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 mE7caBuZxXjE; Tue, 9 May 2017 21:31:12 -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 9204A1205F1; Tue, 9 May 2017 21:31:12 -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 v4A4V8ZY025040; Wed, 10 May 2017 06:31:09 +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 3wN3G45Wt8zDHmm; Wed, 10 May 2017 06:31:08 +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: <767F913A-586B-42A2-B021-F9AC5C478702@mnot.net> Date: Wed, 10 May 2017 06:31:07 +0200 Cc: art@ietf.org, draft-ietf-core-coap-tcp-tls.all@ietf.org, ietf@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 516083467.066919-e7cf67f9e5bffe784973075c0e683012 Content-Transfer-Encoding: quoted-printable Message-Id: <2D57FF92-3A56-43BC-A815-27801E31F770@tzi.org> References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <767F913A-586B-42A2-B021-F9AC5C478702@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] [art] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 04:31:15 -0000 > On May 9, 2017, at 23:30, Mark Nottingham wrote: >=20 > To close this loop -- the change in -08 isn't sufficiently prominent = IME; while the general nature of the change is listed in the Abstract, = the actual normative text is very hard to find. Certainly, let=E2=80=99s see what the IESG decides here. > Given that this is a pretty fundamental change in the operation of a = URI scheme, I'd think it at least deserves its own section, if not a = separate document. I don=E2=80=99t agree that this is such a fundamental change here =E2=80=94= the /.well-known name space in the URI already was special (by the fact = that ws URIs are mapped to http URIs, which do have /.well-known = reserved already). But that doesn=E2=80=99t matter, we should find the best editorial way = to document making the well-known URI concept available to WebSocket = URIs. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue May 9 23:13:11 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36359129503; Tue, 9 May 2017 23:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 p9ZktsVqK3FJ; Tue, 9 May 2017 23:13:05 -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 5CA551205F0; Tue, 9 May 2017 23:13:05 -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 v4A6CxG6016849; Wed, 10 May 2017 08:12:59 +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 3wN5Wb2twWzDHnq; Wed, 10 May 2017 08:12:59 +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: <149411155754.23175.15150224037348429928.idtracker@ietfa.amsl.com> Date: Wed, 10 May 2017 08:12:58 +0200 Cc: The IESG , draft-ietf-core-coap-tcp-tls@ietf.org, Jaime Jimenez , core-chairs@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 516089578.749245-685c28aee45549bd4194784753e4fc96 Content-Transfer-Encoding: quoted-printable Message-Id: References: <149411155754.23175.15150224037348429928.idtracker@ietfa.amsl.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Eric Rescorla's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 06:13:09 -0000 >=20 > Hi Eric, thank you for this detailed review. ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > After reading Mark Nottingham's review, I'm persuaded we should at = least > discuss the relationship of this work to the parallel work in HTTP. I don=E2=80=99t think the work on HTTP/2 is in any way parallel to the = work of bringing CoAP to work on TCP/TLS. There are some elements of Mark=E2=80=99s review that leave me = speechless (=E2=80=9Creinventing framing=E2=80=9D? Any TCP-based = protocol needs to reinvent framing, and it=E2=80=99s not like the HTTPs = have found the definitive answer this perennial issue yet.). I generally = think the competition that is hinted at here is constructed; in reality = it does not exist. I do believe that a discussion about the relationship of the three REST = transfer protocols, CoAP and the two HTTPs, is useful, if well-prepared. But let me dive in to some specifics below. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Document: draft-ietf-core-coap-tcp-tls-08.txt >=20 > TECHNICAL > You need to specify MTI cipher suites. I don't think that the > ones you specified in 7925 are very useful for TLS. Is this really > really what you want? Indeed, you are uncovering an issue here: The recommendations in the document (in 7925 Section 4.2, 4.3) are good = for CoAP over TCP/TLS in the constrained-to-cloud use case. For backend interfacing, and in particular for the WebSockets case, one = would use what one has in those environments. Now https://github.com/core-wg/coap-tcp-tls/issues/145 Generally speaking, it is not so clear that MTI cipher suites are as = useful in this document as they are in the base CoAP spec, as this = document describes a set of optional transport bindings that is needed = in a number of quite different specific use cases, each of which come = with their own specific environments. > S 3.2. > Having the lengths offset by 13 bytes is, IMO, pretty silly. I > realize it avoids duplication, but it also makes the packets hard to > read for not much value. As a practical matter, it expands the > 1-byte length for the range 256-268, for a savings of less than > .5% even on those packets and on average far less. This just mirrors the way CoAP is encoding lengths (and other values) in = other places. The 0.5 % savings is nice to have (but would indeed be a silly = motivation on its own). The motivation for the length encoding used in CoAP (which we iterated = on quite a bit between 2012 and 2013) ultimately was to get = deterministic coding: For each length, there is exactly one way to = encode it, so it is harder to trip up implementations by (accidentally = or deliberately) using an alternate encoding. (The WG originally had decided to use a simpler fixed-length length for = TCP, called L1. Unfortunately, implementations at this point already = had charged ahead and used the CoAP-style length encoding, called L3. = So the WG grudgingly switched to L3.) > S 4.1. > The WebSocket client MUST include the subprotocol name "coap" in the > list of protocols, which indicates support for the protocol defined > in this document. Any later, incompatible versions of CoAP or CoAP > over WebSockets will use a different subprotocol name. >=20 > This doesn't make much sense, because you are willing to have > incompatible > protocols for TCP, where you use CSM to distinguish them, and you do > the same thing with ALPN. The sentence was about =E2=80=9Cincompatible=E2=80=9D in the sense that = you wouldn=E2=80=99t even understand the CSM. No idea why we would make changes like that, but unexpected protocol = evolution does happen, and it is good that ALPN has us covered here. > S 5.5. > These release semantics seem quite problematic. In particular, when > people want an orderly close, they typically want the other side > to process all the outstanding requests and then return them, but > this doesn't seem to do that (note that just because the responses > need to be *delivered* in order doesn't mean they need to be generated > in order). So, for instance, say I have the following sequence of > events: >=20 > C S DB > GET /a -> =20 > Request A -> =20 > Release -> > FIN > <- Response A >=20 > It seems like the only difference between Abort and Release is that > the sender is saying "don't expect that I processed any of your > messages", but in at least a lot of scenarios (e.g., where the > initiator is basically just a client), this doesn't actually tell > the server much about sequence because the responses aren't ordered > wrt Release AFAICT. >=20 > Release message by closing the TCP/TLS connection. Messages may be > in flight when the sender decides to send a Release message. The > general expectation is that these will still be processed. >=20 > This is not really useful language. I see what you mean. The intention is that a Release actually does = allow the other side to process outstanding requests, so in the above = example the server would actually send =E2=80=9CResponse A=E2=80=9D = before closing. Now https://github.com/core-wg/coap-tcp-tls/issues/146 > For CoAP over reliable transports, the recipient rejects such > messages by sending an Abort message and otherwise ignoring the > message. No specific option has been defined for the Abort message > in this case, as the details are best left to a diagnostic payload. >=20 > I don't understand this text. Abort seems to mean "I'm done", but then > how am I ignoring the message. Ignoring as in =E2=80=9Cnot processing=E2=80=9D. (This is echoing the equivalent text from RFC 7252, do we need to use = different wording?) > S 6. > I found this section pretty confusing. In 7959, when M=3D0 you need > to stay *under* the block boundary but here you say: >=20 > In descriptive usage, a BERT Option is interpreted in the same way > as > the equivalent Option with SZX =3D=3D 6, except that the payload is = also > allowed to contain a multiple of 1024 bytes (non-final BERT block) > or > more than 1024 bytes (final BERT block). >=20 > And your examples pretty clearly show it being >> 1024. What's the > reasoning here >=20 > In control usage, a BERT option is interpreted in the same way as > the > equivalent Option with SZX =3D=3D 6, except that it also indicates = the > capability to process BERT blocks. Right, this is from the time we didn=E2=80=99t have the CSM mechanism = yet. > But: >=20 > Block-wise Transfer Option. If a Max-Message-Size Option is > indicated with a value that is greater than 1152 (in the same or a > different CSM message), the Block-wise Transfer Option also > indicates > support for BERT (see Section 6). Subsequently, if the Max-Message- >=20 > Is this an instruction to set the BTO to be 7? Or redundancy? Max-Message-Size is not redundant, as it gives you the actual message = size the peer can process. But the above language about indicating BERT capability in an SZX is = redundant now. Now https://github.com/core-wg/coap-tcp-tls/issues/147 > EDITORIAL > S 3.2. > Length (Len): 4-bit unsigned integer. A value between 0 and 12 > directly indicates the length of the message in bytes starting >=20 > I think you want to say "0 and 12 inclusive=E2=80=9D Yes. Now in https://github.com/core-wg/coap-tcp-tls/issues/148 >=20 >=20 > S 5.3.1. > These are not default values for the option, as defined in > Section 5.4.4 in [RFC7252]. A default value would mean that an > empty > Capabilities and Settings message would result in the option being > set to its default value. >=20 > This is pretty confusing text. I take it that it means that if > the base values of both A and B are 0, then: >=20 > Start // A=3D0, B=3D0 > CSM[A=3D1] // A=3D1, B=3D0 > CSM[B=3D2] // A=3D1, B=3D2 >=20 > Whereas if these were default values, then this would be: >=20 > Start // A=3D0, B=3D0 > CSM[A=3D1] // A=3D1, B=3D0 > CSM[B=3D2] // A=3D0, B=3D2 <- A resets to default >=20 > If that's so, perhaps you could say: >=20 > These are not default values for the option, as defined in > Section 5.4.4 in [RFC7252], because default values apply > on a per-message basis and thus reset when the value is > not present in a given CSM. =E2=80=9CReset when not present=E2=80=9D would be confusing for my = brain. But yes, this has already confused other people, and we need to improve = it. Now in https://github.com/core-wg/coap-tcp-tls/issues/148 Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 10 00:28:29 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7611294DC for ; Wed, 10 May 2017 00:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 VVpMtStDGjDy for ; Wed, 10 May 2017 00:28:24 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A564212932A for ; Wed, 10 May 2017 00:28:24 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:208]) by smtp-cloud2.xs4all.net with ESMTP id JXUN1v0014ydcfa01XUNSs; Wed, 10 May 2017 09:28:22 +0200 Received: from 2001:983:a264:1:517:1881:a53d:d36d by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 10 May 2017 09:28:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 10 May 2017 09:28:22 +0200 From: peter van der Stok To: Michael Koster Cc: "Dijk, Esko" , consultancy@vanderstok.org, Lauri Piikivi , Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <2688B534-A979-42F6-AC33-925817005F80@tzi.org> <75dc1a630fca3fd2e50fe13f867cb85b@xs4all.nl> <0bd0cd5aac2e444cbb625afc688f1c5f@AM3PR90MB0097.MGDPHG.emi.philips.com> <47fc672effd46a2f414c8eca1440d6cc@xs4all.nl> <0c5863c6f5d341c7af35e3147815e961@AM3PR90MB0097.MGDPHG.emi.philips.com> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [core] Resource Directory: Simplifying Domains X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 07:28:27 -0000 Hi, some suggestions OLD > > Sec. 2 has this: > > Domain > In the context of a Resource Directory, a domain is a logical > grouping of endpoints. This specification assumes that the list > of Domains supported by an RD is pre-configured by that RD. > When > a domain is exported to DNS, the domain value equates to the DNS > domain name. NEW Domain In the context of a Resource Directory, a domain is a logical grouping of endpoints. This specification assumes that the list of Domains supported by an RD is populated during registration or pre-configured. When a domain is exported to DNS, the domain value may be equated to the DNS domain name. OLD > Sec. 3: > > An RD can be logically segmented by the use of Domains. > The domain an endpoint is associated with can be defined > by the RD or configured by an outside entity. This information > hierarchy is shown in Figure 2. NEW An RD can be logically segmented by the use of Domains. The domain an endpoint is associated with can be defined by the RD or configured during registration. This information hierarchy is shown in Figure 2. Cheerio, Peter From nobody Wed May 10 01:20:55 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040BA1270AC; Wed, 10 May 2017 01:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Lbk9AVpDstyu; Wed, 10 May 2017 01:20:50 -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 85500120227; Wed, 10 May 2017 01:20:50 -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 v4A8KkXW002792; Wed, 10 May 2017 10:20:46 +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 3wN8M21VF6zDHsy; Wed, 10 May 2017 10:20:46 +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: <149438322150.24264.16123907495920056718.idtracker@ietfa.amsl.com> Date: Wed, 10 May 2017 10:20:45 +0200 Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 516097245.63054-eb72d2aa074b213c6ed072d86ca75c2e Content-Transfer-Encoding: quoted-printable Message-Id: <82019A15-D975-4D54-848E-1CB3D4C2E95C@tzi.org> References: <149438322150.24264.16123907495920056718.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 08:20:53 -0000 Hi Ben, thank your for your review. Before I start working on it in more detail, let me pick this one = DISCUSS out because I think it is the most momentous issue that needs to = be discussed: > On May 10, 2017, at 04:27, Ben Campbell wrote: >=20 > 2) It seems problematic to encode the transport choice in the URI > scheme. > Section 7 says "They are hosted > in distinct namespaces because each URI scheme implies a distinct > origin > server." IIUC, this means any given resource can only be reached over = a > specific transport. That seems to break the idea of cross-transport > proxies > as discussed in section 7. >=20 > It also does not seem to fit with a primary motivation for this draft. > That > is, one might want to use TCP because of local NAT/FW issues. But if > there is > a resource with a "coap" scheme, I cannot switch to TCP when I'm = behind > a > problematic middlebox, and have an expectation of reaching the same > resource. I would rephrase the issue as: URIs don=E2=80=99t have a good place to put in transport hints. (The definition of a transport hint in a URI would be information that = lets me set up specific transports without creating a separate resource = each time the values of that transport hint differ.) Note that the main use case for the document at hand is one where the = client may not be able to reach the server on the =E2=80=9Cmain=E2=80=9D = transport (CoAP over UDP), so negotiation/upgrade(*) mechanisms are not = solving the problem. The solutions that people are talking about in our domain are about = carrying transport alternatives around together. E.g., see draft-silverajan-core-coap-protocol-negotiation-05.txt, which = provides a way to find out about links from a set of links (the resource = directory) while specifying a transport type. [It may be instructive to = go through previous versions of this document just to see what we also = have tried to do.] What we have right now in draft-ietf-core-coap-tcp-tls is what we think = is the least ugly way to solve the problem. The WG is well aware about its problems. We=E2=80=99d rather have a mechanism like transport hints, but we did = not find a solution that would not need to update the web architecture. Gr=C3=BC=C3=9Fe, Carsten (*) This is not an =E2=80=9Cupgrade=E2=80=9D in the sense of going to a = higher version of something in any case; it is just an alternative = transport. From nobody Wed May 10 03:23:57 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1793A1293E1; Wed, 10 May 2017 03:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.9 X-Spam-Level: X-Spam-Status: No, score=-4.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 1mKmAIFsuRJ6; Wed, 10 May 2017 03:23:44 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 6179E129400; Wed, 10 May 2017 03:23:44 -0700 (PDT) Received: from [192.168.91.191] ([80.92.121.214]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MTvUT-1dYyCi21QX-00QnpA; Wed, 10 May 2017 12:23:33 +0200 To: Carsten Bormann , Eric Rescorla References: <149411155754.23175.15150224037348429928.idtracker@ietfa.amsl.com> Cc: core-chairs@ietf.org, The IESG , core@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <28837957-421a-eeff-8304-cfafb80ca234@gmx.net> Date: Wed, 10 May 2017 12:23:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="T7MRmKBdArKbi2Efsv0nTJ1IpvBpU62gO" X-Provags-ID: V03:K0:83hCAINuPShnqfZHs601dET0oUU+78GWrGUen5wuB71vmITuUuA NbktKabbOm2fahUlmLATGQBwCPFD7QWj4wHq7ZI0+PzWwDaxGHV5YwOoOIoj67Abqhm9cCY mQ59iLbdEtI4GMzsxfJSYGSCHy6IU9hkledgKPEIWGpZGlwcLaT13s04sA7qfUZWriefdxr tTppPH0V89vwGsp4kHIIQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:X2EFQf2OQlE=:zisrhpqsEhxXgwzsHGqRSz 6Kg1jQCZ7qf2m8qGusg3mjH+VgA3EfF+CB8ZDz+0+mQ/20OwS6+QtvvqX/nldoW6Gvx2K0Kvp zBU/7UiZocnmM74qhMeVeO+1RkfHex6tqf2z7aHglkRSqzXFlDMoV9gIUIjvduN4e6KYS+JQQ gdM0nym9O3La7QOweUzVwV1ng1jFpHsaXMl+FCsChaAoNGNg/fIA8HjbBoI0R1DJ+MGQpvQN1 kwNkOUPVRqPk8N7aPgWypAQpfupwxhSC/HrpfYhV8e9d71GuSBUjqW5/EmEFj6bh/PMveWfnd OJJLSB3gKpl7LMRPs2grp4R02M9bU7X7nKr2uYmNqF5fZbT2+whKvw8Au0rjCV7wVH4UqrSRH 2klI4I/y2CL9IqDo0Iw0LT8xmUh1hv/8r5NZduT0IvjMmNQT36WpF45j57N71dm/qQInz67fL ZZUOQ0kpZpkYgtClueG5OcHEapSwrpb4DUvYQyIQLBpXBUgekPhg/7fnpfJb/+ZOXcPpJzhyG JSQ6aexW2gV8C1soMy1XyUVI+SQEMIRzqxrjI/lU6+w6aWpC+HrenN0bkrWYlXI1OBxLtZPlh gl4jfGcdb7ZqqeinSdE9cIEK/LkOoG7R1aH+WU0x4Q2Xo57y44ZaWv8/l0xzBAv39xXRRZYXr 9xrYLPSORqVWLojAQJaSMSkinsFeekNLOMqw9en2SJYizfbPkC3c0hWMFNFcJmxkFny0DSrJg tFqw2B+Fnv5v7hbBP+JeDJ947sYbSi0a5KTiK8tokIaZRikxcllw0uoOTSc= Archived-At: Subject: Re: [core] Eric Rescorla's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 10:23:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --T7MRmKBdArKbi2Efsv0nTJ1IpvBpU62gO Content-Type: multipart/mixed; boundary="BQaM8ivLWTJa0D0Ib3pWabk02CSHpagev"; protected-headers="v1" From: Hannes Tschofenig To: Carsten Bormann , Eric Rescorla Cc: core-chairs@ietf.org, The IESG , core@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org Message-ID: <28837957-421a-eeff-8304-cfafb80ca234@gmx.net> Subject: Re: [core] Eric Rescorla's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT) References: <149411155754.23175.15150224037348429928.idtracker@ietfa.amsl.com> In-Reply-To: --BQaM8ivLWTJa0D0Ib3pWabk02CSHpagev Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Adding my remarks here as well. On 05/10/2017 08:12 AM, Carsten Bormann wrote: >> >> Hi Eric, >=20 > thank you for this detailed review. >=20 > ---------------------------------------------------------------------- >> DISCUSS: >> ----------------------------------------------------------------------= >> >> After reading Mark Nottingham's review, I'm persuaded we should at lea= st >> discuss the relationship of this work to the parallel work in HTTP. >=20 > I don=E2=80=99t think the work on HTTP/2 is in any way parallel to the = work of bringing CoAP to work on TCP/TLS. >=20 > There are some elements of Mark=E2=80=99s review that leave me speechle= ss (=E2=80=9Creinventing framing=E2=80=9D? Any TCP-based protocol needs = to reinvent framing, and it=E2=80=99s not like the HTTPs have found the d= efinitive answer this perennial issue yet.). I generally think the compet= ition that is hinted at here is constructed; in reality it does not exist= =2E >=20 > I do believe that a discussion about the relationship of the three REST= transfer protocols, CoAP and the two HTTPs, is useful, if well-prepared.= I also do not see a competition between CoAP and HTTP/2. What this initially tried to do is to describe how some companies (ARM, Microsoft, Zebra) have been deploying CoAP in enterprise networks that block UDP traffic. Why it takes 2 years to standardize such basic features is a mystery to m= e. In the long run, the story for IoT devices may be QUIC & HTTP/2 but today HTTP/2 on IoT devices is essentially non-existent. >=20 > But let me dive in to some specifics below. >=20 >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> Document: draft-ietf-core-coap-tcp-tls-08.txt >> >> TECHNICAL >> You need to specify MTI cipher suites. I don't think that the >> ones you specified in 7925 are very useful for TLS. Is this really >> really what you want? >=20 > Indeed, you are uncovering an issue here: >=20 > The recommendations in the document (in 7925 Section 4.2, 4.3) are good= for CoAP over TCP/TLS in the constrained-to-cloud use case. > For backend interfacing, and in particular for the WebSockets case, one= would use what one has in those environments. >=20 > Now https://github.com/core-wg/coap-tcp-tls/issues/145 >=20 > Generally speaking, it is not so clear that MTI cipher suites are as us= eful in this document as they are in the base CoAP spec, as this document= describes a set of optional transport bindings that is needed in a numbe= r of quite different specific use cases, each of which come with their ow= n specific environments. =46rom what I have seen in the IoT space is that there have been differen= t credentials being used. As such, there is no single ciphersuite that matches the deployments. Mandating a single ciphersuite for use with CoAP over TLS for a PSK-ciphersuite and another one for a certificate/raw public key ciphersuite is fine. This is essentially what RFC 7925 does. I have been arguing that the specification should only support CoAP over TLS but I was battled down. Ciao Hannes --BQaM8ivLWTJa0D0Ib3pWabk02CSHpagev-- --T7MRmKBdArKbi2Efsv0nTJ1IpvBpU62gO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJZEuoiAAoJEGhJURNOOiAthnYH/RFNXBKlZxmfzcEan5jfcdsJ ztNRIOeUWYllGTwprzRUSi2kFSW1/LVaBAO+NOBnNDgAra0pq2xs4APV/isAd4Ud t5phO5q9eL5KatYs9snQOm9U9OuiY90kIW+nJGI7FyxcwYnd4xi8QI9JkjGFPl2x lCcPGU/Y16st+0fN1FkKD5A0tibsLX3eWxBO+/LKl82sRW5KIfaQMBzlpKebbn6h tvMCW0ZqSD8LYxLFwm0Mh+LlSaiyCd0xUvDW+RpCS3m1AsksP7TqjIwlKYPixxpd NiLWQcpYWhSFMSzBzyAGULRyaa7U5MejloVuYqbfpAqJl47yz6A7it0ok45u0Yw= =UPUD -----END PGP SIGNATURE----- --T7MRmKBdArKbi2Efsv0nTJ1IpvBpU62gO-- From nobody Wed May 10 06:40:33 2017 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E77129463; Wed, 10 May 2017 06:40:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-core-coap-tcp-tls@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149442363148.22664.577627584227036852.idtracker@ietfa.amsl.com> Date: Wed, 10 May 2017 06:40:31 -0700 Archived-At: Subject: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-c?= =?utf-8?q?ore-coap-tcp-tls-08=3A_=28with_DISCUSS=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 13:40:31 -0000 Mirja K眉hlewind has entered the following ballot position for draft-ietf-core-coap-tcp-tls-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1) My general concern is that, while I don't necessarily want to block the proposed format, I would like to understand further before publication why this approach was chosen. Similar to Ben's discuss, I don't understand why the format was chosen so differently. You could just use the format (plus a new length option) as defined for UPD and just never have any retransmission or reordering but be more flexible on the lower layer transport to use. However, if you actually prefer a new format (to save space), than that sounds like a new version for me, while the draft says: "CoAP is defined in [RFC7252] with a version number of 1. At this time, there is no known reason to support version numbers different from 1." However, in this case it could even have made sense to define a new format/version that could be used for both underlying protocols and either have a length option or a message type and IP option. Further I also don't understand why on the other hand the TCP COAP framing is re-used for websockets because websockets already provides message framing and a length field. Also inline with Ben's discuss, the use of the Block option for CAOP/TCP is not very clear to me. The draft says: "a UDP-to-TCP gateway may simply not have the context to convert a message with a Block Option into the equivalent exchange without any use of a Block Option (it would need to convert the entire blockwise exchange from start to end into a single exchange)" However, given that the COAP/TCP and COAP/UDP format are so different, it's anyway a more complex conversion than just sticking another transport underneath. The argument for HOL blocking due to e.g. upgrades is also not clear to me because you should probably better just use a different TCP connection for that as it really seems to be a different use case. For me this draft looks like you are defining basically a new protocol version and not just COAP over TCP. Again, I don't necessarily want to block this but I would like to understand why the proposed approach was chosen. 2) Comments from the tsv-art review needs to be addressed as well (Thanks to Yoshi Nishida for the review!). Here is the review text for your connivence: "Summary: This document is well-written. It is almost ready to be published as a PS draft once the following points are addressed. 1: It is not clear how the protocol reacts the errors from transport layers (e.g. connection failure). The protocol will just inform apps of the events and the app will decide what to do or the protocol itself will do something? 2: There will be situations where the app layer is freezing while the transport layer is still working. Since transport layers cannot detect this type of failures, there should be some mechanisms for it somewhere in the protocol or in the app layer. The doc needs to address this point. For example, what will happen when a PONG message is not returned for a certain amount of time? 3: Since this draft defines new SZX value, I think the doc needs to update RFC7959. This point should be clarified more in the doc.鈥 3) And inline with Yoshi's comment, I don't think this part in section 3.3 is well specified; especially I don't understand how these two thing fit together: "To avoid unnecessary latency, a Connection Initiator MAY send additional messages without waiting to receive the Connection Acceptor's CSM; ..." and "Endpoints MUST treat a missing or invalid CSM as a connection error and abort the connection (see Section 5.6)." Also how long should I wait until I abort the connection? From nobody Wed May 10 07:28:03 2017 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB4E126CF6; Wed, 10 May 2017 07:28:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-core-coap-tcp-tls@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149442648130.20975.1746338679841036046.idtracker@ietfa.amsl.com> Date: Wed, 10 May 2017 07:28:01 -0700 Archived-At: Subject: [core] Warren Kumari's No Objection on draft-ietf-core-coap-tcp-tls-08: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 14:28:01 -0000 Warren Kumari has entered the following ballot position for draft-ietf-core-coap-tcp-tls-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have many of the same concerns as others, but see not need to hold a DISCUSS myself. From nobody Wed May 10 07:29:01 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEF612714F; Wed, 10 May 2017 07:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 tJBfvHPtzTtY; Wed, 10 May 2017 07:28:52 -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 17774126CF6; Wed, 10 May 2017 07:28:51 -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 v4AESlNH010415; Wed, 10 May 2017 16:28:47 +0200 (CEST) Received: from client-0144.vpn.uni-bremen.de (client-0144.vpn.uni-bremen.de [134.102.107.144]) (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 3wNJWg2jQ5zDJCj; Wed, 10 May 2017 16:28:47 +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: <149442363148.22664.577627584227036852.idtracker@ietfa.amsl.com> Date: Wed, 10 May 2017 16:28:46 +0200 Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 516119326.712235-8bac039775b6469276b352ad460a352a Content-Transfer-Encoding: quoted-printable Message-Id: <799244C3-CD27-4F46-B5E3-E24457BC7F4B@tzi.org> References: <149442363148.22664.577627584227036852.idtracker@ietfa.amsl.com> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?core-coap-tcp-tls-08=3A_=28with_DISCUSS=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 14:28:54 -0000 Hi Mirja, sorry for answering the IESG input out of order, but since you mostly = have questions, I feel I should answer them quickly. > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > 1) My general concern is that, while I don't necessarily want to block > the proposed format, I would like to understand further before > publication why this approach was chosen. Similar to Ben's discuss, I > don't understand why the format was chosen so differently. You could = just > use the format (plus a new length option) as defined for UPD and just > never have any retransmission or reordering but be more flexible on = the > lower layer transport to use. The CoAP (four-byte) fixed header is to a large extent concerned with = the UDP-based reliability layer of UDP CoAP. =20 Keeping around fields that have lost their function is a recipe for = interoperability issues. Let=E2=80=99s go through the UDP format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver| T | TKL | Code | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token (if any, TKL bytes) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| Payload (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The parts that need to change: Ver is no longer needed, as it doesn=E2=80=99t need to be per message on = a reliable transport. T is about reliability models; we don=E2=80=99t need that on TCP, which = imposes its own reliability model. Message ID also is about retransmissions and protection from packet = duplication, which don=E2=80=99t exist on TCP. The majority of the format is unchanged: TKL, Code, Token, Options, Payload Marker (0xFF), Payload are unchanged. Now add a length for framing. The result: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Len | TKL | Code | Token (if any, TKL bytes) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| Payload (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Maybe we should have formatted this as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Len | TKL | Code | Length extension (if any) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token (if any, TKL bytes) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| Payload (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > However, if you actually prefer a new > format (to save space), than that sounds like a new version for me, = while > the draft says: > "CoAP is defined in [RFC7252] with a version number of 1. At this = time, > there is no known reason to support version numbers different from = 1.=E2=80=9D But there is no need to change the UDP format, it will continue to look = the same. > However, in this case it could even have made sense to define a new > format/version that could be used for both underlying protocols and > either have a length option or a message type and IP option. We don=E2=80=99t need a length on UDP, and we don=E2=80=99t need = Ver/T/MID on TCP. So that is the difference in the structure of the first four bytes, = after which the formats are identical. > Further I also don't understand why on the other hand the TCP COAP > framing is re-used for websockets because websockets already provides > message framing and a length field. After taking out the length (which we don=E2=80=99t need on websockets), = as well, we have a four-bit gap. =20 Using the TCP format and just keeping what was the length field MBZ was = the easiest way to handle this. > Also inline with Ben's discuss, the use of the Block option for = CAOP/TCP > is not very clear to me. The draft says: > "a UDP-to-TCP gateway may simply not have the context to convert a > message with a Block Option into the equivalent exchange without > any use of a Block Option (it would need to convert the entire > blockwise exchange from start to end into a single exchange)" > However, given that the COAP/TCP and COAP/UDP format are so different, > it's anyway a more complex conversion than just sticking another > transport underneath. The (pretty much trivial) format conversion is not a source of = complexity, the handling of the state machines is. But that is not a new thing for a proxy at all. > The argument for HOL blocking due to e.g. upgrades > is also not clear to me because you should probably better just use a > different TCP connection for that as it really seems to be a different > use case. One could do that (often requiring the cloud-based component to incite = the constrained device to set up a new connection), or one can simply = use the established Block protocol. > For me this draft looks like you are defining basically a new protocol > version and not just COAP over TCP. As described above, almost all of the protocol is the same. (The pictures are probably a bit misleading, as they don=E2=80=99t show = the juicy parts of the protocol, which are in the code and options = processing.) > 2) Comments from the tsv-art review needs to be addressed as well = (Thanks > to Yoshi Nishida for the review!). Here is the review text for your > connivence: >=20 > "Summary: This document is well-written. It is almost ready to be > published > as a PS draft once the following points are addressed. >=20 > 1: It is not clear how the protocol reacts the errors from transport > layers > (e.g. connection failure). > The protocol will just inform apps of the events and the app will > decide > what to do or the protocol itself will do something? Indeed, the protocol does not define what to do. (This is similar to other application protocols pn top of TCP, say, HTTP = or FTP.) We probably should be more explicit about that fact. > 2: There will be situations where the app layer is freezing while the > transport layer is still working. Since transport layers cannot detect > this > type of failures, there should be some mechanisms for it somewhere in > the > protocol or in the app layer. The doc needs to address this point. = For > example, what will happen when a PONG message is not returned for a > certain > amount of time? Again, that is in the hand of the application. > 3: Since this draft defines new SZX value, I think the doc needs to > update > RFC7959. This point should be clarified more in the doc.=E2=80=9C We will follow what IESG recommends on the question whether the new = document =E2=80=9Cupdates=E2=80=9D (technical term) RFC 7959. > 3) And inline with Yoshi's comment, I don't think this part in section > 3.3 is well specified; especially I don't understand how these two = thing > fit together: > "To avoid unnecessary latency, a Connection Initiator MAY send > additional messages without waiting to receive the Connection > Acceptor's CSM; ..." > and > "Endpoints MUST treat a missing or invalid CSM as a connection error > and abort the connection (see Section 5.6)." > Also how long should I wait until I abort the connection? I think that this is similar to: How long does an HTTP server wait for the first request? Pointing out that this is all in the hands of the application is = probably a good editorial improvement. Now https://github.com/core-wg/coap-tcp-tls/issues/149 Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 10 08:20:42 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2ACD12948F for ; Wed, 10 May 2017 08:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.104 X-Spam-Level: X-Spam-Status: No, score=-0.104 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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=unavailable 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 Zuqb-GCWTIT7 for ; Wed, 10 May 2017 08:20:30 -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 CE018129465 for ; Wed, 10 May 2017 08:20:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=Et8uE9Mvuze2wUz73SIbCqrdPmqk+ivazslZP82YhN3HQJxXZx0Ub28oearjrVCTaf9EMjMTxLWSlLypWMYM52qKHKvTxQM19EPU6WEZc6PITqkxf7CyGSQWm8SyyiK4oYL0JJISHYjXMueoLSoxihecl5x7IYn4C1rayyAE7qc=; h=Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 3073 invoked from network); 10 May 2017 17:13:47 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 10 May 2017 17:13:46 +0200 To: Carsten Bormann References: <149442363148.22664.577627584227036852.idtracker@ietfa.amsl.com> <799244C3-CD27-4F46-B5E3-E24457BC7F4B@tzi.org> Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <3b6dce14-4f07-e382-64d1-5422426c00b0@kuehlewind.net> Date: Wed, 10 May 2017 17:13:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <799244C3-CD27-4F46-B5E3-E24457BC7F4B@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <20170510151347.2041.78824@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?core-coap-tcp-tls-08=3A_=28with_DISCUSS=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 15:20:31 -0000 Hi Carsten, thanks for your quick reply. I quickly just what to add something to this point, providing a long reply at a later point of time. On 10.05.2017 16:28, Carsten Bormann wrote: > The (pretty much trivial) format conversion is not a source of complexity, the handling of the state machines is. If you keep the same format you can also keep the machinery, it's just that if you use TCP underneath you will never need to make a retransmission or any reordering. However, with your protocol changes you basically need a complete new machinery. Mirja From nobody Wed May 10 08:43:46 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703B0129BF7; Wed, 10 May 2017 08:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 sQOQpYSKkpHh; Wed, 10 May 2017 08:43:43 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B3B71294A1; Wed, 10 May 2017 08:43:43 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1494431018; h=from:subject:to:date:message-id; bh=Yx4NNV8wpFKKCdtI1fJ2rvGdfUYpcKaamr/yTDFJ9Ko=; b=h2vm1Ez4nWbnZdsKkvhP6S4vT0kKkZv8FgZ/eoEwWndpdG6qj/RNsjJYfDFgn0mPYViD+DBXQ4D JeUmQB1s456S16Z1LN3jdUbZTB3HSIvzHEZyWtqwH9y5Vt2zkDhGIhGus310v2v1JupAmsVASM20w fVAV9WQSc4Y/W7a+7nkt7eaUvU8l6A+G91ZHkk3OXZnbw+csffA9f5sU2Hr/8RdusKvJyrA0Xjiat O2Sw+Vim01Azz2yr8A5HJ5xeGwfFxmV3Y8bSSHXJM5jl3AK/LqZoHfUredvKlm26Tz6ZleZIlc8NO BQMA3Vwoc5W/hi+vv2x6Ok52VWVuePdCv1gw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 10 May 2017 08:43:37 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 10 May 2017 08:43:26 -0700 From: Jim Schaad To: 'Carsten Bormann' , =?utf-8?Q?'Mirja_K=C3=BChlewind'?= CC: , 'The IESG' , , References: <149442363148.22664.577627584227036852.idtracker@ietfa.amsl.com> <799244C3-CD27-4F46-B5E3-E24457BC7F4B@tzi.org> In-Reply-To: <799244C3-CD27-4F46-B5E3-E24457BC7F4B@tzi.org> Date: Wed, 10 May 2017 08:43:46 -0700 Message-ID: <002301d2c9a4$3807f1f0$a817d5d0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI8kYvF3YQfGYmhChnEySFfRxnS9QI8zjrwoQg6PyA= X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?core-coap-tcp-tls-08=3A_=28with_DISCUSS=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 15:43:45 -0000 Some of my opinions inline. Jim -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Wednesday, May 10, 2017 7:29 AM To: Mirja K=C3=BChlewind Cc: core-chairs@ietf.org; The IESG ; core@ietf.org; = draft-ietf-core-coap-tcp-tls@ietf.org Subject: Re: [core] Mirja K=C3=BChlewind's Discuss on = draft-ietf-core-coap-tcp-tls-08: (with DISCUSS) Hi Mirja, sorry for answering the IESG input out of order, but since you mostly = have questions, I feel I should answer them quickly. > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > 1) My general concern is that, while I don't necessarily want to block = > the proposed format, I would like to understand further before=20 > publication why this approach was chosen. Similar to Ben's discuss, I=20 > don't understand why the format was chosen so differently. You could=20 > just use the format (plus a new length option) as defined for UPD and=20 > just never have any retransmission or reordering but be more flexible=20 > on the lower layer transport to use. The CoAP (four-byte) fixed header is to a large extent concerned with = the UDP-based reliability layer of UDP CoAP. =20 Keeping around fields that have lost their function is a recipe for = interoperability issues. Let=E2=80=99s go through the UDP format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver| T | TKL | Code | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token (if any, TKL bytes) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| Payload (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The parts that need to change: Ver is no longer needed, as it doesn=E2=80=99t need to be per message on = a reliable transport. [JLS] The reason that Ver is no longer needed has nothing to do with the = fact that this is a reliable transport. It has to do with the fact that = you have decided to setup up multiple streams and assign one version = number per stream. The same thing could potentially be done with UDP as = well. I think it would have made more sense to keep the version field = and allow multiple versions to in a single stream just like is done for = UDP. T is about reliability models; we don=E2=80=99t need that on TCP, which = imposes its own reliability model. [JLS] While this is true, the fact that there is no discussion on what = should be happening when you change reliability models for a message in = transit is something that I have always found troublesome. = Additionally, there are some semantics about these which are not = completely related to reliability. It is possible to send messages = across for which it is reasonable that a server not ever respond back if = the request contains an error or would have an empty answer. This = ability has been lost. Message ID also is about retransmissions and protection from packet = duplication, which don=E2=80=99t exist on TCP. [JLS] On this I agree - Message ID has always been about a single hop. The majority of the format is unchanged: TKL, Code, Token, Options, Payload Marker (0xFF), Payload are unchanged. Now add a length for framing. The result: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Len | TKL | Code | Token (if any, TKL bytes) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| Payload (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Maybe we should have formatted this as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Len | TKL | Code | Length extension (if any) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token (if any, TKL bytes) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| Payload (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > However, if you actually prefer a new > format (to save space), than that sounds like a new version for me,=20 > while the draft says: > "CoAP is defined in [RFC7252] with a version number of 1. At this=20 > time, there is no known reason to support version numbers different = from 1.=E2=80=9D But there is no need to change the UDP format, it will continue to look = the same. > However, in this case it could even have made sense to define a new=20 > format/version that could be used for both underlying protocols and=20 > either have a length option or a message type and IP option. We don=E2=80=99t need a length on UDP, and we don=E2=80=99t need = Ver/T/MID on TCP. So that is the difference in the structure of the first four bytes, = after which the formats are identical. > Further I also don't understand why on the other hand the TCP COAP=20 > framing is re-used for websockets because websockets already provides=20 > message framing and a length field. After taking out the length (which we don=E2=80=99t need on websockets), = as well, we have a four-bit gap. =20 Using the TCP format and just keeping what was the length field MBZ was = the easiest way to handle this. > Also inline with Ben's discuss, the use of the Block option for=20 > CAOP/TCP is not very clear to me. The draft says: > "a UDP-to-TCP gateway may simply not have the context to convert a > message with a Block Option into the equivalent exchange without > any use of a Block Option (it would need to convert the entire > blockwise exchange from start to end into a single exchange)" > However, given that the COAP/TCP and COAP/UDP format are so different, = > it's anyway a more complex conversion than just sticking another=20 > transport underneath. The (pretty much trivial) format conversion is not a source of = complexity, the handling of the state machines is. But that is not a new thing for a proxy at all. > The argument for HOL blocking due to e.g. upgrades is also not clear=20 > to me because you should probably better just use a different TCP=20 > connection for that as it really seems to be a different use case. One could do that (often requiring the cloud-based component to incite = the constrained device to set up a new connection), or one can simply = use the established Block protocol. > For me this draft looks like you are defining basically a new protocol = > version and not just COAP over TCP. As described above, almost all of the protocol is the same. (The pictures are probably a bit misleading, as they don=E2=80=99t show = the juicy parts of the protocol, which are in the code and options = processing.) > 2) Comments from the tsv-art review needs to be addressed as well=20 > (Thanks to Yoshi Nishida for the review!). Here is the review text for = > your > connivence: >=20 > "Summary: This document is well-written. It is almost ready to be=20 > published as a PS draft once the following points are addressed. >=20 > 1: It is not clear how the protocol reacts the errors from transport=20 > layers (e.g. connection failure). > The protocol will just inform apps of the events and the app will=20 > decide what to do or the protocol itself will do something? Indeed, the protocol does not define what to do. (This is similar to other application protocols pn top of TCP, say, HTTP = or FTP.) We probably should be more explicit about that fact. > 2: There will be situations where the app layer is freezing while the=20 > transport layer is still working. Since transport layers cannot detect = > this type of failures, there should be some mechanisms for it=20 > somewhere in the protocol or in the app layer. The doc needs to=20 > address this point. For example, what will happen when a PONG message=20 > is not returned for a certain amount of time? Again, that is in the hand of the application. > 3: Since this draft defines new SZX value, I think the doc needs to=20 > update RFC7959. This point should be clarified more in the = doc.=E2=80=9C We will follow what IESG recommends on the question whether the new = document =E2=80=9Cupdates=E2=80=9D (technical term) RFC 7959. > 3) And inline with Yoshi's comment, I don't think this part in section > 3.3 is well specified; especially I don't understand how these two=20 > thing fit together: > "To avoid unnecessary latency, a Connection Initiator MAY send > additional messages without waiting to receive the Connection > Acceptor's CSM; ..." > and > "Endpoints MUST treat a missing or invalid CSM as a connection error > and abort the connection (see Section 5.6)." > Also how long should I wait until I abort the connection? I think that this is similar to: How long does an HTTP server wait for the first request? Pointing out that this is all in the hands of the application is = probably a good editorial improvement. Now https://github.com/core-wg/coap-tcp-tls/issues/149 Gr=C3=BC=C3=9Fe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Wed May 10 08:56:19 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104A9129C4A for ; Wed, 10 May 2017 08:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 i3L8WQMc275B for ; Wed, 10 May 2017 08:56:08 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 615A3129C41 for ; Wed, 10 May 2017 08:56:05 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id 203so18084767ywe.0 for ; Wed, 10 May 2017 08:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NW5ozenXFWCx74zUfyYeYCYaBsWupsszBe+B8ZNzmLE=; b=xdiCs1bNQ5O5M9vqdqe1gGOD6rIBDz/k7KHLWmpN5CBDNHfNSnQ9OEDl7zcnHzEmeQ ARMpc4qaiQhDQdrK+NLHo1y0IGq7cezy/YpMccuQC6Ty6LVP1BHrJfr/g83hOFQp14XA RwjxebNZn3wPu6e1n5mPxjX08IECY+Nzic+fUk13NyY/Lq/gT0aUuEl9d7gMokH93d3b XBUgrdAggM3u9d5ouiRxqaIdNA6Ev2B27kZJ6mILAmYpb8d74p61q5bsuvbmWU0r5ASg HWsajpbdu5iK1OdjrljrkMSEE/kjFwQP/TEl2YnCtPUkhwuvVws9yWOFhhPrHM9bODGB pMlg== 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=NW5ozenXFWCx74zUfyYeYCYaBsWupsszBe+B8ZNzmLE=; b=AwqIom8SyMSqpqdKK6brASjb2v1uhsEIXMjxx1Sq28Vr6ChTd2LYaaW+nFtntNCk5l QELyQt2fSiUAci1vb5Os5HvlXJDQgqfQSnVUwJZtl4jwAbDTXrtk1qbFjmtyZdBzyxOW vgQwGQF6K1uZJcTdd5oNL9iMyELiuQueWt18af3qqI4u8MSxJzKSEX9HdHJxLyES1ljc x6ZzgM2sgtvFB+UvL8BHJwWdkMGCemyC+Pq/gSUqDH1RdodZfFIqGaP/FmR4S2Yc7L1I mFYUv/o4J0zw0papb6hwpNXVgRKJjGzO1/RqVRL9MB0B9fiaRtD1qCFNKj5bdUKN+HSw 7vLw== X-Gm-Message-State: AODbwcCgD6kEdVPgTG4dVP22n/MYKo7HR4ETP9RL71Zst02Z5dS8l6Fe tntG437I0Lx7q27+wGjSKgDgJ+q1hQ== X-Received: by 10.129.5.14 with SMTP id 14mr5307107ywf.85.1494431764555; Wed, 10 May 2017 08:56:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Wed, 10 May 2017 08:55:24 -0700 (PDT) In-Reply-To: References: <149411155754.23175.15150224037348429928.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Wed, 10 May 2017 08:55:24 -0700 Message-ID: To: Carsten Bormann Cc: The IESG , draft-ietf-core-coap-tcp-tls@ietf.org, Jaime Jimenez , core-chairs@ietf.org, "CORE (Constrained RESTful Environments) WG" Content-Type: multipart/alternative; boundary=001a1141746877dc79054f2d8200 Archived-At: Subject: Re: [core] Eric Rescorla's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 15:56:11 -0000 --001a1141746877dc79054f2d8200 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 9, 2017 at 11:12 PM, Carsten Bormann wrote: > > > > Hi Eric, > > thank you for this detailed review. > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > After reading Mark Nottingham's review, I'm persuaded we should at leas= t > > discuss the relationship of this work to the parallel work in HTTP. > > I don=E2=80=99t think the work on HTTP/2 is in any way parallel to the wo= rk of > bringing CoAP to work on TCP/TLS. > > There are some elements of Mark=E2=80=99s review that leave me speechless > (=E2=80=9Creinventing framing=E2=80=9D? Any TCP-based protocol needs to = reinvent framing, > and it=E2=80=99s not like the HTTPs have found the definitive answer this= perennial > issue yet.). I generally think the competition that is hinted at here is > constructed; in reality it does not exist. > > I do believe that a discussion about the relationship of the three REST > transfer protocols, CoAP and the two HTTPs, is useful, if well-prepared. I don't think this is a question of competition so much as whether it is sensible to be developing very parallel technologies in different WGs, and whether the settings in which those technologies will be deployed are sufficiently different to justify that. That's always a question we should be asking when we look at work. > But let me dive in to some specifics below. > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Document: draft-ietf-core-coap-tcp-tls-08.txt > > > > TECHNICAL > > You need to specify MTI cipher suites. I don't think that the > > ones you specified in 7925 are very useful for TLS. Is this really > > really what you want? > > Indeed, you are uncovering an issue here: > > The recommendations in the document (in 7925 Section 4.2, 4.3) are good > for CoAP over TCP/TLS in the constrained-to-cloud use case. > For backend interfacing, and in particular for the WebSockets case, one > would use what one has in those environments. > > Now https://github.com/core-wg/coap-tcp-tls/issues/145 > > Generally speaking, it is not so clear that MTI cipher suites are as > useful in this document as they are in the base CoAP spec, as this docume= nt > describes a set of optional transport bindings that is needed in a number > of quite different specific use cases, each of which come with their own > specific environments. Fair enough. I think the key thing is that it be clear. within that, you have several options: - Inherit the 7295 MTIs - Inherit the TLS MTIs - Define your own MTIs. I tend to think that the first is kind of unwise in this setting, but ultimately it's a WG decision. It does, however, need to be clear. > S 3.2. > > Having the lengths offset by 13 bytes is, IMO, pretty silly. I > > realize it avoids duplication, but it also makes the packets hard to > > read for not much value. As a practical matter, it expands the > > 1-byte length for the range 256-268, for a savings of less than > > .5% even on those packets and on average far less. > > This just mirrors the way CoAP is encoding lengths (and other values) in > other places. > > The 0.5 % savings is nice to have (but would indeed be a silly motivation > on its own). > The motivation for the length encoding used in CoAP (which we iterated on > quite a bit between 2012 and 2013) ultimately was to get deterministic > coding: For each length, there is exactly one way to encode it, so it is > harder to trip up implementations by (accidentally or deliberately) using > an alternate encoding. > Being nitpicky: the property you are describing here is not deterministic coding but rather is something stricter (bijective, I guess). You could get deterministic simply by requiring people to pick the minimal encoding. I'm not sure I am persuaded that this is actually less likely to trip people up, given that it requires integer addition that overflows the minimal size of the integer you read into. Again, this is a WG decision (hence this being a comment), but I'm not persuaded that this is the right answer. > S 4.1. > > The WebSocket client MUST include the subprotocol name "coap" in the > > list of protocols, which indicates support for the protocol defined > > in this document. Any later, incompatible versions of CoAP or CoAP > > over WebSockets will use a different subprotocol name. > > > > This doesn't make much sense, because you are willing to have > > incompatible > > protocols for TCP, where you use CSM to distinguish them, and you do > > the same thing with ALPN. > > The sentence was about =E2=80=9Cincompatible=E2=80=9D in the sense that y= ou wouldn=E2=80=99t even > understand the CSM. > No idea why we would make changes like that, but unexpected protocol > evolution does happen, and it is good that ALPN has us covered here. > Right, but my point is that this creates an inconsistency with the other operating modes that don't include ALPN, so I don't see how you're going to deploy it. > > S 5.5. > > These release semantics seem quite problematic. In particular, when > > people want an orderly close, they typically want the other side > > to process all the outstanding requests and then return them, but > > this doesn't seem to do that (note that just because the responses > > need to be *delivered* in order doesn't mean they need to be generated > > in order). So, for instance, say I have the following sequence of > > events: > > > > C S DB > > GET /a -> > > Request A -> > > Release -> > > FIN > > <- Response A > > > > It seems like the only difference between Abort and Release is that > > the sender is saying "don't expect that I processed any of your > > messages", but in at least a lot of scenarios (e.g., where the > > initiator is basically just a client), this doesn't actually tell > > the server much about sequence because the responses aren't ordered > > wrt Release AFAICT. > > > > Release message by closing the TCP/TLS connection. Messages may be > > in flight when the sender decides to send a Release message. The > > general expectation is that these will still be processed. > > > > This is not really useful language. > > I see what you mean. The intention is that a Release actually does allow > the other side to process outstanding requests, so in the above example t= he > server would actually send =E2=80=9CResponse A=E2=80=9D before closing. > > Now https://github.com/core-wg/coap-tcp-tls/issues/146 > > > For CoAP over reliable transports, the recipient rejects such > > messages by sending an Abort message and otherwise ignoring the > > message. No specific option has been defined for the Abort message > > in this case, as the details are best left to a diagnostic payload. > > > > I don't understand this text. Abort seems to mean "I'm done", but then > > how am I ignoring the message. > > > Ignoring as in =E2=80=9Cnot processing=E2=80=9D. > > (This is echoing the equivalent text from RFC 7252, do we need to use > different wording?) > I think it might help.... -Ekr --001a1141746877dc79054f2d8200 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 9, 2017 at 11:12 PM, Carsten Bormann <= cabo@tzi.org> wrote:
>
> Hi Eric,

thank you for this detailed review.

-----------------------------------------------------------------= -----
> DISCUSS:
> ------------------------------------------------------------= ----------
>
> After reading Mark Nottingham's review, I'm persuaded we shoul= d at least
> discuss the relationship of this work to the parallel work in HTTP.
I don=E2=80=99t think the work on HTTP/2 is in any way parallel to t= he work of bringing CoAP to work on TCP/TLS.

There are some elements of Mark=E2=80=99s review that leave me speechless (= =E2=80=9Creinventing framing=E2=80=9D?=C2=A0 Any TCP-based protocol needs t= o reinvent framing, and it=E2=80=99s not like the HTTPs have found the defi= nitive answer this perennial issue yet.). I generally think the competition= that is hinted at here is constructed; in reality it does not exist.

I do believe that a discussion about the relationship of the three REST tra= nsfer protocols, CoAP and the two HTTPs, is useful, if well-prepared.

I don't think this is a question of competit= ion so much as whether it is sensible to be developing very parallel techno= logies in different WGs, and whether the settings in which those technologi= es will be deployed are sufficiently different to justify that. That's = always a question we should be asking when we look at work.

<= /div>

But let me dive in to some specifics below.

> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> Document: draft-ietf-core-coap-tcp-tls-08.txt
>
> TECHNICAL
> You need to specify MTI cipher suites. I don't think that the
> ones you specified in 7925 are very useful for TLS. Is this really
> really what you want?

Indeed, you are uncovering an issue here:

The recommendations in the document (in 7925 Section 4.2, 4.3) are good for= CoAP over TCP/TLS in the constrained-to-cloud use case.
For backend interfacing, and in particular for the WebSockets case, one wou= ld use what one has in those environments.

Now https://github.com/core-wg/coap-tcp-tls/i= ssues/145

Generally speaking, it is not so clear that MTI cipher suites are as useful= in this document as they are in the base CoAP spec, as this document descr= ibes a set of optional transport bindings that is needed in a number of qui= te different specific use cases, each of which come with their own specific= environments.

Fair enough. I think the key= thing is that it be clear. within that, you have several options:

- Inherit the 7295 MTIs
- Inherit the TLS MTIs
- Define your own MTIs.

I tend to think t= hat the first is kind of unwise in this setting, but ultimately it's a = WG decision. It does, however, need to be clear.

= =C2=A0

> S 3.2.
> Having the lengths offset by 13 bytes is, IMO, pretty silly.=C2=A0 I > realize it avoids duplication, but it also makes the packets hard to > read for not much value. As a practical matter, it expands the
> 1-byte length for the range 256-268, for a savings of less than
> .5% even on those packets and on average far less.

This just mirrors the way CoAP is encoding lengths (and other values= ) in other places.

The 0.5 % savings is nice to have (but would indeed be a silly motivation o= n its own).
The motivation for the length encoding used in CoAP (which we iterated on q= uite a bit between 2012 and 2013) ultimately was to get deterministic codin= g: For each length, there is exactly one way to encode it, so it is harder = to trip up implementations by (accidentally or deliberately) using an alter= nate encoding.

Being nitpicky: the prop= erty you are describing here is not deterministic coding but rather
is something stricter (bijective, I guess). You could get deterministic = simply by requiring
people to pick the minimal encoding.

I'm not sure I am persuaded that this is actually less= likely to trip people up, given that
it requires integer additio= n that overflows the minimal size of the integer you read into.
A= gain, this is a WG decision (hence this being a comment), but I'm not p= ersuaded that
this is the right answer.

=
> S 4.1.
>=C2=A0 =C2=A0The WebSocket client MUST include the subprotocol name &qu= ot;coap" in the
>=C2=A0 =C2=A0list of protocols, which indicates support for the protoco= l defined
>=C2=A0 =C2=A0in this document.=C2=A0 Any later, incompatible versions o= f CoAP or CoAP
>=C2=A0 =C2=A0over WebSockets will use a different subprotocol name.
>
> This doesn't make much sense, because you are willing to have
> incompatible
> protocols for TCP, where you use CSM to distinguish them, and you do > the same thing with ALPN.

The sentence was about =E2=80=9Cincompatible=E2=80=9D in the sense t= hat you wouldn=E2=80=99t even understand the CSM.
No idea why we would make changes like that, but unexpected protocol evolut= ion does happen, and it is good that ALPN has us covered here.

Right, but my point is that this creates an inconsi= stency with the other
operating modes that don't include ALPN= , so I don't see how you're
going to deploy it.


> S 5.5.
> These release semantics seem quite problematic. In particular, when > people want an orderly close, they typically want the other side
> to process all the outstanding requests and then return them, but
> this doesn't seem to do that (note that just because the responses=
> need to be *delivered* in order doesn't mean they need to be gener= ated
> in order). So, for instance, say I have the following sequence of
> events:
>
> C=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0S=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DB
> GET /a ->
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Request = A ->
> Release ->
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 FIN
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <- Re= sponse A
>
> It seems like the only difference between Abort and Release is that > the sender is saying "don't expect that I processed any of yo= ur
> messages", but in at least a lot of scenarios (e.g., where the > initiator is basically just a client), this doesn't actually tell<= br> > the server much about sequence because the responses aren't ordere= d
> wrt Release AFAICT.
>
>=C2=A0 =C2=A0Release message by closing the TCP/TLS connection.=C2=A0 M= essages may be
>=C2=A0 =C2=A0in flight when the sender decides to send a Release messag= e.=C2=A0 The
>=C2=A0 =C2=A0general expectation is that these will still be processed.=
>
> This is not really useful language.

I see what you mean.=C2=A0 The intention is that a Release actually = does allow the other side to process outstanding requests, so in the above = example the server would actually send =E2=80=9CResponse A=E2=80=9D before = closing.

Now https://github.com/core-wg/coap-tcp-tls/i= ssues/146

>=C2=A0 =C2=A0For CoAP over reliable transports, the recipient rejects s= uch
>=C2=A0 =C2=A0messages by sending an Abort message and otherwise ignorin= g the
>=C2=A0 =C2=A0message.=C2=A0 No specific option has been defined for the= Abort message
>=C2=A0 =C2=A0in this case, as the details are best left to a diagnostic= payload.
>
> I don't understand this text. Abort seems to mean "I'm do= ne", but then
> how am I ignoring the message.


Ignoring as in =E2=80=9Cnot processing=E2=80=9D.

(This is echoing the equivalent text from RFC 7252, do we need to use diffe= rent wording?)

I think it might help...= .
=C2=A0
-Ekr


--001a1141746877dc79054f2d8200-- From nobody Wed May 10 08:57:05 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F260129C40; Wed, 10 May 2017 08:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 KmgemnWTP3b2; Wed, 10 May 2017 08:56:56 -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 DCB70129C30; Wed, 10 May 2017 08:56:55 -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 v4AFukcY022676; Wed, 10 May 2017 17:56:46 +0200 (CEST) Received: from client-0223.vpn.uni-bremen.de (client-0223.vpn.uni-bremen.de [134.102.107.223]) (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 3wNLT94hV0zDJFS; Wed, 10 May 2017 17:56:45 +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: <002301d2c9a4$3807f1f0$a817d5d0$@augustcellars.com> Date: Wed, 10 May 2017 17:56:43 +0200 Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , core-chairs@ietf.org, The IESG , core@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org X-Mao-Original-Outgoing-Id: 516124603.605815-1f689a6ea1e1bec95c78572aa034ce99 Content-Transfer-Encoding: quoted-printable Message-Id: <13F288CF-AD20-4D7E-8FFE-0D417DCF155F@tzi.org> References: <149442363148.22664.577627584227036852.idtracker@ietfa.amsl.com> <799244C3-CD27-4F46-B5E3-E24457BC7F4B@tzi.org> <002301d2c9a4$3807f1f0$a817d5d0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?core-coap-tcp-tls-08=3A_=28with_DISCUSS=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 15:56:58 -0000 > On May 10, 2017, at 17:43, Jim Schaad wrote: >=20 > Ver is no longer needed, as it doesn=E2=80=99t need to be per message = on a reliable transport. >=20 > [JLS] The reason that Ver is no longer needed has nothing to do with = the fact that this is a reliable transport. It has to do with the fact = that you have decided to setup up multiple streams and assign one = version number per stream. The same thing could potentially be done = with UDP as well. I think it would have made more sense to keep the = version field and allow multiple versions to in a single stream just = like is done for UDP. Fundamentally, version numbers are overrated. CoAP versions are not for = counting through small behavior changes. I struggle to find a reason to mix multiple format versions on one = stream. CoAP-TCP is doing the right thing here. > T is about reliability models; we don=E2=80=99t need that on TCP, = which imposes its own reliability model. >=20 > [JLS] While this is true, the fact that there is no discussion on what = should be happening when you change reliability models for a message in = transit is something that I have always found troublesome. = Additionally, there are some semantics about these which are not = completely related to reliability. It is possible to send messages = across for which it is reasonable that a server not ever respond back if = the request contains an error or would have an empty answer. This = ability has been lost. Well, that is a comment on CoAP, not on the present specification. We = don=E2=80=99t have a way to indicate what reliability model we expect a = proxy to use for its forwarded request. That is usually simply not for = the client to decide. There are some approaches that seem to imply that = a UDP proxy must use exactly the same reliability model for the = forwarded request as was used for the client request, and that may = actually be a good implementation strategy if you don=E2=80=99t want to = address the issue more throughly. But a Non-confirmable request coming = in from an on-link client on an Ethernet has a quite different = reliability to it than even a Confirmable request on a very flaky = low-power wireless link. (Other standards in this space have =E2=80=9CQoS classes=E2=80=9D, which = I don=E2=80=99t even want to start to berate here.) Should a client be able to instruct a proxy about the next-hop = reliability? If yes, there is more to this than the NON/CON = distinction, and we should do a real solution for this. Not here. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 10 09:25:03 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A0C129C68; Wed, 10 May 2017 09:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.018 X-Spam-Level: X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 2kVff1KKyaEM; Wed, 10 May 2017 09:24:59 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A42F4129C55; Wed, 10 May 2017 09:24:58 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4AGOtgH091798 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 May 2017 11:24:58 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Carsten Bormann , =?UTF-8?Q?Mirja_K=c3=bchlewind?= Cc: core-chairs@ietf.org, The IESG , core@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org References: <149442363148.22664.577627584227036852.idtracker@ietfa.amsl.com> <799244C3-CD27-4F46-B5E3-E24457BC7F4B@tzi.org> From: Adam Roach Message-ID: Date: Wed, 10 May 2017 11:24:50 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <799244C3-CD27-4F46-B5E3-E24457BC7F4B@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?core-coap-tcp-tls-08=3A_=28with_DISCUSS=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 16:25:01 -0000 On 5/10/17 09:28, Carsten Bormann wrote: > The (pretty much trivial) format conversion is not a source of complexity, the handling of the state machines is. > But that is not a new thing for a proxy at all. You state this like the complexity of adapting two different state machines to each other is unavoidably inherent to a proxy that performs these kinds of transport conversions; but it's not. The only reason this complexity arises for CoAP is because the design in this document requires it. If you simply encapsulated UDP over TCP with simple framing, and left handing of reordering and deduplication identical to what currently exists for CoAP over UDP, then the proxy could shuttle messages from one side to the other, with the only needed state being that directly related to the TCP connection. (And if you left in the fields that you find unnecessary in TCP, it would be able to do it with far fewer memory copies, which would make for significantly better scalability; and, as a bonus, you wouldn't need multiple sets of parsing and marshalling code in endpoints that support both UDP and TCP). Proxies between different transports don't *have* to be complicated. /a From nobody Wed May 10 09:25:44 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D8A129C66; Wed, 10 May 2017 09:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 E0T7SNntm2LY; Wed, 10 May 2017 09:25:34 -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 4BCF512947B; Wed, 10 May 2017 09:25:34 -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 v4AGPUtY016531; Wed, 10 May 2017 18:25:30 +0200 (CEST) Received: from client-0223.vpn.uni-bremen.de (client-0223.vpn.uni-bremen.de [134.102.107.223]) (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 3wNM6K5ngMzDJG1; Wed, 10 May 2017 18:25:29 +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: Wed, 10 May 2017 18:25:28 +0200 Cc: The IESG , draft-ietf-core-coap-tcp-tls@ietf.org, Jaime Jimenez , core-chairs@ietf.org, "CORE (Constrained RESTful Environments) WG" X-Mao-Original-Outgoing-Id: 516126328.180255-4f7e233e34673313fea5e507e16a7220 Content-Transfer-Encoding: quoted-printable Message-Id: <1838D73B-2275-41DC-B6B3-D44E90A709CD@tzi.org> References: <149411155754.23175.15150224037348429928.idtracker@ietfa.amsl.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Eric Rescorla's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 16:25:36 -0000 > I don't think this is a question of competition so much as whether it = is sensible to be developing very parallel technologies in different = WGs, and whether the settings in which those technologies will be = deployed are sufficiently different to justify that. That's always a = question we should be asking when we look at work. True. We used to have a pretty good IESG consensus that it is worth to = have an IETF stack for constrained devices. The pretty good pickup of that stack by other SDOs seems to corroborate = this. In fact, the present document is on the table because both OCF and OMA = saw a need for it. Of course, there will always be people who say that Moore=E2=80=99s law = will get rid of constrained environments. There also always will be people to say that IP is too heavyweight in = the first place for these. Since chartering 6LoWPAN in 2005, we have spent a lot of time proving = them wrong, and those SDOs would not understand why we stop doing that = (and I wouldn=E2=80=99t either). > Fair enough. I think the key thing is that it be clear. within that, = you have several options: >=20 > - Inherit the 7295 MTIs > - Inherit the TLS MTIs > - Define your own MTIs. >=20 > I tend to think that the first is kind of unwise in this setting, but = ultimately it's a WG decision. It does, however, need to be clear. Again, this presumes MTIs are desirable (or even possible!), but we = definitely can give better guidance. Added this list to https://github.com/core-wg/coap-tcp-tls/issues/145 > Being nitpicky: the property you are describing here is not = deterministic coding but rather > is something stricter (bijective, I guess). You could get = deterministic simply by requiring > people to pick the minimal encoding. Well, if we could rely on peers always implementing the MUSTs=E2=80=A6 > I'm not sure I am persuaded that this is actually less likely to trip = people up, given that > it requires integer addition that overflows the minimal size of the = integer you read into. > Again, this is a WG decision (hence this being a comment), but I'm not = persuaded that > this is the right answer. CoAP implementers already have coded this once (they might even re-use = that code). > Right, but my point is that this creates an inconsistency with the = other > operating modes that don't include ALPN, so I don't see how you're > going to deploy it. Yes. I think that sentence is making a gratuitous speculation about an = unknown unknown, and we should get rid of it. Now https://github.com/core-wg/coap-tcp-tls/issues/150 >=20 > Ignoring as in =E2=80=9Cnot processing=E2=80=9D. >=20 > (This is echoing the equivalent text from RFC 7252, do we need to use = different wording?) >=20 > I think it might help=E2=80=A6. Now https://github.com/core-wg/coap-tcp-tls/issues/151 Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 10 09:35:33 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA6512E036 for ; Wed, 10 May 2017 09:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 FNBY-9SMEEhN for ; Wed, 10 May 2017 09:35:25 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 61F0612E039 for ; Wed, 10 May 2017 09:35:22 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id l14so552608ywk.1 for ; Wed, 10 May 2017 09:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tas2qnp1O7zAfvB6RXHIB5WnZqpQ8lKAMsYfXLdH9UU=; b=cgG2MAdhvb5Nt7TGgYwnDuOfqDyLC/s6aGuZgzDIo8Tmt1OmqUffpHk584to4WtNYq woQAWhYfR2vqit0maIPP2gIDy8CRW2Y06s+9bfFaHxrGu9qs6+0nCmg65P+8wGb5+BG5 uZsTLN2juL3fEzrbFWMigNEbU/T8dGl3iar0/Kb5AsaitWxqTdxcsfPKIOfVoIsUhyw7 zzOHRM/fCg7KHSMkYHqgG72LXuIeRvjWpQuW/nPvNRy3cbh0q7bzQETdid7ObZYxs3ti ns9no4vbT6V1jz19UlJslgsywlP/xoixbp6yh2hKu7lY60GGA+q14p7L7zbA98dOg5wM +ZpA== 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=tas2qnp1O7zAfvB6RXHIB5WnZqpQ8lKAMsYfXLdH9UU=; b=M8M34pxX8i0LZNAwDcoqC6AJ7gSqAy5Iub7N/wf5OqxR4oqI7tIS/K5lsyXOYx9STn L1s28ipn7FMfDoEixNP1H7evwrINBD2Bsj5xkB7SJ2PPK93ndzEIBLKsbSNmjdBTW6Rn kWCNGvL0PD/T+MWqEo7ttA9GsDXbSfIHGSw/2XvV/zy1zbXPjBaB9SWIwZUXbGNCUlMH uJKGoEG2pgsFHITPG6KUCRJ3O+ROUEBeAhJkkL/uvAtNPdhX+5eTleseM47oKx9PX4Mt TQ3PF9nv8kvwaNq6UX+bz0qcwH4hKqviR+qOxY5KMEYPQZ1uRs1caYg3+wXpkTZgSN0a uW8g== X-Gm-Message-State: AODbwcC8KLX+Rh/9n1IE7J6DGapLMArKigr6G9A65FpNBfjOT2Kt9cZc 2QxCV5ATZBTPVWdYjIlk6SV1rQJa2g== X-Received: by 10.129.104.69 with SMTP id d66mr5582695ywc.74.1494434121548; Wed, 10 May 2017 09:35:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Wed, 10 May 2017 09:34:40 -0700 (PDT) In-Reply-To: <1838D73B-2275-41DC-B6B3-D44E90A709CD@tzi.org> References: <149411155754.23175.15150224037348429928.idtracker@ietfa.amsl.com> <1838D73B-2275-41DC-B6B3-D44E90A709CD@tzi.org> From: Eric Rescorla Date: Wed, 10 May 2017 09:34:40 -0700 Message-ID: To: Carsten Bormann Cc: The IESG , draft-ietf-core-coap-tcp-tls@ietf.org, Jaime Jimenez , core-chairs@ietf.org, "CORE (Constrained RESTful Environments) WG" Content-Type: multipart/alternative; boundary=001a11490b9af53523054f2e0eb7 Archived-At: Subject: Re: [core] Eric Rescorla's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 16:35:27 -0000 --001a11490b9af53523054f2e0eb7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 10, 2017 at 9:25 AM, Carsten Bormann wrote: > > Of course, there will always be people who say that Moore=E2=80=99s law w= ill get > rid of constrained environments. > There also always will be people to say that IP is too heavyweight in the > first place for these. > Since chartering 6LoWPAN in 2005, we have spent a lot of time proving the= m > wrong, and those SDOs would not understand why we stop doing that (and I > wouldn=E2=80=99t either). > The issue at hand is not whether Moore's law will get rid of constrained environments but rather whether having a completely parallel stack is the right way to accommodate such environments. > Fair enough. I think the key thing is that it be clear. within that, you > have several options: > > > > - Inherit the 7295 MTIs > > - Inherit the TLS MTIs > > - Define your own MTIs. > > > > I tend to think that the first is kind of unwise in this setting, but > ultimately it's a WG decision. It does, however, need to be clear. > > Again, this presumes MTIs are desirable (or even possible!), You are of course free to disagree, but this is not an open question in this case. TLS 1.2 explicitly specifies an MTI cipher suite, and so if you do nothing you inherit it. (https://tools.ietf.org/rfcmarkup?doc=3D5246#section-9). I supp= ose that you could explicitly disclaim an MTI here, but then I think you would have some trouble :) > but we definitely can give better guidance. > Added this list to https://github.com/core-wg/coap-tcp-tls/issues/145 > > > Being nitpicky: the property you are describing here is not > deterministic coding but rather > > is something stricter (bijective, I guess). You could get deterministic > simply by requiring > > people to pick the minimal encoding. > > Well, if we could rely on peers always implementing the MUSTs=E2=80=A6 > Yes. > I'm not sure I am persuaded that this is actually less likely to trip > people up, given that > > it requires integer addition that overflows the minimal size of the > integer you read into. > > Again, this is a WG decision (hence this being a comment), but I'm not > persuaded that > > this is the right answer. > > CoAP implementers already have coded this once (they might even re-use > that code). This is not really a technical argument about the merits of this design choice. As I said, this is a COMMENT, so you're free to simply ignore me, but if your objective is to persuade me, you have not yet done so. -Ekr --001a11490b9af53523054f2e0eb7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 10, 2017 at 9:25 AM, Carsten Bormann <= cabo@tzi.org> wrote:
Of course, there will always be people who say that Moore=E2=80=99s law wil= l get rid of constrained environments.
There also always will be people to say that IP is too heavyweight in the f= irst place for these.
Since chartering 6LoWPAN in 2005, we have spent a lot of time proving them = wrong, and those SDOs would not understand why we stop doing that (and I wo= uldn=E2=80=99t either).

The issue at ha= nd is not whether Moore's law will get rid of constrained environments = but
rather whether having a completely parallel stack is the righ= t way to accommodate such
environments.

=
> Fair enough. I think the key thing is that it be clear. within that, y= ou have several options:
>
> - Inherit the 7295 MTIs
> - Inherit the TLS MTIs
> - Define your own MTIs.
>
> I tend to think that the first is kind of unwise in this setting, but = ultimately it's a WG decision. It does, however, need to be clear.

Again, this presumes MTIs are desirable (or even possible!),

You are of course free to disagree, but this is no= t an open question in this case.
TLS 1.2 explicitly specifies an = MTI cipher suite, and so if you do nothing you
that you = could explicitly disclaim an MTI here, but then I think you would
have some trouble :)

=C2=A0
but we definitely can give better guidan= ce.
Added this list to https://github.com/core-wg/coap-tcp-tls/issues/145

> Being nitpicky: the property you are describing here is not determinis= tic coding but rather
> is something stricter (bijective, I guess). You could get deterministi= c simply by requiring
> people to pick the minimal encoding.

Well, if we could rely on peers always implementing the MUSTs=E2=80= =A6

Yes.


<= /div>
> I'm not sure I am persuaded that this is actually less likely to t= rip people up, given that
> it requires integer addition that overflows the minimal size of the in= teger you read into.
> Again, this is a WG decision (hence this being a comment), but I'm= not persuaded that
> this is the right answer.

CoAP implementers already have coded this once (they might even re-u= se that code).

This is not really a technic= al argument about the merits of this design choice.

As I said, this is a COMMENT, so you're free to simply ignore me, but= if your
objective is to persuade me, you have not yet done so.

-Ekr

--001a11490b9af53523054f2e0eb7-- From nobody Wed May 10 09:38:28 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9C01242F5; Wed, 10 May 2017 09:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 seZgWh5imJ8p; Wed, 10 May 2017 09:38:25 -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 0B7E312949B; Wed, 10 May 2017 09:38:24 -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 v4AGcLY2025838; Wed, 10 May 2017 18:38:21 +0200 (CEST) Received: from client-0223.vpn.uni-bremen.de (client-0223.vpn.uni-bremen.de [134.102.107.223]) (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 3wNMP95JZGzDJGC; Wed, 10 May 2017 18:38:21 +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: Wed, 10 May 2017 18:38:20 +0200 Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , core-chairs@ietf.org, The IESG , core@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org X-Mao-Original-Outgoing-Id: 516127100.157809-e5b23f81c66761fb4f3960f406dc54f3 Content-Transfer-Encoding: quoted-printable Message-Id: <4DD370D3-62A2-460C-9D3F-0B96EA1A94F6@tzi.org> References: <149442363148.22664.577627584227036852.idtracker@ietfa.amsl.com> <799244C3-CD27-4F46-B5E3-E24457BC7F4B@tzi.org> To: Adam Roach X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?core-coap-tcp-tls-08=3A_=28with_DISCUSS=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 16:38:27 -0000 On May 10, 2017, at 18:24, Adam Roach wrote: >=20 > You state this like the complexity of adapting two different state = machines to each other is unavoidably inherent to a proxy that performs = these kinds of transport conversions; but it's not. >=20 > The only reason this complexity arises for CoAP is because the design = in this document requires it. If you simply encapsulated UDP over TCP = with simple framing, and left handing of reordering and deduplication = identical to what currently exists for CoAP over UDP, then the proxy = could shuttle messages from one side to the other, with the only needed = state being that directly related to the TCP connection. (And if you = left in the fields that you find unnecessary in TCP, it would be able to = do it with far fewer memory copies, which would make for significantly = better scalability; and, as a bonus, you wouldn't need multiple sets of = parsing and marshalling code in endpoints that support both UDP and = TCP). >=20 > Proxies between different transports don't *have* to be complicated. There are indeed simple cases where UDP-to-UDP proxies can be = implemented as UDP payload forwarders. Unfortunately, things become a bit more complex as soon as the proxy has = some fan-in (more than one client), or actually wants to provide some = function such as caching. For TCP, the WG decided we wanted to use TCP's reliability features = instead of re-using our own on top of using TCP just as a datagram = forwarding mechanism. This favors the simplicity of an end-system over = that of certain simple cases of a proxy. (Which is in line with other = design decisions we have made about allotting complexity to different = places in the architecture.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 10 09:49:24 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2C912E042 for ; Wed, 10 May 2017 09:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.104 X-Spam-Level: X-Spam-Status: No, score=-0.104 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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=unavailable 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 DGLCWwZMFw-O for ; Wed, 10 May 2017 09:49:22 -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 703C312E038 for ; Wed, 10 May 2017 09:49:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=LHBOsSkMqkwDj9V5/sna78MavbwPMwiPc9T/wBNKypNoYTd2++B0WDz128ih/QkgAbCl+qaVVKQ790SWDacqRdBNL0RWi6N2qKJvbZevrJbgK8tNQcHoAfUw7nnB0lEIzaWsNDXS12Qeu1dr6O7Y2t8QJAsZUMLurMGieubinMQ=; h=Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 8104 invoked from network); 10 May 2017 18:49:19 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 10 May 2017 18:49:19 +0200 To: Carsten Bormann , Adam Roach References: <149442363148.22664.577627584227036852.idtracker@ietfa.amsl.com> <799244C3-CD27-4F46-B5E3-E24457BC7F4B@tzi.org> <4DD370D3-62A2-460C-9D3F-0B96EA1A94F6@tzi.org> Cc: core-chairs@ietf.org, The IESG , core@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: Date: Wed, 10 May 2017 18:49:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4DD370D3-62A2-460C-9D3F-0B96EA1A94F6@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <20170510164919.8095.14443@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?core-coap-tcp-tls-08=3A_=28with_DISCUSS=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 16:49:23 -0000 On 10.05.2017 18:38, Carsten Bormann wrote: > For TCP, the WG decided we wanted to use TCP's reliability features instead of re-using our own on top of using TCP just as a datagram forwarding mechanism. This favors the simplicity of an end-system over that of certain simple cases of a proxy. (Which is in line with other design decisions we have made about allotting complexity to different places in the architecture.) You cannot use TCP without it reliability features. Having additional reliability in the higher layer simply means the reliability is not used. From nobody Wed May 10 09:56:37 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241F912E039; Wed, 10 May 2017 09:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 sfm5ObFBzYfb; Wed, 10 May 2017 09:56:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6E9CB1242F5; Wed, 10 May 2017 09:56:27 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4AGuQv3095043 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 May 2017 11:56:26 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <82019A15-D975-4D54-848E-1CB3D4C2E95C@tzi.org> Date: Wed, 10 May 2017 11:56:25 -0500 Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9ED35E88-0B02-4B20-B7CE-A7EE07669F35@nostrum.com> References: <149438322150.24264.16123907495920056718.idtracker@ietfa.amsl.com> <82019A15-D975-4D54-848E-1CB3D4C2E95C@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 16:56:29 -0000 > On May 10, 2017, at 3:20 AM, Carsten Bormann wrote: >=20 > Hi Ben, >=20 > thank your for your review. >=20 > Before I start working on it in more detail, let me pick this one = DISCUSS out because I think it is the most momentous issue that needs to = be discussed: >=20 >> On May 10, 2017, at 04:27, Ben Campbell wrote: >>=20 >> 2) It seems problematic to encode the transport choice in the URI >> scheme. >> Section 7 says "They are hosted >> in distinct namespaces because each URI scheme implies a distinct >> origin >> server." IIUC, this means any given resource can only be reached over = a >> specific transport. That seems to break the idea of cross-transport >> proxies >> as discussed in section 7. >>=20 >> It also does not seem to fit with a primary motivation for this = draft. >> That >> is, one might want to use TCP because of local NAT/FW issues. But if >> there is >> a resource with a "coap" scheme, I cannot switch to TCP when I'm = behind >> a >> problematic middlebox, and have an expectation of reaching the same >> resource. >=20 >=20 > I would rephrase the issue as: > URIs don=E2=80=99t have a good place to put in transport hints. >=20 > (The definition of a transport hint in a URI would be information that = lets me set up specific transports without creating a separate resource = each time the values of that transport hint differ.) >=20 > Note that the main use case for the document at hand is one where the = client may not be able to reach the server on the =E2=80=9Cmain=E2=80=9D = transport (CoAP over UDP), so negotiation/upgrade(*) mechanisms are not = solving the problem. That=E2=80=99s exactly what I mean by =E2=80=9Ca primary motivation=E2=80=9D= . As defined, the name of a resource declares the transport. So if I = have a =E2=80=9Ccoap=E2=80=9D scheme resource that I cannot reach over = UDP, I cannot simply switch to TCP and reach that same resource, even if = the server supports both UDP and TCP. I suppose the server could treat = the two resources as aliases, but the client cannot know that without = some out-of-band agreement. (but see next comment) So is it expected that people have to decide in advance which transport = will be use for any given resource? The middlebox-traversal use case = would seem to favor approaches where the client gets to decide what = transport to use on the fly. >=20 > The solutions that people are talking about in our domain are about = carrying transport alternatives around together. > E.g., see draft-silverajan-core-coap-protocol-negotiation-05.txt, = which provides a way to find out about links from a set of links (the = resource directory) while specifying a transport type. [It may be = instructive to go through previous versions of this document just to see = what we also have tried to do.] So from an admittedly very quick scan, am I correct to assume that the = directory described in that draft could be as =E2=80=9Cout-of-band=E2=80=9D= mechanism to declare resource aliases as I mentioned above? So why not = use that sort of mechanism to advertise the available transports for an = authority, and at least allow the transport selection to be completely = decoupled from the scheme? If people really want to bind transport selection to the resource name, = then some such mechanism seems to be a requirement to make the solution = in this draft fit for purpose. But the transport-negotiation draft is = not yet adopted by CORE. Does it make sense to publish this before that = is well on it=E2=80=99s way to ready? >=20 > What we have right now in draft-ietf-core-coap-tcp-tls is what we = think is the least ugly way to solve the problem. > The WG is well aware about its problems. > We=E2=80=99d rather have a mechanism like transport hints, but we did = not find a solution that would not need to update the web architecture. At least some other protocols do this with DNS NAPTR records. I realize = that may not be realistic for constrained devices (and I gather the = protocol-negotiation draft attacks that same problem.) SIP, for example, = can specify the transport with a URI parameter, which allows a URI to = either specify a transport or to be transport-independent (by leaving = off the parameter.) Thanks! Ben.= From nobody Wed May 10 11:31:25 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D7E12E054; Wed, 10 May 2017 11:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 FPHtlBpreS5X; Wed, 10 May 2017 11:31:20 -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 0FAE912E049; Wed, 10 May 2017 11:31:19 -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 v4AIVFxQ027372; Wed, 10 May 2017 20:31:15 +0200 (CEST) Received: from client-0223.vpn.uni-bremen.de (client-0223.vpn.uni-bremen.de [134.102.107.223]) (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 3wNPvQ5yyMzDJHg; Wed, 10 May 2017 20:31:14 +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: <149430548476.30014.11810513211435340238.idtracker@ietfa.amsl.com> Date: Wed, 10 May 2017 20:31:13 +0200 Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 516133873.556914-018df61dff82891c0d33d8e6993ba241 Content-Transfer-Encoding: quoted-printable Message-Id: <7ABC8B29-825A-4FC4-9DF3-7BA877A4561F@tzi.org> References: <149430548476.30014.11810513211435340238.idtracker@ietfa.amsl.com> To: Adam Roach X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Adam Roach's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 18:31:24 -0000 Hi Adam, thank you for your extensive review. Alexey has addressed your procedural DISCUSS, and I don=E2=80=99t have = anything to add there. I will try to make one quick round through the COMMENTs. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > General =E2=80=94 this is a very bespoke approach to what could have = been mostly > solved with a single four-byte =E2=80=9Clength=E2=80=9D header; it is = complicated on the > wire, and in implementation; and the format variations among CoAP over > UDP, coap+tls, and coap+ws are going to make gateways much harder to > implement and less efficient (as they will necessarily have to > disassemble messages and rebuild them to change between formats). The > protocol itself mentions gateways in several places, but does not = discuss > how they are expected to map among the various flavors of CoAP defined = in > this document. Some of the changes seem unnecessary, but it could be = that > I=E2=80=99m missing the motivation for them. Ideally, the introduction = would work > harder at explaining why CoAP over these transports is as different = from > CoAP over UDP as it is, focusing in particular on why the complexity = of > having three syntactically incompatible headers is justified by the > benefits provided by such variations. I think I addressed this one in the comments to Mirja. I=E2=80=99m still amazed how the arrangement of the first few bytes of = the header can cause so much interest. > Additionally, it=E2=80=99s not clear from the introduction what the = motivation > for using the mechanisms in this document is as compared to the > techniques described in section 10 (and its subsections) of RFC 7252. I read this as =E2=80=9Cwhy don=E2=80=99t you use HTTP when you need = TCP=E2=80=9D? CoAP over TCP is more complex than CoAP over UDP, but still much less = complex than either one of the HTTPs. > With the exception of subscribing to resource state (which could be > added), A very big exception =E2=80=94 the observe option is fundamental to many = interactions with Things, and we currently don=E2=80=99t have a way to = map this on HTTP. > it seems that such an approach is significantly easier to > implement and more clearly defined than what is in this document; and = it > appears to provide the combined benefits of all four transports = discussed > in this document. My concern here is that an explosion of transport > options makes it less likely that a client and server can find two in > common: the limit of the probability of two implementations having a > transport in common as the number of transports approaches infinity is > zero. Due to this likely decrease in interoperability, I=E2=80=99d = expect to see > some pretty powerful motivation in here for defining a third, fourth, > fifth, and sixth way to carry CoAP when only TCP is available (I count > RFC 7252 http and https as the first and second ways in this > accounting). These motivations are in the draft. > I=E2=80=99m also a bit puzzled that CoAP already has an inherent = mechanism for > blocking messages off into chunks, which this document circumvents for > TCP connections (by allowing Max-Message-Size to be increased), and = then > is forced to offer remedies for the resultant head-of-line blocking > issues. If you didn=E2=80=99t introduce this feature, messages with a = two-byte > token add six bytes of overhead for every 1024 bytes of content =E2=80=94= less > than 0.6% size inflation. It seems like a lot of complicated machinery = =E2=80=94 > which has a built-in foot-gun that you have to warn people about = misusing > =E2=80=94 for a very tiny gain. I know it=E2=80=99s relatively late in = the process, but > if these trade-offs haven't had a lot of discussion yet, it=E2=80=99s = probably > worth at least giving them some additional thought. There are indeed different ways of handling large bodies (which occur as = payload mainly as an exception in our use cases). The current set of features was defined after OCF complained that the = lock-step nature of the block protocol slowed down their firmware = transfers too much; this was easy to fix my making the message size more = flexible. > I=E2=80=99ll note that the entire BERT mechanism seems to fall into = the same trap > of adding extra complexity for virtually nonexistent savings. CoAP > headers are, by design, tiny. It seems like a serious = over-optimization > to try to eliminate them in this fashion. In particular, you=E2=80=99re = making > the actual implementation code larger to save a trivial number of bits = on > the wire; I was under the impression that many of the implementation > environments CoAP is intended for had some serious on-chip = restrictions > that would point away from this kind of additional complexity. There is a spectrum of devices out there, and some may benefit from this = =E2=80=94 performance issues for larger messages tend to come up with = larger nodes. > Specific comments follow. >=20 > Section 3.3, paragraph 3 says that an initiator may send messages = prior > to receiving the remote side=E2=80=99s CSM, even though the message = may be larger > than would be allowed by that CSM. What should the recipient of an > oversized message do in this case? In fact, I don=E2=80=99t see in = here what a > recipient of a message larger than it allowed for in its CSM is = supposed > to do in response at *any* stage of the connection. Is it an error? If > so, how do you indicate it? Or is the Max-Message-Size option just a > suggestion for the other side? This definitely needs clarification. Given the introduction of Max-Message-Size, there was some speculation = that it would be good to allow going below the default CoAP value of = 1152. In UDP CoAP, preferences of this kind are indicated in the = =E2=80=9Ccontrol usage=E2=80=9D of the Block options, and there is an = assumption that violating them will lead to suboptimal performance, not = to malfunction. But we never really thought that the possibility of = reducing Max-Message-Size below 1152 would motivate making the state = machine more complex; maybe we should state the obvious and add the = warning that indicating a smaller Max-Message-Size is no protection = against receiving a message that was sent off before that new value was = known to the peer. > (Aside =E2=80=94 it seems odd and somewhat backwards that TCP = connections are > provided an affordance for fine-grained control over message sizes, = while > UDP communications are not.) Connections provide a context for performing this control; for = transports that don=E2=80=99t have connections, it is less clear what = the control state should be attached to. (Certainly not four-tuples.) = So far, we have handled DTLS like UDP; theoretically, we could use = CSM-style messages in DTLS, but that hasn=E2=80=99t been explored yet = (and so far I=E2=80=99m not aware of interest in changing CoAP over DTLS = to make use of this theoretical possibility). > Section 4.4 has a prohibition against using WebSockets keepalives in > favor of using CoAP ping/pong. Section 3.4 has no similar prohibition > against TCP keepalives, while the rationale would seem to be = identical. > Is this asymmetry intentional? Successful TCP keepalives are usually not visible to the application, so = they are not quite in the same league as CoAP PING/PONG or WebSocket = mechanism. This is a SHOULD NOT because there may be reasons why the = WebSocket mechanism might be the one to use; the CoAP-level PING/PONG = are closer to the application and provide some CoAP-specific = functionality (such as Custody). > (I=E2=80=99ll also note that the presence of > keepalive mechanisms in both TCP and WebSockets would seem to make the > addition of new CoAP primitives for the same purpose unnecessary, but = I > suspect this has already been debated). One problem with such mechanisms is that they are often buried in layers = that are hard to access/control, so it ay be simpler to solve the = problem at the application layer. (This is a bit of a TLS vs. IPsec = argument.) > Section 5 and its subsections define a new set of message types, > presumably for use only on connection-oriented protocols, although = this > is only implied, and never stated. Now https://github.com/core-wg/coap-tcp-tls/issues/152 > For example, some implementors may see > CSM, Ping, and Pong as potentially useful in UDP; and, finding no > prohibition in this document against using them, decide to give it a = go. > Is that intended? If not, I strongly suggest an explicit prohibition > against using these in UDP contexts. Yes. > Section 5.3.2 says that implementations supporting block-wise = transfers > SHOULD indicate the Block-wise Transfer Option. I can't figure out why > this is anything other than a "MUST=E2=80=9D. Well, they may not want to disclose this capability=E2=80=A6 What the text probably should say is that if they want to make this = capability available to the peer they MUST indicate it. Now https://github.com/core-wg/coap-tcp-tls/issues/153 > It seems odd that this document > would define a way to communicate this, and then choose to leave the > communicated options as =E2=80=9CYES=E2=80=9D and =E2=80=9CYOUR GUESS = IS AS GOOD AS MINE=E2=80=9D rather > than the simpler and more useful =E2=80=9CYES=E2=80=9D and =E2=80=9CNO=E2= =80=9D. Indeed. > I find the described operation of the Custody Option in the operation = of > Ping and Pong to be somewhat problematic: it allows the Pong sender to > unilaterally decide to set the Custody Option, and consequently > quarantine the Pong for an arbitrary amount of time while it processes > other operations. Oh. The intention was that the PINGer gives permission to delay with = the Custody option. =20 I now realize that the text isn=E2=80=99t clear about that. s/Unless there is an option with delaying semantics/Unless the PING carries an option with delaying semantics/ Now https://github.com/core-wg/coap-tcp-tls/issues/154 > This seems impossible to distinguish from a > failure-due-to-timeout from the perspective of the Ping sender. Why = not > limit this behavior only to Ping messages that include the Custody > Option? (Or a similar future option.) > I find the unmotivated definition of the default port for = =E2=80=9Ccoaps+tcp=E2=80=9D to > 443 =E2=80=94 a port that is already assigned to https =E2=80=94 to be = surprising, to put > it mildly. This definitely needs motivating text, and I suspect it's > actually wrong. That is possible because of the way ALPN works; it seems that 443 is the = best choice for actually getting connectivity. > I am similarly perplexed by the hard-coded =E2=80=9Cmust do ALPN = *unless* the > designated port takes the magical value 5684=E2=80=9D behavior. I = don=E2=80=99t think > I=E2=80=99ve ever seen a protocol that has such variation based on a = hard-coded > port number, and it seems unlikely to be deployed correctly (I=E2=80=99m= imaging > the frustration of: =E2=80=9CI changed both the server and the client > configuration from the default port of 5684 to 49152, and it just = stopped > working. Like, literally the *only* way it works is on port 5684. I've > checked firewall settings everywhere and don't see any special = handling > for that port -- I just can't figure this out, and it's driving me > crazy.=E2=80=9D). Given the nearly universal availability of ALPN in = pretty much > all modern TLS libraries, it seems much cleaner to just require ALPN > support and call it done. Or *don=E2=80=99t* require ALPN at all and = call it > done. But *changing* protocol behavior based on magic port numbers = seems > like it=E2=80=99s going to cause a lot of operational heartburn. Interesting scenario. The current rules are an attempt to use ALPN as it is the future, but = also allow environments (which were specifically cited, but I forget = which ones they were) without ALPN to play. I think that objective is = worth some complexity, but I=E2=80=99ve opened an issue to discuss this = nonetheless. Now https://github.com/core-wg/coap-tcp-tls/issues/155 > The final paragraph of section 8.1 is very confusing, making it = somewhat > unclear which of the three modes must be implemented on a CoAP client, The entirety of CoAP over TCP is optional for a CoAP client or server. > and which must be implemented on a CoAP server. Read na=C3=AFvely, = this sounds > like clients are required to do only one (but one of their choosing) = of > these three, while servers are required to also do only one (again, of > their choosing). Generally, this is determined by what kind of security workflows are = used; writing down a preference here will have little impact. EKR has pointed out that we need to make explicit that we want to = deviate from the TLS 1.2 MTI for constrained-to-cloud, so some changes = will be required here. See also = https://github.com/core-wg/coap-tcp-tls/issues/145 > It seems that the chance of finding devices that could > interoperate under such circumstances is going to be relatively low: = to > work together, you would have to find a client and a server that = happened > to make the same implementation choice among these three. What I=E2=80=99= m used > to in these kinds of cases is: (a) server must implement all, client = can > choose to implement only one (or more), (b) client must implement all, > server can choose to implement only one (or more), or (c) client and > server must implement a specifically named lowest-common denominator, = and > can negotiate up from there. Pretty much anything else (aside from > strange =E2=80=9Ceveryone must implement two of three=E2=80=9D = schemes) will end up with > interop issues. The server and client roles are not really defined very well here, as = either side can use a connection either way once it has been set up. My advice would be: If you want interoperability, use CoAP over UDP with = the security model that you have a security workflow for. If there are operational restrictions making this impossible, respond to = those operational restrictions. > Although the document clearly expects the use of gateways and proxies > between these connection-oriented usages of CoAP and UDP-based CoAP, > Appendix A seems to omit discussion or consideration of how this > gatewaying can be performed. The following list of problems is > illustrative of this larger issue, but likely not exhaustive. (I'll = note > that all of these issues evaporate if you move to a simpler scheme = that > merely frames otherwise unmodified UDP CoAP messages) >=20 > Section A.1 does not indicate what gateways are supposed to do with > out-of-order notifications. The TCP side requires these to be = delivered > in-order; so, do this mean that gateways observing a gap in sequence > numbers need to quarantine the newly received message so that it can > deliver the missing one first? Or does it deliver the newly-received > message and then discard the =E2=80=9Cstale=E2=80=9D one when it = arrives? I don=E2=80=99t think > that leaving this up to implementations is particularly advisable. Yes, we had that discussion on the list. There is little point in = trying to do anything here but the latter. =20 We could state that more explicitly here, or leave that to = implementers=E2=80=99 advice documents such as draft-ietf-lwig-coap = (we=E2=80=99ll need to rework section 6 of that now anyway). > Section A.3 is a bit more worrisome. I understand the desired > optimization here, but where you reduce traffic in one direction, you = run > the risk of exploding it in the other. For example, consider a = coap+tcp > client connecting to a gateway that communicates with a CoAP-over-UDP > server. When that client wants to check the health of its = observations, > it can send a Ping and receive a Pong that confirms that they are all > alive and well. In order to be able to send a Pong that *means* =E2=80=9C= all your > observations are alive and well,=E2=80=9D the gateway has to verify = that all the > observations are alive and well. Oh. The PONG says the proxy hasn=E2=80=99t crashed, so the observations = are alive and well in the proxy. How that makes sure it gets fresh data = from the next hop (by observe, by polling) is up to the proxy. There is = no intention that a PING suddenly makes a proxy do a check, when it = otherwise has ignored its duty to check that before. > A simple implementation of a gateway > will likely check on each observed resource individually when it gets = a > Ping, and then send a Pong after it hears back about all of them. So, = as > a client, I can set up, let=E2=80=99s say, two dozen observations = through this > gateway. Then, with each Ping I send, the gateway sends two dozen = checks > towards the server. This kind of message amplification attack is an > awesome way to DoS both the gateway and the server. I believe the > document needs a treatment of how UDP/TCP gateways handle notification > health checks, along with techniques for mitigating this specific > attack. See above. We probably need to say that PINGs check the connection (and = thus the fate-sharing observation state) but are not meant to make = proxies frantically check the observation relationships to their data = sources. Now https://github.com/core-wg/coap-tcp-tls/issues/156 > Section A.4 talks about the rather different ways of dealing with > unsubscribing from a resource. Presumably, gateways that get a reset = to a > notification are expected to synthesize a new GET to deregister on = behalf > of the client? A proxy that translates from a UDP client to TCP server may want to = deregister if the client sends a Reset. Or not, of the proxy has other = clients that want this data (or if it is configured to watch that TCP = server). > Or is it okay if they just pass along the reset, In that scenario, there is no way to pass on the Reset, as there are no = resets over the TCP connection. (Well, you could close the TCP connection :-) > and > expect the server to know that it means the same thing as a > deregistration? Without explicit guidance here, I expect server and > gateway implementors to make different choices and end up with a lack = of > interop. A UDP CoAP server needs to handle resets on notifications, so it cannot = make a choice here. A TCP CoAP server never can see a reset, so it only has to handle the = explicit deregistration (or a connection teardown). The proxy can make a choice to perform explicit deregistration to a UDP = CoAP server or send a Reset on the next notification; I would generally = assume that proxies will use explicit deregistration. Food for section 6 of draft-ietf-lwig-coap, I=E2=80=99d say. >> =46rom i-d nits (this appears to be in reference to Figure 1): > ** There is 1 instance of too long lines in the document, the longest = one > being 3 characters in excess of 72. Thanks, now https://github.com/core-wg/coap-tcp-tls/issues/157 Again, thank you for this extensive review =E2=80=94 getting feedback = from someone who hasn=E2=80=99t followed the work since its start really = can open one=E2=80=99s eyes on how a document can be confusing. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 10 11:54:22 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC95129548; Wed, 10 May 2017 11:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 R-cHD8dQBlMV; Wed, 10 May 2017 11:54:18 -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 EB073126C23; Wed, 10 May 2017 11:54:17 -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 v4AIsE1l014738; Wed, 10 May 2017 20:54:14 +0200 (CEST) Received: from client-0223.vpn.uni-bremen.de (client-0223.vpn.uni-bremen.de [134.102.107.223]) (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 3wNQPy1D18zDJHs; Wed, 10 May 2017 20:54:14 +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: <9ED35E88-0B02-4B20-B7CE-A7EE07669F35@nostrum.com> Date: Wed, 10 May 2017 20:54:13 +0200 Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 516135252.862603-adec3b3438f58c159d9dfd2a8b5e3649 Content-Transfer-Encoding: quoted-printable Message-Id: <8EB0F791-8432-4C27-ACD8-244C33DBA57D@tzi.org> References: <149438322150.24264.16123907495920056718.idtracker@ietfa.amsl.com> <82019A15-D975-4D54-848E-1CB3D4C2E95C@tzi.org> <9ED35E88-0B02-4B20-B7CE-A7EE07669F35@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 18:54:20 -0000 > On May 10, 2017, at 18:56, Ben Campbell wrote: >=20 >>=20 >> On May 10, 2017, at 3:20 AM, Carsten Bormann wrote: >>=20 >> Hi Ben, >>=20 >> thank your for your review. >>=20 >> Before I start working on it in more detail, let me pick this one = DISCUSS out because I think it is the most momentous issue that needs to = be discussed: >>=20 >>> On May 10, 2017, at 04:27, Ben Campbell wrote: >>>=20 >>> 2) It seems problematic to encode the transport choice in the URI >>> scheme. >>> Section 7 says "They are hosted >>> in distinct namespaces because each URI scheme implies a distinct >>> origin >>> server." IIUC, this means any given resource can only be reached = over a >>> specific transport. That seems to break the idea of cross-transport >>> proxies >>> as discussed in section 7. >>>=20 >>> It also does not seem to fit with a primary motivation for this = draft. >>> That >>> is, one might want to use TCP because of local NAT/FW issues. But if >>> there is >>> a resource with a "coap" scheme, I cannot switch to TCP when I'm = behind >>> a >>> problematic middlebox, and have an expectation of reaching the same >>> resource. >>=20 >>=20 >> I would rephrase the issue as: >> URIs don=E2=80=99t have a good place to put in transport hints. >>=20 >> (The definition of a transport hint in a URI would be information = that lets me set up specific transports without creating a separate = resource each time the values of that transport hint differ.) >>=20 >> Note that the main use case for the document at hand is one where the = client may not be able to reach the server on the =E2=80=9Cmain=E2=80=9D = transport (CoAP over UDP), so negotiation/upgrade(*) mechanisms are not = solving the problem. >=20 > That=E2=80=99s exactly what I mean by =E2=80=9Ca primary = motivation=E2=80=9D. As defined, the name of a resource declares the = transport. So if I have a =E2=80=9Ccoap=E2=80=9D scheme resource that I = cannot reach over UDP, I cannot simply switch to TCP and reach that same = resource, even if the server supports both UDP and TCP. I suppose the = server could treat the two resources as aliases, but the client cannot = know that without some out-of-band agreement. (but see next comment) >=20 > So is it expected that people have to decide in advance which = transport will be use for any given resource? The middlebox-traversal = use case would seem to favor approaches where the client gets to decide = what transport to use on the fly. The way this is set up right now: Yes, the link tells you which = transport to use. >> The solutions that people are talking about in our domain are about = carrying transport alternatives around together. >> E.g., see draft-silverajan-core-coap-protocol-negotiation-05.txt, = which provides a way to find out about links from a set of links (the = resource directory) while specifying a transport type. [It may be = instructive to go through previous versions of this document just to see = what we also have tried to do.] >=20 > So from an admittedly very quick scan, am I correct to assume that the = directory described in that draft could be as =E2=80=9Cout-of-band=E2=80=9D= mechanism to declare resource aliases as I mentioned above? Well, you go from a directory search to a set of links, not as a way to = go from one link to another. Other sources of links (hypermedia documents) would also need to provide = alternatives whenever they are needed. > So why not use that sort of mechanism to advertise the available = transports for an authority, and at least allow the transport selection = to be completely decoupled from the scheme? We weren=E2=80=99t sure whether we wanted to support the trend =E2=80=9Cto= use this URI, you need this ancillary information=E2=80=9D. It would be nice if we could keep the URL property for our URIs. > If people really want to bind transport selection to the resource = name, then some such mechanism seems to be a requirement to make the = solution in this draft fit for purpose. But the transport-negotiation = draft is not yet adopted by CORE. Does it make sense to publish this = before that is well on it=E2=80=99s way to ready? Generally, we already know how to ship around sets of links. What the = transport-negotiation draft addresses is some additional functionality = facilitating the bundling of these links in directories. So = coap-tcp-tls will be useful today for OMA and OCF, but we=E2=80=99d like = to have the bundling available for the future. >> What we have right now in draft-ietf-core-coap-tcp-tls is what we = think is the least ugly way to solve the problem. >> The WG is well aware about its problems. >> We=E2=80=99d rather have a mechanism like transport hints, but we did = not find a solution that would not need to update the web architecture. >=20 > At least some other protocols do this with DNS NAPTR records. I = realize that may not be realistic for constrained devices (and I gather = the protocol-negotiation draft attacks that same problem.) SIP, for = example, can specify the transport with a URI parameter, which allows a = URI to either specify a transport or to be transport-independent (by = leaving off the parameter.) Adding a level of indirection is not that useful in the constrained = space =E2=80=94 URIs are better if they are ready to use (many CoAP = applications do not even use DNS). Shipping around URIs that need = additional lookup to use them is not so useful. Having a = multiple-transport URI that is compatible with (caches the same as) any = of the single-transport ones would be great. I=E2=80=99m not sure SIP = transport parameters to that. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 10 12:05:54 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952DF12EA57; Wed, 10 May 2017 12:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 bSrHVThe0rJW; Wed, 10 May 2017 12:05:50 -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 BB3821267BB; Wed, 10 May 2017 12:05:49 -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 v4AJ5kHN023943; Wed, 10 May 2017 21:05:46 +0200 (CEST) Received: from client-0223.vpn.uni-bremen.de (client-0223.vpn.uni-bremen.de [134.102.107.223]) (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 3wNQgG0dgZzDJJ6; Wed, 10 May 2017 21:05:46 +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: Wed, 10 May 2017 21:05:45 +0200 Cc: Adam Roach , core-chairs@ietf.org, The IESG , core@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org X-Mao-Original-Outgoing-Id: 516135945.116296-ac8c4aa17c23efb2fab283204d8ae9e4 Content-Transfer-Encoding: quoted-printable Message-Id: <2CD73E04-4287-45A1-A83C-CA4CD976A0B5@tzi.org> References: <149442363148.22664.577627584227036852.idtracker@ietfa.amsl.com> <799244C3-CD27-4F46-B5E3-E24457BC7F4B@tzi.org> <4DD370D3-62A2-460C-9D3F-0B96EA1A94F6@tzi.org> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?core-coap-tcp-tls-08=3A_=28with_DISCUSS=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 19:05:51 -0000 On May 10, 2017, at 18:49, Mirja K=C3=BChlewind = wrote: >=20 > You cannot use TCP without it reliability features. Having additional = reliability in the higher layer simply means the reliability is not = used. =E2=80=A6 or that the features are suddenly viewed as conveying = application (or even end-to-end) reliability. Much safer to remove them. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 10 12:38:38 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1045912EA8D; Wed, 10 May 2017 12:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 8OyW-c6WZTO3; Wed, 10 May 2017 12:38:34 -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 8B671128AB0; Wed, 10 May 2017 12:38:34 -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 v4AJcTrf020438; Wed, 10 May 2017 21:38:29 +0200 (CEST) Received: from client-0223.vpn.uni-bremen.de (client-0223.vpn.uni-bremen.de [134.102.107.223]) (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 3wNRP06wSyzDJJV; Wed, 10 May 2017 21:38:28 +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: <149438315533.29515.17605324258067615896.idtracker@ietfa.amsl.com> Date: Wed, 10 May 2017 21:38:28 +0200 Cc: The IESG , draft-ietf-core-coap-tcp-tls@ietf.org, Jaime Jimenez , core-chairs@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 516137908.321557-64a78eceacd4c699c9a6ffc5ba6a1c2b Content-Transfer-Encoding: quoted-printable Message-Id: <59D34C32-4AB4-4F42-8390-C7CA5FE92F86@tzi.org> References: <149438315533.29515.17605324258067615896.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 19:38:37 -0000 Hi Ben, now for the other parts. > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > 1) This draft removes the reliability and ordering features COAP when > used > over reliable transports, under the assumption that the transport will > provide. Yes. > But the draft also includes the assumption that COAP proxies > exist. This is not a new situation; we have had UDP-to-UDP proxies before (as = well as cross-protocol proxies). > This has the potential for creating a problem, since the transport can > only > provide guaranty reliable delivery and ordering to the next hop. Once > you > have a proxy in play, you loose that guaranty end to end. There is no guarantee in any of the transports. End-to-end semantics = require end-to-end support. > This is further complicated because this draft contemplates > cross-transport > proxies, where one side may be over WebSocket (and I assume might be > over > TCP) and the other side over UDP. If the client sends via TCP but a > proxy > changes it to UDP, the client has no way to specify the reliability > properties to be used on the UDP connection. If one imagines a client > that uses > UDP to a forward proxy, which speaks TCP to a reverse-proxy, which = then > switches back to UDP, any reliability properties specified by the = client > will get > lost. That has been true for UDP-to-UDP proxies, too. (I wrote a little bit about that in = https://mailarchive.ietf.org/arch/msg/core/Gpk8y4J78Pm7C8lKqMtxWdrzce0 = .) > Also, a proxy can potentially reorder messages, even if it uses TCP on > both > sides. If one leaves ordering to the transport, then one needs to add > rules > about proxies maintaining that order. There are no new rules here =E2=80=94 everything a UDP-to-UDP CoAP proxy = needed to do also needs to be done if one side is TCP. > 2) [=E2=80=A6] (See previous message.) >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Subtantive: >=20 > 3.2: I agree with Adam that this length scheme seems very complex for > the > return (1) This is a copy of what CoAP does for option lengths (2) The WG originally wanted to use something simpler, but got pulled = over to the current scheme by OCF. > 3.3: Since the initiator can start sending messages before receiving a > CSM > from the responder, how long should the initiator wait for a CSM = before > bailing? I don=E2=80=99t think there should be a recommendation here. I=E2=80=99d say: Wait for the CSM if you can afford it; start sending if = you can=E2=80=99t. > 3.4: Can you offer any guidance about how often to send keep-alives? I > note > that these keepalives are not necessarily bi-directional. Aren't there > some > NAT/FW cases where bi-directional traffic is needed to keep bindings > from > timing out? Reference [HomeGateway] may be useful here. Adaptive algorithms are = probably going to have the best performance here. > This and other places explicitly mention that in-flight messages may = be > lost > when the transport is closed or reset. This creates uncertainty about > whether > such messages have been processed or not. Is that really okay? It is not ideal, in particular for methods that are not idempotent = (e.g., POST). The Web has had that problem for a long time now and has evolved ways to = deal with the uncertainty. But it does require attention from application programmers. > 4: After the discussion resulting from Mark's Art-Art review, I = expected > to > see more emphasis about WebSocket being intended for browser-based > clients. > There's a couple of in-passing mentions of browser-clients buried in > the > text; I would have expected something more up front. The introduction currently motivates the WebSockets part with: CoAP applications running inside a web browser without access to connectivity other than HTTP and the WebSocket protocol [RFC6455] may cross-proxy their CoAP requests via HTTP to a HTTP-to-CoAP cross- proxy or transport them via the the WebSocket protocol, which provides two-way communication between a WebSocket client and a WebSocket server after upgrading an HTTP/1.1 [RFC7230] connection. How could we emphasize browsers even more? > 4.2: Is it really worth making the framing code behave differently for > WebSocket than for TCP? WebSockets already has framing, which we use (and thus do not populate = the length field). TCP (TLS) doesn=E2=80=99t, so we do need the length. =20 Since the implementations are likely to be completely different anyway, = I don=E2=80=99t see a big problem in that minor difference. >=20 > 5.3: Do I understand correctly that once an option is established, it > cannot > be removed unless replaced? (Short of tearing down the connection and > starting over, anyway.) Some CSM capability indicating options are that way, yes (e.g., the = Block capability). Why would such a capability go away during a connection? >=20 > 7.2: The text mentions 443 as a default port, but really seems to make > 5684 > the default. If 443 is really a default, then this needs discussion > about > why and why it's okay to squat on HTTPS. Well, 443 is the general port for ALPN. 5684 is for the case without ALPN. But see also https://github.com/core-wg/coap-tcp-tls/issues/155 >=20 > The text about whether ALPN is required is confusing. Why not just > require > ALPN and move one, rather than special casing it by port choice? = (There > seems > to be some circular logic about requiring 5685 to support clients that > don't > do ALPN, then saying clients MUST do ALPN unless they are using port > 5685.) I believe the text is consistent here. It just may be more complicated = than needed, depending on how much you believe ALPN is already = ubiquitous. See https://github.com/core-wg/coap-tcp-tls/issues/155 for = the question we have taken home as homework. >=20 > 7.3: I agree with Adam's DISCUSS comment. And even if people decide = that > the > well-known bit can be specified in CORE, I think it does future users = of > a > well-known URIs for ws a disservice to make them dig through this spec > to > find the update to 6455. It would be better to pull that into a > separate > draft. That's also a material addition post IETF last call, so we = should > consider > repeating the LC. Of course, we will follow the wisdom of the IESG of how to handle this. > 10.2: Is the registration policy "analogous to" that of [RFC7252] = S12.2, > or > "identical to" it. If the answer is not "identical", then the policy > should be detailed here. It is analogous, because the structure of the subregistry is slightly = different (additional column). We can add a sentence that the value of the additional column does not = influence the choice of the policy. > Editorial: >=20 > Figures 7 and 8: "Payload (if any)" - Can we assume that if one uses > either > extended length format, one has a payload? In practice yes, but the options could be verrrrry long. The figures try to show the similarity of the subformats, not the = differences... > 3.3: Is the guidance about what errors to return if you don't = implement > a > server any different here than for UDP? A UDP server can send a reset. The equivalent here of closing down the = TCP connection is unhealthy for the other direction, that=E2=80=99s why = it is good to have some response. >=20 > 4.3 and 4.4 seem to primarily repeat details that are the same for WS = as > for > TCP, even though the introduction to the WS part says that it won't do > that > :-) Right. Diminishing returns, though. >=20 > 5.3: "One CSM MUST be sent by both endpoints...": s/both/each Good point. >=20 > 7.6: The "updates" in this section are confusing. I understand this to > mean > that the procedures for TCP and WS are identical to those for UDP = except > for > the mentioned steps. But the language of the form of "This step from > [RFC7252] is updated to:" makes it sound like this intends to actually > change > the language in 7252 to this new language. If the latter, then that > effectively removes UDP support from 7252 as updated. OK, =E2=80=9Cupdate=E2=80=9D is not the right word them. >=20 > This could easily be fixed by changing that to something to the effect > of > "When using TCP, this step changes to =E2=80=A6" Good point. >=20 > Appendix A: Why is this an appendix? Updates to a standards track RFC > seem to > warrant a more prominent position in the draft. It was smeared all over the document, and then we collected it in an = appendix. I don=E2=80=99t think anyone would have a strong opposition against = making it a mainline section. Should we? I have collected the editorial issues into = https://github.com/core-wg/coap-tcp-tls/issues/158 (at least the ones = where I know what we need to do or what needs to be discussed). Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 10 12:46:34 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DD8128B4E; Wed, 10 May 2017 12:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 2aQ7f_eNrUKN; Wed, 10 May 2017 12:46:30 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9A5B3128AB0; Wed, 10 May 2017 12:46:30 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4AJkT3f012185 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 May 2017 14:46:29 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Carsten Bormann Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org References: <149430548476.30014.11810513211435340238.idtracker@ietfa.amsl.com> <7ABC8B29-825A-4FC4-9DF3-7BA877A4561F@tzi.org> From: Adam Roach Message-ID: <5fbbdd78-ba18-cf98-31c9-44ead6c1e677@nostrum.com> Date: Wed, 10 May 2017 14:46:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <7ABC8B29-825A-4FC4-9DF3-7BA877A4561F@tzi.org> Content-Type: multipart/alternative; boundary="------------E04802356DA375E165AD57E7" Content-Language: en-US Archived-At: Subject: [core] Deprecating ports 0-442, 444-65535 (was Re: Adam Roach's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 19:46:32 -0000 This is a multi-part message in MIME format. --------------E04802356DA375E165AD57E7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I'm starting a new thread on this one issue in particular because it has much larger architectural implications for the future of the Internet at large. On 5/10/17 13:31, Carsten Bormann wrote: >> I find the unmotivated definition of the default port for 鈥渃oaps+tcp鈥 to >> 443 鈥 a port that is already assigned to https 鈥 to be surprising, to put >> it mildly. This definitely needs motivating text, and I suspect it's >> actually wrong. > That is possible because of the way ALPN works; it seems that 443 is the best choice for actually getting connectivity. > I understand that it's *possible*, but that hardly seems to make it *advisable*. At the moment, the primary component in the design of most of our layer 4 protocols -- including TCP -- for distinguishing among different services is the port number. The way ALPN is currently used is for distinguishing among protocols on a single port that fundamentally accomplish the same thing. Users of "https" URLs use it to switch among HTTP, SPDY, and H2. Users of "stun" URLs use it to switch between relay server functionality and NAT discovery functionality. Users of WebRTC datachannels use it to differentiate between confidential and non-confidential media. All of those are basically using variations of the same protocol on a single port. You're proposing a fairly large departure from that, in that CoAP -- while inspired by HTTP and its relatives -- is really a different thing than what port 443 is assigned for, and the argument being offered is that port 443 tends to work through firewalls better than other ports. Allowing a default port of 443 for coaps+tcp would mark the moment where we first assigned overlapping default ports to different protocols for the purposes of circumventing firewall policies that -- through intention or misconfiguration -- prevent the use of a unique assigned port. Taken to its logical end, all future TLS-using protocols could equally claim a default port of 443 on the basis that: 1. It works through firewalls better, and 2. ALPN makes it possible This list seems to be a complete accounting of your rationale for using a default port 443 for CoAP; correct me if I'm wrong. If we're going to take the first steps down this path, I want them to be made deliberately and after due consideration of the consequences. If we decide that we really need to evaluate such an approach, I have a number of concrete, severely detrimental real-world consequences that would ensue from allowing the generalized assignment of port 443 to non-HTTPS protocols. I'm not raising them here because I think enough people will find the decision to move differentiation among unrelated protocols from port numbers to ALPN IDs sufficiently architecturally distasteful that debating the specific consequences will be unnecessary. /a --------------E04802356DA375E165AD57E7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I'm starting a new thread on this one issue in particular because it has much larger architectural implications for the future of the Internet at large.


On 5/10/17 13:31, Carsten Bormann wrote:
I find the unmotivated definition of the default port for 鈥渃oaps+tcp鈥 to
443 鈥 a port that is already assigned to https 鈥 to be surprising, to put
it mildly. This definitely needs motivating text, and I suspect it's
actually wrong.

That is possible because of the way ALPN works; it seems that 443 is the best choice for actually getting connectivity.


I understand that it's *possible*, but that hardly seems to make it *advisable*.

At the moment, the primary component in the design of most of our layer 4 protocols -- including TCP -- for distinguishing among different services is the port number. The way ALPN is currently used is for distinguishing among protocols on a single port that fundamentally accomplish the same thing. Users of "https" URLs use it to switch among HTTP, SPDY, and H2. Users of "stun" URLs use it to switch between relay server functionality and NAT discovery functionality. Users of WebRTC datachannels use it to differentiate between confidential and non-confidential media.

All of those are basically using variations of the same protocol on a single port.

You're proposing a fairly large departure from that, in that CoAP -- while inspired by HTTP and its relatives -- is really a different thing than what port 443 is assigned for, and the argument being offered is that port 443 tends to work through firewalls better than other ports. Allowing a default port of 443 for coaps+tcp would mark the moment where we first assigned overlapping default ports to different protocols for the purposes of circumventing firewall policies that -- through intention or misconfiguration -- prevent the use of a unique assigned port. Taken to its logical end, all future TLS-using protocols could equally claim a default port of 443 on the basis that:

  1. It works through firewalls better, and
  2. ALPN makes it possible

This list seems to be a complete accounting of your rationale for using a default port 443 for CoAP; correct me if I'm wrong.

If we're going to take the first steps down this path, I want them to be made deliberately and after due consideration of the consequences. If we decide that we really need to evaluate such an approach, I have a number of concrete, severely detrimental real-world consequences that would ensue from allowing the generalized assignment of port 443 to non-HTTPS protocols. I'm not raising them here because I think enough people will find the decision to move differentiation among unrelated protocols from port numbers to ALPN IDs sufficiently architecturally distasteful that debating the specific consequences will be unnecessary.

/a

--------------E04802356DA375E165AD57E7-- From nobody Wed May 10 13:16:42 2017 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83281129423; Wed, 10 May 2017 13:16:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-core-coap-tcp-tls@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149444740052.16728.2139093383077364684.idtracker@ietfa.amsl.com> Date: Wed, 10 May 2017 13:16:40 -0700 Archived-At: Subject: [core] Adam Roach's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 20:16:40 -0000 Adam Roach has entered the following ballot position for draft-ietf-core-coap-tcp-tls-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ISSUE 1: WebSockets and .well-known - Part of the document is outside the scope of the charter of the WG which requested its publication While I understand that this document requires a WebSockets mechanism for .well-known, and that such a mechanism doesn鈥檛 yet exist, it seems pretty far out of scope for the CORE working group to take on defining this itself (unless I missed something in its charter, which is entirely possible: it鈥檚 quite long). Specifically, I fear that this venue is unlikely to bring such a change to the attention of those people best positioned to comment on whether .well-known is appropriate for WebSockets. Even if this is in scope for CORE, it really needs to be its own document. If some future document comes along at a later point and wants to make use of its own .well-known path with WebSockets, it would be really quite strange to require it to reference this document in describing .well-known for WS. ================================================== ISSUE 2: Assignment of port 443 as default - Widespread deployment would be damaging to the Internet or an enterprise network for reasons of congestion control, scalability, or the like. I'd like to thank the authors for helping me to understand the intention with the use of port 443 more clearly. Based on their clarifications, I need to move my issue about assigning a default of port 443 to coaps+tcp from my Comment into the Discuss, as it does have implications for the Internet at large that will have long-term damaging effects. The rationale being offered for the using the already-assigned port 443 as a default is that it tends to go through firewalls that other ports may not, and that doing so is fine because ALPN makes it possible. These arguments, if we accept them, are manifestly true for all future TLS-using protocols. Allowing CoAP to re-use an assigned port on this basis established precedent for pretty much all future protocols to do so, effectively moving the protocol demux point for future protocols from port numbers to ALPN IDs (all over port 443). It is hard to imagine an outcome *other* *than* firewall manufacturers starting to whitelist desired ALPN IDs, which effectively ossifies the available set of IDs to whatever is defined at that moment, destroying the future utility of the mechanism. There are other issues having to do with software architecture, protocol demultiplexing in user space rather than kernel space, and operational considerations that come into play as well, but they don't technically fall under discuss criteria. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- General 鈥 this is a very bespoke approach to what could have been mostly solved with a single four-byte 鈥渓ength鈥 header; it is complicated on the wire, and in implementation; and the format variations among CoAP over UDP, coap+tls, and coap+ws are going to make gateways much harder to implement and less efficient (as they will necessarily have to disassemble messages and rebuild them to change between formats). The protocol itself mentions gateways in several places, but does not discuss how they are expected to map among the various flavors of CoAP defined in this document. Some of the changes seem unnecessary, but it could be that I鈥檓 missing the motivation for them. Ideally, the introduction would work harder at explaining why CoAP over these transports is as different from CoAP over UDP as it is, focusing in particular on why the complexity of having three syntactically incompatible headers is justified by the benefits provided by such variations. Additionally, it鈥檚 not clear from the introduction what the motivation for using the mechanisms in this document is as compared to the techniques described in section 10 (and its subsections) of RFC 7252. With the exception of subscribing to resource state (which could be added), it seems that such an approach is significantly easier to implement and more clearly defined than what is in this document; and it appears to provide the combined benefits of all four transports discussed in this document. My concern here is that an explosion of transport options makes it less likely that a client and server can find two in common: the limit of the probability of two implementations having a transport in common as the number of transports approaches infinity is zero. Due to this likely decrease in interoperability, I鈥檇 expect to see some pretty powerful motivation in here for defining a third, fourth, fifth, and sixth way to carry CoAP when only TCP is available (I count RFC 7252 http and https as the first and second ways in this accounting). I鈥檓 also a bit puzzled that CoAP already has an inherent mechanism for blocking messages off into chunks, which this document circumvents for TCP connections (by allowing Max-Message-Size to be increased), and then is forced to offer remedies for the resultant head-of-line blocking issues. If you didn鈥檛 introduce this feature, messages with a two-byte token add six bytes of overhead for every 1024 bytes of content 鈥 less than 0.6% size inflation. It seems like a lot of complicated machinery 鈥 which has a built-in foot-gun that you have to warn people about misusing 鈥 for a very tiny gain. I know it鈥檚 relatively late in the process, but if these trade-offs haven't had a lot of discussion yet, it鈥檚 probably worth at least giving them some additional thought. I鈥檒l note that the entire BERT mechanism seems to fall into the same trap of adding extra complexity for virtually nonexistent savings. CoAP headers are, by design, tiny. It seems like a serious over-optimization to try to eliminate them in this fashion. In particular, you鈥檙e making the actual implementation code larger to save a trivial number of bits on the wire; I was under the impression that many of the implementation environments CoAP is intended for had some serious on-chip restrictions that would point away from this kind of additional complexity. Specific comments follow. Section 3.3, paragraph 3 says that an initiator may send messages prior to receiving the remote side鈥檚 CSM, even though the message may be larger than would be allowed by that CSM. What should the recipient of an oversized message do in this case? In fact, I don鈥檛 see in here what a recipient of a message larger than it allowed for in its CSM is supposed to do in response at *any* stage of the connection. Is it an error? If so, how do you indicate it? Or is the Max-Message-Size option just a suggestion for the other side? This definitely needs clarification. (Aside 鈥 it seems odd and somewhat backwards that TCP connections are provided an affordance for fine-grained control over message sizes, while UDP communications are not.) Section 4.4 has a prohibition against using WebSockets keepalives in favor of using CoAP ping/pong. Section 3.4 has no similar prohibition against TCP keepalives, while the rationale would seem to be identical. Is this asymmetry intentional? (I鈥檒l also note that the presence of keepalive mechanisms in both TCP and WebSockets would seem to make the addition of new CoAP primitives for the same purpose unnecessary, but I suspect this has already been debated). Section 5 and its subsections define a new set of message types, presumably for use only on connection-oriented protocols, although this is only implied, and never stated. For example, some implementors may see CSM, Ping, and Pong as potentially useful in UDP; and, finding no prohibition in this document against using them, decide to give it a go. Is that intended? If not, I strongly suggest an explicit prohibition against using these in UDP contexts. Section 5.3.2 says that implementations supporting block-wise transfers SHOULD indicate the Block-wise Transfer Option. I can't figure out why this is anything other than a "MUST". It seems odd that this document would define a way to communicate this, and then choose to leave the communicated options as 鈥淵ES鈥 and 鈥淵OUR GUESS IS AS GOOD AS MINE鈥 rather than the simpler and more useful 鈥淵ES鈥 and 鈥淣O鈥. I find the described operation of the Custody Option in the operation of Ping and Pong to be somewhat problematic: it allows the Pong sender to unilaterally decide to set the Custody Option, and consequently quarantine the Pong for an arbitrary amount of time while it processes other operations. This seems impossible to distinguish from a failure-due-to-timeout from the perspective of the Ping sender. Why not limit this behavior only to Ping messages that include the Custody Option? [Moved from Comment to Discuss: I find the unmotivated definition of the default port for 鈥渃oaps+tcp鈥 to 443 鈥 a port that is already assigned to https 鈥 to be surprising, to put it mildly. This definitely needs motivating text, and I suspect it's actually wrong.] I am similarly perplexed by the hard-coded 鈥渕ust do ALPN *unless* the designated port takes the magical value 5684鈥 behavior. I don鈥檛 think I鈥檝e ever seen a protocol that has such variation based on a hard-coded port number, and it seems unlikely to be deployed correctly (I鈥檓 imaging the frustration of: 鈥淚 changed both the server and the client configuration from the default port of 5684 to 49152, and it just stopped working. Like, literally the *only* way it works is on port 5684. I've checked firewall settings everywhere and don't see any special handling for that port -- I just can't figure this out, and it's driving me crazy.鈥). Given the nearly universal availability of ALPN in pretty much all modern TLS libraries, it seems much cleaner to just require ALPN support and call it done. Or *don鈥檛* require ALPN at all and call it done. But *changing* protocol behavior based on magic port numbers seems like it鈥檚 going to cause a lot of operational heartburn. The final paragraph of section 8.1 is very confusing, making it somewhat unclear which of the three modes must be implemented on a CoAP client, and which must be implemented on a CoAP server. Read na茂vely, this sounds like clients are required to do only one (but one of their choosing) of these three, while servers are required to also do only one (again, of their choosing). It seems that the chance of finding devices that could interoperate under such circumstances is going to be relatively low: to work together, you would have to find a client and a server that happened to make the same implementation choice among these three. What I鈥檓 used to in these kinds of cases is: (a) server must implement all, client can choose to implement only one (or more), (b) client must implement all, server can choose to implement only one (or more), or (c) client and server must implement a specifically named lowest-common denominator, and can negotiate up from there. Pretty much anything else (aside from strange 鈥渆veryone must implement two of three鈥 schemes) will end up with interop issues. Although the document clearly expects the use of gateways and proxies between these connection-oriented usages of CoAP and UDP-based CoAP, Appendix A seems to omit discussion or consideration of how this gatewaying can be performed. The following list of problems is illustrative of this larger issue, but likely not exhaustive. (I'll note that all of these issues evaporate if you move to a simpler scheme that merely frames otherwise unmodified UDP CoAP messages) Section A.1 does not indicate what gateways are supposed to do with out-of-order notifications. The TCP side requires these to be delivered in-order; so, do this mean that gateways observing a gap in sequence numbers need to quarantine the newly received message so that it can deliver the missing one first? Or does it deliver the newly-received message and then discard the 鈥渟tale鈥 one when it arrives? I don鈥檛 think that leaving this up to implementations is particularly advisable. Section A.3 is a bit more worrisome. I understand the desired optimization here, but where you reduce traffic in one direction, you run the risk of exploding it in the other. For example, consider a coap+tcp client connecting to a gateway that communicates with a CoAP-over-UDP server. When that client wants to check the health of its observations, it can send a Ping and receive a Pong that confirms that they are all alive and well. In order to be able to send a Pong that *means* 鈥渁ll your observations are alive and well,鈥 the gateway has to verify that all the observations are alive and well. A simple implementation of a gateway will likely check on each observed resource individually when it gets a Ping, and then send a Pong after it hears back about all of them. So, as a client, I can set up, let鈥檚 say, two dozen observations through this gateway. Then, with each Ping I send, the gateway sends two dozen checks towards the server. This kind of message amplification attack is an awesome way to DoS both the gateway and the server. I believe the document needs a treatment of how UDP/TCP gateways handle notification health checks, along with techniques for mitigating this specific attack. Section A.4 talks about the rather different ways of dealing with unsubscribing from a resource. Presumably, gateways that get a reset to a notification are expected to synthesize a new GET to deregister on behalf of the client? Or is it okay if they just pass along the reset, and expect the server to know that it means the same thing as a deregistration? Without explicit guidance here, I expect server and gateway implementors to make different choices and end up with a lack of interop. >From i-d nits (this appears to be in reference to Figure 1): ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. From nobody Wed May 10 15:22:50 2017 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E15F129B6D; Wed, 10 May 2017 15:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 BF9_cCR1440D; Wed, 10 May 2017 15:22:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 B9C81129A99; Wed, 10 May 2017 15:22:26 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4AMMPde028250 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 May 2017 17:22:25 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Carsten Bormann Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org References: <149430548476.30014.11810513211435340238.idtracker@ietfa.amsl.com> <7ABC8B29-825A-4FC4-9DF3-7BA877A4561F@tzi.org> From: Adam Roach Message-ID: Date: Wed, 10 May 2017 17:22:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <7ABC8B29-825A-4FC4-9DF3-7BA877A4561F@tzi.org> Content-Type: multipart/alternative; boundary="------------F5959672A15014330D27AA01" Content-Language: en-US Archived-At: Subject: Re: [core] Adam Roach's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 22:22:48 -0000 This is a multi-part message in MIME format. --------------F5959672A15014330D27AA01 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/10/17 13:31, Carsten Bormann wrote: > Hi Adam, > > thank you for your extensive review. > > Alexey has addressed your procedural DISCUSS, and I don鈥檛 have anything to add there. > > I will try to make one quick round through the COMMENTs. > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> General 鈥 this is a very bespoke approach to what could have been mostly >> solved with a single four-byte 鈥渓ength鈥 header; it is complicated on the >> wire, and in implementation; and the format variations among CoAP over >> UDP, coap+tls, and coap+ws are going to make gateways much harder to >> implement and less efficient (as they will necessarily have to >> disassemble messages and rebuild them to change between formats). The >> protocol itself mentions gateways in several places, but does not discuss >> how they are expected to map among the various flavors of CoAP defined in >> this document. Some of the changes seem unnecessary, but it could be that >> I鈥檓 missing the motivation for them. Ideally, the introduction would work >> harder at explaining why CoAP over these transports is as different from >> CoAP over UDP as it is, focusing in particular on why the complexity of >> having three syntactically incompatible headers is justified by the >> benefits provided by such variations. > I think I addressed this one in the comments to Mirja. > > I鈥檓 still amazed how the arrangement of the first few bytes of the header can cause so much interest. It's not so much the specific arrangement itself as much as the creation of three mutually incompatible versions of the arrangement that is causing me heartburn. I'd be much happier with something baroque like little-endian byte packing than with so many variations on a theme. I'm seeing that some implementations will have to have three different parsers (or equivalent complexity in terms of alternate code paths) and three different serializers if they're going to implement all three variations. That is very unfriendly to developers and testers alike. >> Additionally, it鈥檚 not clear from the introduction what the motivation >> for using the mechanisms in this document is as compared to the >> techniques described in section 10 (and its subsections) of RFC 7252. > I read this as 鈥渨hy don鈥檛 you use HTTP when you need TCP鈥? > CoAP over TCP is more complex than CoAP over UDP, but still much less complex than either one of the HTTPs. I really hope this doesn't come across as snarky, as such is really not my intention, but that explanation thoroughly falls apart when I get to section 4. >> With the exception of subscribing to resource state (which could be >> added), > A very big exception 鈥 the observe option is fundamental to many interactions with Things, and we currently don鈥檛 have a way to map this on HTTP. I would suggest becoming familiar with RFC8030. > >> it seems that such an approach is significantly easier to >> implement and more clearly defined than what is in this document; and it >> appears to provide the combined benefits of all four transports discussed >> in this document. My concern here is that an explosion of transport >> options makes it less likely that a client and server can find two in >> common: the limit of the probability of two implementations having a >> transport in common as the number of transports approaches infinity is >> zero. Due to this likely decrease in interoperability, I鈥檇 expect to see >> some pretty powerful motivation in here for defining a third, fourth, >> fifth, and sixth way to carry CoAP when only TCP is available (I count >> RFC 7252 http and https as the first and second ways in this >> accounting). > These motivations are in the draft. To be clear: I think it needs to clearly say "we are making interop less likely, and find these benefits to be sufficiently compelling to justify doing so." I suspect that, phrased that way, the current justification won't hold up to your own scrutiny, at least not without being made substantially more convincing. >> I鈥檓 also a bit puzzled that CoAP already has an inherent mechanism for >> blocking messages off into chunks, which this document circumvents for >> TCP connections (by allowing Max-Message-Size to be increased), and then >> is forced to offer remedies for the resultant head-of-line blocking >> issues. If you didn鈥檛 introduce this feature, messages with a two-byte >> token add six bytes of overhead for every 1024 bytes of content 鈥 less >> than 0.6% size inflation. It seems like a lot of complicated machinery 鈥 >> which has a built-in foot-gun that you have to warn people about misusing >> 鈥 for a very tiny gain. I know it鈥檚 relatively late in the process, but >> if these trade-offs haven't had a lot of discussion yet, it鈥檚 probably >> worth at least giving them some additional thought. > There are indeed different ways of handling large bodies (which occur as payload mainly as an exception in our use cases). > The current set of features was defined after OCF complained that the lock-step nature of the block protocol slowed down their firmware transfers too much; this was easy to fix my making the message size more flexible. Ah, so the current block transfer mode is like of like TFTP in that it has a window size of 1? I didn't realize that. In that context, the current design makes a bit more sense. Perhaps an explanation closer to the fron that ties Max-Message-Size, block transfer, and the BERT mechanism together would be useful. [snip] >> Specific comments follow. >> >> Section 3.3, paragraph 3 says that an initiator may send messages prior >> to receiving the remote side鈥檚 CSM, even though the message may be larger >> than would be allowed by that CSM. What should the recipient of an >> oversized message do in this case? In fact, I don鈥檛 see in here what a >> recipient of a message larger than it allowed for in its CSM is supposed >> to do in response at *any* stage of the connection. Is it an error? If >> so, how do you indicate it? Or is the Max-Message-Size option just a >> suggestion for the other side? This definitely needs clarification. > Given the introduction of Max-Message-Size, there was some speculation that it would be good to allow going below the default CoAP value of 1152. Including the rationale in the document would be good. > In UDP CoAP, preferences of this kind are indicated in the 鈥渃ontrol usage鈥 of the Block options, and there is an assumption that violating them will lead to suboptimal performance, not to malfunction. But we never really thought that the possibility of reducing Max-Message-Size below 1152 would motivate making the state machine more complex; maybe we should state the obvious and add the warning that indicating a smaller Max-Message-Size is no protection against receiving a message that was sent off before that new value was known to the peer. Yes. I guarantee that the current phrasing will make some implementors want to treat messages larger than their advertised Max-Message-Size as an error. If it is supposed to be not an error, you need explicit language that it is not an error. >> (Aside 鈥 it seems odd and somewhat backwards that TCP connections are >> provided an affordance for fine-grained control over message sizes, while >> UDP communications are not.) > Connections provide a context for performing this control; for transports that don鈥檛 have connections, it is less clear what the control state should be attached to. (Certainly not four-tuples.) So far, we have handled DTLS like UDP; theoretically, we could use CSM-style messages in DTLS, but that hasn鈥檛 been explored yet (and so far I鈥檓 not aware of interest in changing CoAP over DTLS to make use of this theoretical possibility). The "block transfer window size is one" clarification nullifies this observation. >> Section 4.4 has a prohibition against using WebSockets keepalives in >> favor of using CoAP ping/pong. Section 3.4 has no similar prohibition >> against TCP keepalives, while the rationale would seem to be identical. >> Is this asymmetry intentional? > Successful TCP keepalives are usually not visible to the application, so they are not quite in the same league as CoAP PING/PONG or WebSocket mechanism. This is a SHOULD NOT because there may be reasons why the WebSocket mechanism might be the one to use; the CoAP-level PING/PONG are closer to the application and provide some CoAP-specific functionality (such as Custody). You seem to have answered some inverse of what I was asking, so I'll try to be clearer: should section 3.4 say "SHOULD NOT use TCP keepalives"? [snip] > >> I find the described operation of the Custody Option in the operation of >> Ping and Pong to be somewhat problematic: it allows the Pong sender to >> unilaterally decide to set the Custody Option, and consequently >> quarantine the Pong for an arbitrary amount of time while it processes >> other operations. > Oh. The intention was that the PINGer gives permission to delay with the Custody option. > I now realize that the text isn鈥檛 clear about that. > > s/Unless there is an > option with delaying semantics/Unless the PING carries an > option with delaying semantics/ > > Now https://github.com/core-wg/coap-tcp-tls/issues/154 That fixes part of the problem. 5.4.1 also says "When responding to a Ping message, the receiver can include an elective Custody Option in the Pong message," making it again sound like it's the entity sending the Pong making the decision. And then I can't read the second paragraph of section 5.4.1 in any way other than "in addition to the (clearly unilateral) decision to include a Custody Option in a Pong, the sender of the Ping can request that this happen by including one in the Ping." I think most of the text in 5.4.1 needs to be rewritten to make it clear -- and I do suggest normative language here -- that a Ping MAY include a Custody Option, and a Pong MUST NOT include a Custody Option unless the corresponding Ping also contained one. > (Or a similar future option.) Yes. Or a similar future option. >> I am similarly perplexed by the hard-coded 鈥渕ust do ALPN *unless* the >> designated port takes the magical value 5684鈥 behavior. I don鈥檛 think >> I鈥檝e ever seen a protocol that has such variation based on a hard-coded >> port number, and it seems unlikely to be deployed correctly (I鈥檓 imaging >> the frustration of: 鈥淚 changed both the server and the client >> configuration from the default port of 5684 to 49152, and it just stopped >> working. Like, literally the *only* way it works is on port 5684. I've >> checked firewall settings everywhere and don't see any special handling >> for that port -- I just can't figure this out, and it's driving me >> crazy.鈥). Given the nearly universal availability of ALPN in pretty much >> all modern TLS libraries, it seems much cleaner to just require ALPN >> support and call it done. Or *don鈥檛* require ALPN at all and call it >> done. But *changing* protocol behavior based on magic port numbers seems >> like it鈥檚 going to cause a lot of operational heartburn. > Interesting scenario. > > The current rules are an attempt to use ALPN as it is the future, but also allow environments (which were specifically cited, Not in this document, as far as I can tell. Including design rationale for non-obvious choices is generally a Good Thing.... > but I forget which ones they were) ...and that's why. > without ALPN to play. I think that objective is worth some complexity, but I鈥檝e opened an issue to discuss this nonetheless. > > Now https://github.com/core-wg/coap-tcp-tls/issues/155 I think this conversation will be very difficult to properly reason about unless someone can unearth the rationale that you describe above. >> The final paragraph of section 8.1 is very confusing, making it somewhat >> unclear which of the three modes must be implemented on a CoAP client, > The entirety of CoAP over TCP is optional for a CoAP client or server. s/CoAP client/coaps+tls client/ -- sorry for the imprecision, as I thought this would be obvious from context. >> and which must be implemented on a CoAP server. Read na茂vely, this sounds >> like clients are required to do only one (but one of their choosing) of >> these three, while servers are required to also do only one (again, of >> their choosing). > Generally, this is determined by what kind of security workflows are used; writing down a preference here will have little impact. This again points towards something about CoAP that's giving me a vague sense of unease about the whole ecosystem as designed. Right now, you have the mutually incompatible options of: 1. COAP/UDP 2. COAP/DLTS/UDP 3. COAP mapped to HTTP per RFC 7252 4. COAP mapped to HTTPS per RFC 7252 5. COAP/TCP 6. COAP/TLS/TCP with PSK 7. COAP/TLS/TCP with Raw Public Key 8. COAP/TLS/TCP with Certs 9. COAP/WS/HTTP 10. COAP/WS/HTTPS It might be worse than this, as I suspect that your handling of DTLS probably parallels your handling of TLS. And these are all *configuration* options, not negotiated options. It's made worse by the fact that you're defining the resource spaces for many of these to be different from the others, so you can't just switch among them to find one you have in common: if something is available via coaps+tcp, then there's no mechanical way to determine whether it's also available over coaps (on UDP), so even an assertion that UDP is MTI doesn't make things work. I think Hannes' response is very telling, so I'll quote it here: > We care only about CoAP over TLS. We are not going to use the WebSockets > part of the document. In practice for many companies there will not be a > problem with too many transports since they will only use specific ones > in their deployment. Basically what I'm hearing is that each deployment will have to pick one of these mutually incompatible (and increasingly unrelated) flavors of COAP. At some point, this becomes indistinguishable from each installation having its own proprietary protocol in terms of the benefits derived from standardization in the first place. I'm sad that these protocols are syntactically different from each other and have different state machines, requiring multiple or unnecessarily complex libraries to implement them. I'm sad that these protocols have disjoint resource spaces, preventing automated failover among them to find one in common. I'm sad that these protocols have no in-built negotiation among themselves. I'm sad that these protocols have no MTI among the myriad of options, and particularly sad that the disjoint resource spaces will forever slam the door on fixing that flaw. And I'm sad that this list appears to be long and growing longer. Mostly, I'm sad that saying "our device uses CoAP" is becoming an increasingly meaningless statement, as you have to be very clear about which incompatible variation of CoAP it implements. > EKR has pointed out that we need to make explicit that we want to deviate from the TLS 1.2 MTI for constrained-to-cloud, so some changes will be required here. See also https://github.com/core-wg/coap-tcp-tls/issues/145 If EKR is on top of the TLS binding issue, I'm sure he is better equipped to drive it to a reasonable conclusion than I am. >> It seems that the chance of finding devices that could >> interoperate under such circumstances is going to be relatively low: to >> work together, you would have to find a client and a server that happened >> to make the same implementation choice among these three. What I鈥檓 used >> to in these kinds of cases is: (a) server must implement all, client can >> choose to implement only one (or more), (b) client must implement all, >> server can choose to implement only one (or more), or (c) client and >> server must implement a specifically named lowest-common denominator, and >> can negotiate up from there. Pretty much anything else (aside from >> strange 鈥渆veryone must implement two of three鈥 schemes) will end up with >> interop issues. > The server and client roles are not really defined very well here, as either side can use a connection either way once it has been set up. > > My advice would be: If you want interoperability, use CoAP over UDP with the security model that you have a security workflow for. > If there are operational restrictions making this impossible, respond to those operational restrictions. This seems precluded by the determination that each transport has a disjoint resource space. > >> Although the document clearly expects the use of gateways and proxies >> between these connection-oriented usages of CoAP and UDP-based CoAP, >> Appendix A seems to omit discussion or consideration of how this >> gatewaying can be performed. The following list of problems is >> illustrative of this larger issue, but likely not exhaustive. (I'll note >> that all of these issues evaporate if you move to a simpler scheme that >> merely frames otherwise unmodified UDP CoAP messages) >> >> Section A.1 does not indicate what gateways are supposed to do with >> out-of-order notifications. The TCP side requires these to be delivered >> in-order; so, do this mean that gateways observing a gap in sequence >> numbers need to quarantine the newly received message so that it can >> deliver the missing one first? Or does it deliver the newly-received >> message and then discard the 鈥渟tale鈥 one when it arrives? I don鈥檛 think >> that leaving this up to implementations is particularly advisable. > Yes, we had that discussion on the list. There is little point in trying to do anything here but the latter. > We could state that more explicitly here, or leave that to implementers鈥 advice documents such as draft-ietf-lwig-coap (we鈥檒l need to rework section 6 of that now anyway). Say that out loud, or someone will get it wrong. I mean, I outlined the two potentially sensible things. There are infinite nonsensical things. Absent guidance, people will implement out of both categories. >> Section A.3 is a bit more worrisome. I understand the desired >> optimization here, but where you reduce traffic in one direction, you run >> the risk of exploding it in the other. For example, consider a coap+tcp >> client connecting to a gateway that communicates with a CoAP-over-UDP >> server. When that client wants to check the health of its observations, >> it can send a Ping and receive a Pong that confirms that they are all >> alive and well. In order to be able to send a Pong that *means* 鈥渁ll your >> observations are alive and well,鈥 the gateway has to verify that all the >> observations are alive and well. > Oh. The PONG says the proxy hasn鈥檛 crashed, so the observations are alive and well in the proxy. That's not what this document says, and why I was careful to quote from the document above. > How that makes sure it gets fresh data from the next hop (by observe, by polling) is up to the proxy. There is no intention that a PING suddenly makes a proxy do a check, when it otherwise has ignored its duty to check that before. You are making a bunch of assumptions here that are completely undocumented. >> A simple implementation of a gateway >> will likely check on each observed resource individually when it gets a >> Ping, and then send a Pong after it hears back about all of them. So, as >> a client, I can set up, let鈥檚 say, two dozen observations through this >> gateway. Then, with each Ping I send, the gateway sends two dozen checks >> towards the server. This kind of message amplification attack is an >> awesome way to DoS both the gateway and the server. I believe the >> document needs a treatment of how UDP/TCP gateways handle notification >> health checks, along with techniques for mitigating this specific >> attack. > See above. We probably need to say that PINGs check the connection (and thus the fate-sharing observation state) but are not meant to make proxies frantically check the observation relationships to their data sources. Now https://github.com/core-wg/coap-tcp-tls/issues/156 Yes. That's the solution. I strongly suggest outlining this attack as one consequence if implementors ignore such advice. Sending checks when you get a Ping is the easiest thing to code, by far, so unless you explain that it could be potentially quite harmful, people *will* do it even if you say not to. (In fact, saying not to without being clear about *why* not could be worse than saying nothing; cf. ) > >> Section A.4 talks about the rather different ways of dealing with >> unsubscribing from a resource. Presumably, gateways that get a reset to a >> notification are expected to synthesize a new GET to deregister on behalf >> of the client? > A proxy that translates from a UDP client to TCP server may want to deregister if the client sends a Reset. Or not, of the proxy has other clients that want this data (or if it is configured to watch that TCP server). > >> Or is it okay if they just pass along the reset, > In that scenario, there is no way to pass on the Reset, as there are no resets over the TCP connection. > (Well, you could close the TCP connection :-) > >> and >> expect the server to know that it means the same thing as a >> deregistration? Without explicit guidance here, I expect server and >> gateway implementors to make different choices and end up with a lack of >> interop. > A UDP CoAP server needs to handle resets on notifications, so it cannot make a choice here. > A TCP CoAP server never can see a reset, so it only has to handle the explicit deregistration (or a connection teardown). > The proxy can make a choice to perform explicit deregistration to a UDP CoAP server or send a Reset on the next notification; I would generally assume that proxies will use explicit deregistration. > Food for section 6 of draft-ietf-lwig-coap, I鈥檇 say. Okay. [snip] /a --------------F5959672A15014330D27AA01 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/10/17 13:31, Carsten Bormann wrote:
Hi Adam,

thank you for your extensive review.

Alexey has addressed your procedural DISCUSS, and I don鈥檛 have anything to add there.

I will try to make one quick round through the COMMENTs.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

General 鈥 this is a very bespoke approach to what could have been mostly
solved with a single four-byte 鈥渓ength鈥 header; it is complicated on the
wire, and in implementation; and the format variations among CoAP over
UDP, coap+tls, and coap+ws are going to make gateways much harder to
implement and less efficient (as they will necessarily have to
disassemble messages and rebuild them to change between formats). The
protocol itself mentions gateways in several places, but does not discuss
how they are expected to map among the various flavors of CoAP defined in
this document. Some of the changes seem unnecessary, but it could be that
I鈥檓 missing the motivation for them. Ideally, the introduction would work
harder at explaining why CoAP over these transports is as different from
CoAP over UDP as it is, focusing in particular on why the complexity of
having three syntactically incompatible headers is justified by the
benefits provided by such variations.

I think I addressed this one in the comments to Mirja.

I鈥檓 still amazed how the arrangement of the first few bytes of the header can cause so much interest.

It's not so much the specific arrangement itself as much as the creation of three mutually incompatible versions of the arrangement that is causing me heartburn. I'd be much happier with something baroque like little-endian byte packing than with so many variations on a theme. I'm seeing that some implementations will have to have three different parsers (or equivalent complexity in terms of alternate code paths) and three different serializers if they're going to implement all three variations. That is very unfriendly to developers and testers alike.



      

        
Additionally, it鈥檚 not clear from the introduction what the motivation
for using the mechanisms in this document is as compared to the
techniques described in section 10 (and its subsections) of RFC 7252.


      

      
I read this as 鈥渨hy don鈥檛 you use HTTP when you need TCP鈥?
CoAP over TCP is more complex than CoAP over UDP, but still much less complex than either one of the HTTPs.

    

    

    I really hope this doesn't come across as snarky, as such is really
    not my intention, but that explanation thoroughly falls apart when I
    get to section 4.

    

    

      

      

        
With the exception of subscribing to resource state (which could be
added),


      

      
A very big exception 鈥 the observe option is fundamental to many interactions with Things, and we currently don鈥檛 have a way to map this on HTTP.

    

    

    I would suggest becoming familiar with RFC8030.

    

    

      



      

        
it seems that such an approach is significantly easier to
implement and more clearly defined than what is in this document; and it
appears to provide the combined benefits of all four transports discussed
in this document. My concern here is that an explosion of transport
options makes it less likely that a client and server can find two in
common: the limit of the probability of two implementations having a
transport in common as the number of transports approaches infinity is
zero. Due to this likely decrease in interoperability, I鈥檇 expect to see
some pretty powerful motivation in here for defining a third, fourth,
fifth, and sixth way to carry CoAP when only TCP is available (I count
RFC 7252 http and https as the first and second ways in this
accounting).


      

      
These motivations are in the draft.

    

    

    To be clear: I think it needs to clearly say "we are making interop
    less likely, and find these benefits to be sufficiently compelling
    to justify doing so." I suspect that, phrased that way, the current
    justification won't hold up to your own scrutiny, at least not
    without being made substantially more convincing.

    

    

      

      

        
I鈥檓 also a bit puzzled that CoAP already has an inherent mechanism for
blocking messages off into chunks, which this document circumvents for
TCP connections (by allowing Max-Message-Size to be increased), and then
is forced to offer remedies for the resultant head-of-line blocking
issues. If you didn鈥檛 introduce this feature, messages with a two-byte
token add six bytes of overhead for every 1024 bytes of content 鈥 less
than 0.6% size inflation. It seems like a lot of complicated machinery 鈥
which has a built-in foot-gun that you have to warn people about misusing
鈥 for a very tiny gain. I know it鈥檚 relatively late in the process, but
if these trade-offs haven't had a lot of discussion yet, it鈥檚 probably
worth at least giving them some additional thought.


      

      
There are indeed different ways of handling large bodies (which occur as payload mainly as an exception in our use cases).
The current set of features was defined after OCF complained that the lock-step nature of the block protocol slowed down their firmware transfers too much; this was easy to fix my making the message size more flexible.

    

    

    Ah, so the current block transfer mode is like of like TFTP in that
    it has a window size of 1? I didn't realize that. In that context,
    the current design makes a bit more sense. Perhaps an explanation
    closer to the fron that ties Max-Message-Size, block transfer, and
    the BERT mechanism together would be useful.

    

    [snip]

    

    

      

        
Specific comments follow.

Section 3.3, paragraph 3 says that an initiator may send messages prior
to receiving the remote side鈥檚 CSM, even though the message may be larger
than would be allowed by that CSM.  What should the recipient of an
oversized message do in this case? In fact, I don鈥檛 see in here what a
recipient of a message larger than it allowed for in its CSM is supposed
to do in response at *any* stage of the connection. Is it an error? If
so, how do you indicate it? Or is the Max-Message-Size option just a
suggestion for the other side? This definitely needs clarification.


      

      
Given the introduction of Max-Message-Size, there was some speculation that it would be good to allow going below the default CoAP value of 1152.

    

    

    Including the rationale in the document would be good.

    

    

      
In UDP CoAP, preferences of this kind are indicated in the 鈥渃ontrol usage鈥 of the Block options, and there is an assumption that violating them will lead to suboptimal performance, not to malfunction.  But we never really thought that the possibility of reducing Max-Message-Size below 1152 would motivate making the state machine more complex; maybe we should state the obvious and add the warning that indicating a smaller Max-Message-Size is no protection against receiving a message that was sent off before that new value was known to the peer.

    

    

    Yes. I guarantee that the current phrasing will make some
    implementors want to treat messages larger than their advertised
    Max-Message-Size as an error. If it is supposed to be not an error,
    you need explicit language that it is not an error.

    

    

      

      

        
(Aside 鈥 it seems odd and somewhat backwards that TCP connections are
provided an affordance for fine-grained control over message sizes, while
UDP communications are not.)


      

      
Connections provide a context for performing this control; for transports that don鈥檛 have connections, it is less clear what the control state should be attached to.  (Certainly not four-tuples.)  So far, we have handled DTLS like UDP; theoretically, we could use CSM-style messages in DTLS, but that hasn鈥檛 been explored yet (and so far I鈥檓 not aware of interest in changing CoAP over DTLS to make use of this theoretical possibility).

    

    

    The "block transfer window size is one" clarification nullifies this
    observation.

    

    

      

      

        
Section 4.4 has a prohibition against using WebSockets keepalives in
favor of using CoAP ping/pong. Section 3.4 has no similar prohibition
against TCP keepalives, while the rationale would seem to be identical.
Is this asymmetry intentional?


      

      
Successful TCP keepalives are usually not visible to the application, so they are not quite in the same league as CoAP PING/PONG or WebSocket mechanism.  This is a SHOULD NOT because there may be reasons why the WebSocket mechanism might be the one to use; the CoAP-level PING/PONG are closer to the application and provide some CoAP-specific functionality (such as Custody).

    

    

    You seem to have answered some inverse of what I was asking, so I'll
    try to be clearer: should section 3.4 say "SHOULD NOT use TCP
    keepalives"?

    

    [snip]

    

    


      

        
I find the described operation of the Custody Option in the operation of
Ping and Pong to be somewhat problematic: it allows the Pong sender to
unilaterally decide to set the Custody Option, and consequently
quarantine the Pong for an arbitrary amount of time while it processes
other operations.


      

      
Oh.  The intention was that the PINGer gives permission to delay with the Custody option.  
I now realize that the text isn鈥檛 clear about that.

s/Unless there is an
   option with delaying semantics/Unless the PING carries an
   option with delaying semantics/

Now https://github.com/core-wg/coap-tcp-tls/issues/154

    

    

    That fixes part of the problem. 5.4.1 also says "When responding to
    a Ping message, the receiver can include an elective Custody Option
    in the Pong message," making it again sound like it's the entity
    sending the Pong making the decision.

    

    And then I can't read the second paragraph of section 5.4.1 in any
    way other than "in addition to the (clearly unilateral) decision to
    include a Custody Option in a Pong, the sender of the Ping can
    request that this happen by including one in the Ping."

    

    I think most of the text in 5.4.1 needs to be rewritten to make it
    clear -- and I do suggest normative language here -- that a Ping MAY
    include a Custody Option, and a Pong MUST NOT include a Custody
    Option unless the corresponding Ping also contained one.

    

    

      
(Or a similar future option.)

    

    

    Yes. Or a similar future option.

    

    

    

      

        
I am similarly perplexed by the hard-coded 鈥渕ust do ALPN *unless* the
designated port takes the magical value 5684鈥 behavior. I don鈥檛 think
I鈥檝e ever seen a protocol that has such variation based on a hard-coded
port number, and it seems unlikely to be deployed correctly (I鈥檓 imaging
the frustration of: 鈥淚 changed both the server and the client
configuration from the default port of 5684 to 49152, and it just stopped
working. Like, literally the *only* way it works is on port 5684. I've
checked firewall settings everywhere and don't see any special handling
for that port -- I just can't figure this out, and it's driving me
crazy.鈥). Given the nearly universal availability of ALPN in pretty much
all modern TLS libraries, it seems much cleaner to just require ALPN
support and call it done. Or *don鈥檛* require ALPN at all and call it
done. But *changing* protocol behavior based on magic port numbers seems
like it鈥檚 going to cause a lot of operational heartburn.


      

      
Interesting scenario.

The current rules are an attempt to use ALPN as it is the future, but also allow environments (which were specifically cited,

    

    

    Not in this document, as far as I can tell. Including design
    rationale for non-obvious choices is generally a Good Thing....

    

    

      
but I forget which ones they were)

    

    

    ...and that's why.

    

    

      
without ALPN to play.  I think that objective is worth some complexity, but I鈥檝e opened an issue to discuss this nonetheless.

Now https://github.com/core-wg/coap-tcp-tls/issues/155

    

    

    I think this conversation will be very difficult to properly reason
    about unless someone can unearth the rationale that you describe
    above.

    

    

      

      

        
The final paragraph of section 8.1 is very confusing, making it somewhat
unclear which of the three modes must be implemented on a CoAP client,


      

      
The entirety of CoAP over TCP is optional for a CoAP client or server.

    

    

    s/CoAP client/coaps+tls client/ -- sorry for the imprecision, as I
    thought this would be obvious from context.

    

    

      

      

        
and which must be implemented on a CoAP server. Read na茂vely, this sounds
like clients are required to do only one (but one of their choosing) of
these three, while servers are required to also do only one (again, of
their choosing).


      

      
Generally, this is determined by what kind of security workflows are used; writing down a preference here will have little impact.

    

    

    This again points towards something about CoAP that's giving me a
    vague sense of unease about the whole ecosystem as designed. Right
    now, you have the mutually incompatible options of:

    

    
    
      
  1. COAP/UDP
    2. 
      
  2. COAP/DLTS/UDP
    3. 
      
  3. COAP mapped to HTTP per RFC 7252
    4. 
      
  4. COAP mapped to HTTPS per RFC 7252
    5. 
      
  5. COAP/TCP
    6. 
      
  6. COAP/TLS/TCP with PSK
    7. 
      
  7. COAP/TLS/TCP with Raw Public Key
    8. 
      
  8. COAP/TLS/TCP with Certs
    9. 
      
  9. COAP/WS/HTTP
    10. 
      
  10. COAP/WS/HTTPS
    11. 
    

    

    It might be worse than this, as I suspect that your handling of DTLS
    probably parallels your handling of TLS. And these are all
    *configuration* options, not negotiated options. It's made worse by
    the fact that you're defining the resource spaces for many of these
    to be different from the others, so you can't just switch among them
    to find one you have in common: if something is available via
    coaps+tcp, then there's no mechanical way to determine whether it's
    also available over coaps (on UDP), so even an assertion that UDP is
    MTI doesn't make things work.

    

    I think Hannes' response is very telling, so I'll quote it here:

    

    

      
We care only about CoAP over TLS. We are not going to use the WebSockets
part of the document. In practice for many companies there will not be a
problem with too many transports since they will only use specific ones
in their deployment.

    

    

    Basically what I'm hearing is that each deployment will have to pick
    one of these mutually incompatible (and increasingly unrelated)
    flavors of COAP. At some point, this becomes indistinguishable from
    each installation having its own proprietary protocol in terms of
    the benefits derived from standardization in the first place.

    

    I'm sad that these protocols are syntactically different from each
    other and have different state machines, requiring multiple or
    unnecessarily complex libraries to implement them. I'm sad that
    these protocols have disjoint resource spaces, preventing automated
    failover among them to find one in common. I'm sad that these
    protocols have no in-built negotiation among themselves. I'm sad
    that these protocols have no MTI among the myriad of options, and
    particularly sad that the disjoint resource spaces will forever slam
    the door on fixing that flaw. And I'm sad that this list appears to
    be long and growing longer.

    

    Mostly, I'm sad that saying "our device uses CoAP" is becoming an
    increasingly meaningless statement, as you have to be very clear
    about which incompatible variation of CoAP it implements.

    

    

      
EKR has pointed out that we need to make explicit that we want to deviate from the TLS 1.2 MTI for constrained-to-cloud, so some changes will be required here.  See also https://github.com/core-wg/coap-tcp-tls/issues/145

    

    

    If EKR is on top of the TLS binding issue, I'm sure he is better
    equipped to drive it to a reasonable conclusion than I am.

    

    

      

      

        
It seems that the chance of finding devices that could
interoperate under such circumstances is going to be relatively low: to
work together, you would have to find a client and a server that happened
to make the same implementation choice among these three. What I鈥檓 used
to in these kinds of cases is: (a) server must implement all, client can
choose to implement only one (or more), (b) client must implement all,
server can choose to implement only one (or more), or (c) client and
server must implement a specifically named lowest-common denominator, and
can negotiate up from there. Pretty much anything else (aside from
strange 鈥渆veryone must implement two of three鈥 schemes) will end up with
interop issues.


      

      
The server and client roles are not really defined very well here, as either side can use a connection either way once it has been set up.

My advice would be: If you want interoperability, use CoAP over UDP with the security model that you have a security workflow for.
If there are operational restrictions making this impossible, respond to those operational restrictions.

    

    

    This seems precluded by the determination that each transport has a
    disjoint resource space.

    

    


      

        
Although the document clearly expects the use of gateways and proxies
between these connection-oriented usages of CoAP and UDP-based CoAP,
Appendix A seems to omit discussion or consideration of how this
gatewaying can be performed. The following list of problems is
illustrative of this larger issue, but likely not exhaustive. (I'll note
that all of these issues evaporate if you move to a simpler scheme that
merely frames otherwise unmodified UDP CoAP messages)

Section A.1 does not indicate what gateways are supposed to do with
out-of-order notifications. The TCP side requires these to be delivered
in-order; so, do this mean that gateways observing a gap in sequence
numbers need to quarantine the newly received message so that it can
deliver the missing one first? Or does it deliver the newly-received
message and then discard the 鈥渟tale鈥 one when it arrives? I don鈥檛 think
that leaving this up to implementations is particularly advisable.


      

      
Yes, we had that discussion on the list.  There is little point in trying to do anything here but the latter.  
We could state that more explicitly here, or leave that to implementers鈥 advice documents such as draft-ietf-lwig-coap (we鈥檒l need to  rework section 6 of that now anyway).

    

    

    Say that out loud, or someone will get it wrong. I mean, I outlined
    the two potentially sensible things. There are infinite nonsensical
    things. Absent guidance, people will implement out of both
    categories.

    

    

    

      

      

        
Section A.3 is a bit more worrisome. I understand the desired
optimization here, but where you reduce traffic in one direction, you run
the risk of exploding it in the other. For example, consider a coap+tcp
client connecting to a gateway that communicates with a CoAP-over-UDP
server. When that client wants to check the health of its observations,
it can send a Ping and receive a Pong that confirms that they are all
alive and well. In order to be able to send a Pong that *means* 鈥渁ll your
observations are alive and well,鈥 the gateway has to verify that all the
observations are alive and well.


      

      
Oh.  The PONG says the proxy hasn鈥檛 crashed, so the observations are alive and well in the proxy.

    

    

    That's not what this document says, and why I was careful to quote
    from the document above.

    

    

      
  How that makes sure it gets fresh data from the next hop (by observe, by polling) is up to the proxy.  There is no intention that a PING suddenly makes a proxy do a check, when it otherwise has ignored its duty to check that before.

    

    

    You are making a bunch of assumptions here that are completely
    undocumented.

    

    

      

      

        
A simple implementation of a gateway
will likely check on each observed resource individually when it gets a
Ping, and then send a Pong after it hears back about all of them. So, as
a client, I can set up, let鈥檚 say, two dozen observations through this
gateway. Then, with each Ping I send, the gateway sends two dozen checks
towards the server. This kind of message amplification attack is an
awesome way to DoS both the gateway and the server. I believe the
document needs a treatment of how UDP/TCP gateways handle notification
health checks, along with techniques for mitigating this specific
attack.


      

      
See above.  We probably need to say that PINGs check the connection (and thus the fate-sharing observation state) but are not meant to make proxies frantically check the observation relationships to their data sources.   Now https://github.com/core-wg/coap-tcp-tls/issues/156

    

    

    Yes. That's the solution. I strongly suggest outlining this attack
    as one consequence if implementors ignore such advice. Sending
    checks when you get a Ping is the easiest thing to code, by far, so
    unless you explain that it could be potentially quite harmful,
    people *will* do it even if you say not to. (In fact, saying not to
    without being clear about *why* not could be worse than saying
    nothing; cf.
<https://en.wikipedia.org/wiki/Wikipedia:Don%27t_stuff_beans_up_your_nose>)

    

    


      

        
Section A.4 talks about the rather different ways of dealing with
unsubscribing from a resource. Presumably, gateways that get a reset to a
notification are expected to synthesize a new GET to deregister on behalf
of the client?


      

      
A proxy that translates from a UDP client to TCP server may want to deregister if the client sends a Reset.  Or not, of the proxy has other clients that want this data (or if it is configured to watch that TCP server).



      

        
Or is it okay if they just pass along the reset,


      

      
In that scenario, there is no way to pass on the Reset, as there are no resets over the TCP connection.
(Well, you could close the TCP connection :-)



      

        
and
expect the server to know that it means the same thing as a
deregistration? Without explicit guidance here, I expect server and
gateway implementors to make different choices and end up with a lack of
interop.


      

      
A UDP CoAP server needs to handle resets on notifications, so it cannot make a choice here.
A TCP CoAP server never can see a reset, so it only has to handle the explicit deregistration (or a connection teardown).
The proxy can make a choice to perform explicit deregistration to a UDP CoAP server or send a Reset on the next notification; I would generally assume that proxies will use explicit deregistration.
Food for section 6 of draft-ietf-lwig-coap, I鈥檇 say.

    

    

    Okay.

    

    [snip]

    

    /a

  


--------------F5959672A15014330D27AA01--


From nobody Wed May 10 19:01:07 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5A0129329; Wed, 10 May 2017 19:00:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level: 
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 bGAHy8Imhu7S; Wed, 10 May 2017 19:00:58 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 280CB126BF0; Wed, 10 May 2017 19:00:58 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4B20upt049204 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 May 2017 21:00:57 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell 
In-Reply-To: <8EB0F791-8432-4C27-ACD8-244C33DBA57D@tzi.org>
Date: Wed, 10 May 2017 21:00:55 -0500
Cc: core-chairs@ietf.org, The IESG , core@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6901CFC8-3C32-459F-8C29-2B23AA3DD9F0@nostrum.com>
References: <149438322150.24264.16123907495920056718.idtracker@ietfa.amsl.com> <82019A15-D975-4D54-848E-1CB3D4C2E95C@tzi.org> <9ED35E88-0B02-4B20-B7CE-A7EE07669F35@nostrum.com> <8EB0F791-8432-4C27-ACD8-244C33DBA57D@tzi.org>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 02:01:00 -0000

> On May 10, 2017, at 1:54 PM, Carsten Bormann  wrote:
>=20
>=20
>> On May 10, 2017, at 18:56, Ben Campbell  wrote:
>>=20
>>>=20
>>> On May 10, 2017, at 3:20 AM, Carsten Bormann  wrote:
>>>=20
>>> Hi Ben,
>>>=20
>>> thank your for your review.
>>>=20
>>> Before I start working on it in more detail, let me pick this one =
DISCUSS out because I think it is the most momentous issue that needs to =
be discussed:
>>>=20
>>>> On May 10, 2017, at 04:27, Ben Campbell  wrote:
>>>>=20
>>>> 2) It seems problematic to encode the transport choice in the URI
>>>> scheme.
>>>> Section 7 says "They are hosted
>>>> in distinct namespaces because each URI scheme implies a distinct
>>>> origin
>>>> server." IIUC, this means any given resource can only be reached =
over a
>>>> specific transport. That seems to break the idea of cross-transport
>>>> proxies
>>>> as discussed in section 7.
>>>>=20
>>>> It also does not seem to fit with a primary motivation for this =
draft.
>>>> That
>>>> is, one might want to use TCP because of local NAT/FW issues. But =
if
>>>> there is
>>>> a resource with a "coap" scheme, I cannot switch to TCP when I'm =
behind
>>>> a
>>>> problematic middlebox, and have an expectation of reaching the same
>>>> resource.
>>>=20
>>>=20
>>> I would rephrase the issue as:
>>> URIs don=E2=80=99t have a good place to put in transport hints.
>>>=20
>>> (The definition of a transport hint in a URI would be information =
that lets me set up specific transports without creating a separate =
resource each time the values of that transport hint differ.)
>>>=20
>>> Note that the main use case for the document at hand is one where =
the client may not be able to reach the server on the =E2=80=9Cmain=E2=80=9D=
 transport (CoAP over UDP), so negotiation/upgrade(*) mechanisms are not =
solving the problem.
>>=20
>> That=E2=80=99s exactly what I mean by =E2=80=9Ca primary =
motivation=E2=80=9D. As defined, the name of a resource declares the =
transport. So if I have a =E2=80=9Ccoap=E2=80=9D scheme resource that I =
cannot reach over UDP, I cannot simply switch to TCP and reach that same =
resource, even if the server supports both UDP and TCP. I suppose the =
server could treat the two resources as aliases, but the client cannot =
know that without some out-of-band agreement. (but see next comment)
>>=20
>> So is it expected that people have to decide in advance which =
transport will be use for any given resource? The middlebox-traversal =
use case would seem to favor approaches where the client gets to decide =
what transport to use on the fly.
>=20
> The way this is set up right now: Yes, the link tells you which =
transport to use.

I=E2=80=99m confused at how this mechanism addresses the middlebox =
problem it purports to solve. Is the server expected to know in advance =
whether all of the clients are behind UDP-eating middleboxes? What if a =
client moves back and forth from behind such a middlebox?=20

And how are the cross-transport proxies described in this draft supposed =
to work at all, if a resource can only be reached over one transport?

>=20
>>> The solutions that people are talking about in our domain are about =
carrying transport alternatives around together.
>>> E.g., see draft-silverajan-core-coap-protocol-negotiation-05.txt, =
which provides a way to find out about links from a set of links (the =
resource directory) while specifying a transport type. [It may be =
instructive to go through previous versions of this document just to see =
what we also have tried to do.]
>>=20
>> So from an admittedly very quick scan, am I correct to assume that =
the directory described in that draft could be as =E2=80=9Cout-of-band=E2=80=
=9D mechanism to declare resource aliases as I mentioned above?
>=20
> Well, you go from a directory search to a set of links, not as a way =
to go from one link to another.
> Other sources of links (hypermedia documents) would also need to =
provide alternatives whenever they are needed.

But do I understand correctly that with the transport negotiation draft, =
a server could advertise in such a directory that it was reachable over =
alternative transports? Wouldn=E2=80=99t that effectively mean that all =
of it=E2=80=99s resources are aliased for that alternative transport?


>=20
>> So why not use that sort of mechanism to advertise the available =
transports for an authority, and at least allow the transport selection =
to be completely decoupled from the scheme?
>=20
> We weren=E2=80=99t sure whether we wanted to support the trend =E2=80=9C=
to use this URI, you need this ancillary information=E2=80=9D.
> It would be nice if we could keep the URL property for our URIs.
>=20
>> If people really want to bind transport selection to the resource =
name, then some such mechanism seems to be a requirement to make the =
solution in this draft fit for purpose. But the transport-negotiation =
draft is not yet adopted by CORE. Does it make sense to publish this =
before that is well on it=E2=80=99s way to ready?
>=20
> Generally, we already know how to ship around sets of links.  What the =
transport-negotiation draft addresses is some additional functionality =
facilitating the bundling of these links in directories.  So =
coap-tcp-tls will be useful today for OMA and OCF, but we=E2=80=99d like =
to have the bundling available for the future.
>=20
>>> What we have right now in draft-ietf-core-coap-tcp-tls is what we =
think is the least ugly way to solve the problem.
>>> The WG is well aware about its problems.
>>> We=E2=80=99d rather have a mechanism like transport hints, but we =
did not find a solution that would not need to update the web =
architecture.
>>=20
>> At least some other protocols do this with DNS NAPTR records. I =
realize that may not be realistic for constrained devices (and I gather =
the protocol-negotiation draft attacks that same problem.) SIP, for =
example, can specify the transport with a URI parameter, which allows a =
URI to either specify a transport or to be transport-independent (by =
leaving off the parameter.)
>=20
> Adding a level of indirection is not that useful in the constrained =
space =E2=80=94 URIs are better if they are ready to use (many CoAP =
applications do not even use DNS).  Shipping around URIs that need =
additional lookup to use them is not so useful.  Having a =
multiple-transport URI that is compatible with (caches the same as) any =
of the single-transport ones would be great.  I=E2=80=99m not sure SIP =
transport parameters to that.

For SIP URIs, two URIs with explicit transport parameters with different =
values do not match. But a SIP URI with a transport parameter matches an =
otherwise identical one with no transport parameter.

Thanks,

Ben.


From nobody Wed May 10 19:07:20 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF767126BF0; Wed, 10 May 2017 19:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level: 
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 QDxEuxIbeto9; Wed, 10 May 2017 19:07:16 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6C10B129468; Wed, 10 May 2017 19:07:16 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4B27B2j049730 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 May 2017 21:07:11 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell 
In-Reply-To: <59D34C32-4AB4-4F42-8390-C7CA5FE92F86@tzi.org>
Date: Wed, 10 May 2017 21:07:10 -0500
Cc: Jaime Jimenez , core-chairs@ietf.org, The IESG , core@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F431FE8-DD65-4AF2-A65F-4229EC7E4EA3@nostrum.com>
References: <149438315533.29515.17605324258067615896.idtracker@ietfa.amsl.com> <59D34C32-4AB4-4F42-8390-C7CA5FE92F86@tzi.org>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 02:07:19 -0000

> On May 10, 2017, at 2:38 PM, Carsten Bormann  wrote:
>=20
> Hi Ben,
>=20
> now for the other parts.
>=20
>> =
----------------------------------------------------------------------
>> DISCUSS:
>> =
----------------------------------------------------------------------
>>=20
>> 1) This draft removes the reliability and ordering features COAP when
>> used
>> over reliable transports, under the assumption that the transport =
will
>> provide.
>=20
> Yes.
>=20
>> But the draft also includes the assumption that COAP proxies
>> exist.
>=20
> This is not a new situation; we have had UDP-to-UDP proxies before (as =
well as cross-protocol proxies).

Sure, but I guess I was more talking about proxies that translate =
between two transports, which of course could not exist until we started =
talking about additional transports.

>=20
>> This has the potential for creating a problem, since the transport =
can
>> only
>> provide guaranty reliable delivery and ordering to the next hop. Once
>> you
>> have a proxy in play, you loose that guaranty end to end.
>=20
> There is no guarantee in any of the transports.  End-to-end semantics =
require end-to-end support.



>=20
>> This is further complicated because this draft contemplates
>> cross-transport
>> proxies, where one side may be over WebSocket (and I assume might be
>> over
>> TCP) and the other side over UDP. If the client sends via TCP but a
>> proxy
>> changes it to UDP, the client has no way to specify the reliability
>> properties to be used on the UDP connection. If one imagines a client
>> that uses
>> UDP to a forward proxy, which speaks TCP to a reverse-proxy, which =
then
>> switches back to UDP, any reliability properties specified by the =
client
>> will get
>> lost.
>=20
> That has been true for UDP-to-UDP proxies, too.
> (I wrote a little bit about that in =
https://mailarchive.ietf.org/arch/msg/core/Gpk8y4J78Pm7C8lKqMtxWdrzce0 =
.)

With UDP, it was at least possible for a proxy to preserve the =
reliability type. A proxy could strip that, but it didn=E2=80=99t _have_ =
to strip that. In the scenarios I mention, it=E2=80=99s not possible for =
the proxy to preserve the reliability type, because it never sees it.=20


>=20
>=20
>> Also, a proxy can potentially reorder messages, even if it uses TCP =
on
>> both
>> sides. If one leaves ordering to the transport, then one needs to add
>> rules
>> about proxies maintaining that order.
>=20
> There are no new rules here =E2=80=94 everything a UDP-to-UDP CoAP =
proxy needed to do also needs to be done if one side is TCP.

So maybe I misunderstand something here, at least about ordering in =
COAP. Doesn=E2=80=99t COAP/UDP have an application layer =
order-preservation mechanism? Is it not at least _possible_ for a =
UDP-UDP proxy to preserve that mechanism across transport instances?

>=20
>=20
>> 2) [=E2=80=A6]
>=20
> (See previous message.)
>=20
>=20
>>=20
>> =
----------------------------------------------------------------------
>> COMMENT:
>> =
----------------------------------------------------------------------
>>=20
>> Subtantive:
>>=20
>> 3.2: I agree with Adam that this length scheme seems very complex for
>> the
>> return
>=20
> (1) This is a copy of what CoAP does for option lengths
> (2) The WG originally wanted to use something simpler, but got pulled =
over to the current scheme by OCF.
>=20
>> 3.3: Since the initiator can start sending messages before receiving =
a
>> CSM
>> from the responder, how long should the initiator wait for a CSM =
before
>> bailing?
>=20
> I don=E2=80=99t think there should be a recommendation here.
> I=E2=80=99d say: Wait for the CSM if you can afford it; start sending =
if you can=E2=80=99t.
>=20
>> 3.4: Can you offer any guidance about how often to send keep-alives? =
I
>> note
>> that these keepalives are not necessarily bi-directional. Aren't =
there
>> some
>> NAT/FW cases where bi-directional traffic is needed to keep bindings
>> from
>> timing out?
>=20
> Reference [HomeGateway] may be useful here.  Adaptive algorithms are =
probably going to have the best performance here.
>=20
>> This and other places explicitly mention that in-flight messages may =
be
>> lost
>> when the transport is closed or reset. This creates uncertainty about
>> whether
>> such messages have been processed or not. Is that really okay?
>=20
> It is not ideal, in particular for methods that are not idempotent =
(e.g., POST).
> The Web has had that problem for a long time now and has evolved ways =
to deal with the uncertainty.
> But it does require attention from application programmers.
>=20
>> 4: After the discussion resulting from Mark's Art-Art review, I =
expected
>> to
>> see more emphasis about WebSocket being intended for browser-based
>> clients.
>> There's a couple of in-passing mentions of browser-clients buried in
>> the
>> text; I would have expected something more up front.
>=20
> The introduction currently motivates the WebSockets part with:
>=20
>   CoAP applications running inside a web browser without access to
>   connectivity other than HTTP and the WebSocket protocol [RFC6455] =
may
>   cross-proxy their CoAP requests via HTTP to a HTTP-to-CoAP cross-
>   proxy or transport them via the the WebSocket protocol, which
>   provides two-way communication between a WebSocket client and a
>   WebSocket server after upgrading an HTTP/1.1 [RFC7230] connection.
>=20
> How could we emphasize browsers even more?
>=20
>> 4.2: Is it really worth making the framing code behave differently =
for
>> WebSocket than for TCP?
>=20
> WebSockets already has framing, which we use (and thus do not populate =
the length field).
> TCP (TLS) doesn=E2=80=99t, so we do need the length. =20
> Since the implementations are likely to be completely different =
anyway, I don=E2=80=99t see a big problem in that minor difference.
>=20
>>=20
>> 5.3: Do I understand correctly that once an option is established, it
>> cannot
>> be removed unless replaced? (Short of tearing down the connection and
>> starting over, anyway.)
>=20
> Some CSM capability indicating options are that way, yes (e.g., the =
Block capability).
> Why would such a capability go away during a connection?
>=20
>>=20
>> 7.2: The text mentions 443 as a default port, but really seems to =
make
>> 5684
>> the default. If 443 is really a default, then this needs  discussion
>> about
>> why and why it's okay to squat on HTTPS.
>=20
> Well, 443 is the general port for ALPN.
> 5684 is for the case without ALPN.
> But see also https://github.com/core-wg/coap-tcp-tls/issues/155
>=20
>>=20
>> The text about whether ALPN is required is confusing. Why not just
>> require
>> ALPN and move one, rather than special casing it by port choice? =
(There
>> seems
>> to be some circular logic about requiring 5685 to support clients =
that
>> don't
>> do ALPN, then saying clients MUST do ALPN unless they are using port
>> 5685.)
>=20
> I believe the text is consistent here. It just may be more complicated =
than needed, depending on how much you believe ALPN is already =
ubiquitous.  See https://github.com/core-wg/coap-tcp-tls/issues/155 for =
the question we have taken home as homework.
>=20
>>=20
>> 7.3: I agree with Adam's DISCUSS comment. And even if people decide =
that
>> the
>> well-known bit can be specified in CORE, I think it does future users =
of
>> a
>> well-known URIs for ws a disservice to make them dig through this =
spec
>> to
>> find the update to 6455.  It would be better to pull that into a
>> separate
>> draft. That's also a material addition post IETF last call, so we =
should
>> consider
>> repeating the LC.
>=20
> Of course, we will follow the wisdom of the IESG of how to handle =
this.
>=20
>> 10.2: Is the registration policy "analogous to" that of [RFC7252] =
S12.2,
>> or
>> "identical to" it. If the answer is not "identical", then the policy
>> should be detailed here.
>=20
> It is analogous, because the structure of the subregistry is slightly =
different (additional column).
> We can add a sentence that the value of the additional column does not =
influence the choice of the policy.
>=20
>=20
>> Editorial:
>>=20
>> Figures 7 and 8: "Payload (if any)" - Can we assume that if one uses
>> either
>> extended length format, one has a payload?
>=20
> In practice yes, but the options could be verrrrry long.
> The figures try to show the similarity of the subformats, not the =
differences...
>=20
>> 3.3: Is the guidance about what errors to return if you don't =
implement
>> a
>> server any different here than for UDP?
>=20
> A UDP server can send a reset.  The equivalent here of closing down =
the TCP connection is unhealthy for the other direction, that=E2=80=99s =
why it is good to have some response.
>=20
>>=20
>> 4.3 and 4.4 seem to primarily repeat details that are the same for WS =
as
>> for
>> TCP, even though the introduction to the WS part says that it won't =
do
>> that
>> :-)
>=20
> Right.  Diminishing returns, though.
>=20
>=20
>>=20
>> 5.3: "One CSM MUST be sent by both endpoints...": s/both/each
>=20
> Good point.
>=20
>>=20
>> 7.6: The "updates" in this section are confusing. I understand this =
to
>> mean
>> that the procedures for TCP and WS are identical to those for UDP =
except
>> for
>> the mentioned steps. But the language of the form of "This step from
>> [RFC7252] is updated to:" makes it sound like this intends to =
actually
>> change
>> the language in 7252 to this new language. If the latter, then that
>> effectively removes UDP support from 7252 as updated.
>=20
> OK, =E2=80=9Cupdate=E2=80=9D is not the right word them.
>=20
>>=20
>> This could easily be fixed by changing that to something to the =
effect
>> of
>> "When using TCP, this step changes to =E2=80=A6"
>=20
> Good point.
>>=20
>> Appendix A: Why is this an appendix? Updates to a standards track RFC
>> seem to
>> warrant a more prominent position in the draft.
>=20
> It was smeared all over the document, and then we collected it in an =
appendix.
> I don=E2=80=99t think anyone would have a strong opposition against =
making it a mainline section.
> Should we?
>=20
> I have collected the editorial issues into =
https://github.com/core-wg/coap-tcp-tls/issues/158 (at least the ones =
where I know what we need to do or what needs to be discussed).
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20


From nobody Wed May 10 23:55:46 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DF21205F0; Wed, 10 May 2017 23:55:38 -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 oKdI3N1eYdLW; Wed, 10 May 2017 23:55:35 -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 8C17F127B52; Wed, 10 May 2017 23:55:34 -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 v4B6tTCw018599; Thu, 11 May 2017 08:55:29 +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 3wNkQ93cT9zDGt3; Thu, 11 May 2017 08:55:29 +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: Thu, 11 May 2017 08:55:28 +0200
Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org
X-Mao-Original-Outgoing-Id: 516178528.808296-19d357285ffd841753b7f9dbb8e11017
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <149430548476.30014.11810513211435340238.idtracker@ietfa.amsl.com> <7ABC8B29-825A-4FC4-9DF3-7BA877A4561F@tzi.org> 
To: Adam Roach 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [core] Adam Roach's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 06:55:38 -0000

>> I think I addressed this one in the comments to Mirja.
>>=20
>> I=E2=80=99m still amazed how the arrangement of the first few bytes =
of the header can cause so much interest.
>>=20
>=20
> It's not so much the specific arrangement itself as much as the =
creation of three mutually incompatible versions of the arrangement     =
that is causing me heartburn.

Well, there is only one arrangement, with a variable-size length =
extension.
I=E2=80=99m afraid the box notation we used doesn=E2=80=99t make the =
simplicity very transparent.

This box notation might have been better:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Len  |  TKL  |      Code     | Length extension (if any)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Token (if any, TKL bytes) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Options (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 1 1 1 1 1|    Payload (if any) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


> I'd be much happier with something baroque like little-endian byte =
packing than with so many variations on a theme. I'm seeing that some =
implementations will have to have three different parsers (or equivalent =
complexity in terms of alternate code paths) and three different =
serializers if they're going to implement all three variations. That is =
very unfriendly to developers and testers alike.

Well, we=E2=80=99ll have to fix the presentation so people don=E2=80=99t =
think there is more to this than there is.
(Variable-size lengths already occur in other places in the CoAP =
protocol, so this is not surprising to CoAP developers.)

Now https://github.com/core-wg/coap-tcp-tls/issues/159

>>> Additionally, it=E2=80=99s not clear from the introduction what the =
motivation
>>> for using the mechanisms in this document is as compared to the
>>> techniques described in section 10 (and its subsections) of RFC =
7252.
>>>=20
>> I read this as =E2=80=9Cwhy don=E2=80=99t you use HTTP when you need =
TCP=E2=80=9D?
>> CoAP over TCP is more complex than CoAP over UDP, but still much less =
complex than either one of the HTTPs.
>>=20
>=20
> I really hope this doesn't come across as snarky, as such is really =
not my intention, but that explanation thoroughly falls apart when I get =
to section 4.

Well, I was talking about CoAP over TCP and not CoAP over Websockets. =20=

There is a different simplicity argument for the latter: Not having to =
translate application semantics simplifies the application.

>=20
>>> With the exception of subscribing to resource state (which could be
>>> added),
>>>=20
>> A very big exception =E2=80=94 the observe option is fundamental to =
many interactions with Things, and we currently don=E2=80=99t have a way =
to map this on HTTP.
>=20
> I would suggest becoming familiar with RFC8030.

Web Push is about forwarding messages (=E2=80=9Cevents=E2=80=9D), not =
about observing resources.
I=E2=80=99m sure we can create a mapping from resources to messages back =
to resources, but that is exactly the kind of complexity that direct use =
of CoAP can avoid.

>=20
>>=20
>>> it seems that such an approach is significantly easier to
>>> implement and more clearly defined than what is in this document; =
and it
>>> appears to provide the combined benefits of all four transports =
discussed
>>> in this document. My concern here is that an explosion of transport
>>> options makes it less likely that a client and server can find two =
in
>>> common: the limit of the probability of two implementations having a
>>> transport in common as the number of transports approaches infinity =
is
>>> zero. Due to this likely decrease in interoperability, I=E2=80=99d =
expect to see
>>> some pretty powerful motivation in here for defining a third, =
fourth,
>>> fifth, and sixth way to carry CoAP when only TCP is available (I =
count
>>> RFC 7252 http and https as the first and second ways in this
>>> accounting).
>>>=20
>> These motivations are in the draft.
>=20
> To be clear: I think it needs to clearly say "we are making interop =
less likely, and find these benefits to be sufficiently compelling to =
justify doing so." I suspect that, phrased that way, the current =
justification won't hold up to your own scrutiny, at least not without =
being made substantially more convincing.

While reducing options always is a good objective, there are also cases =
where creating options increases interoperability.
Which of the two effects prevails depends a lot on the specifics of the =
domain.

[snip]

> Perhaps an explanation closer to the fron that ties Max-Message-Size, =
block transfer, and the BERT mechanism together would be useful.

Makes sense.  Now https://github.com/core-wg/coap-tcp-tls/issues/160

>=20
> [snip]
>=20
>>> Specific comments follow.
>>>=20
>>> Section 3.3, paragraph 3 says that an initiator may send messages =
prior
>>> to receiving the remote side=E2=80=99s CSM, even though the message =
may be larger
>>> than would be allowed by that CSM.  What should the recipient of an
>>> oversized message do in this case? In fact, I don=E2=80=99t see in =
here what a
>>> recipient of a message larger than it allowed for in its CSM is =
supposed
>>> to do in response at *any* stage of the connection. Is it an error? =
If
>>> so, how do you indicate it? Or is the Max-Message-Size option just a
>>> suggestion for the other side? This definitely needs clarification.
>>>=20
>> Given the introduction of Max-Message-Size, there was some =
speculation that it would be good to allow going below the default CoAP =
value of 1152.
>=20
> Including the rationale in the document would be good.
>=20
>> In UDP CoAP, preferences of this kind are indicated in the =E2=80=9Ccon=
trol usage=E2=80=9D of the Block options, and there is an assumption =
that violating them will lead to suboptimal performance, not to =
malfunction.  But we never really thought that the possibility of =
reducing Max-Message-Size below 1152 would motivate making the state =
machine more complex; maybe we should state the obvious and add the =
warning that indicating a smaller Max-Message-Size is no protection =
against receiving a message that was sent off before that new value was =
known to the peer.
>=20
> Yes. I guarantee that the current phrasing will make some implementors =
want to treat messages larger than their advertised Max-Message-Size as =
an error. If it is supposed to be not an error, you need explicit =
language that it is not an error.
>=20

We should cover this in =
https://github.com/core-wg/coap-tcp-tls/issues/160=20

[snip]
>=20
>>> Section 4.4 has a prohibition against using WebSockets keepalives in
>>> favor of using CoAP ping/pong. Section 3.4 has no similar =
prohibition
>>> against TCP keepalives, while the rationale would seem to be =
identical.
>>> Is this asymmetry intentional?
>>>=20
>> Successful TCP keepalives are usually not visible to the application, =
so they are not quite in the same league as CoAP PING/PONG or WebSocket =
mechanism.  This is a SHOULD NOT because there may be reasons why the =
WebSocket mechanism might be the one to use; the CoAP-level PING/PONG =
are closer to the application and provide some CoAP-specific =
functionality (such as Custody).
>=20
> You seem to have answered some inverse of what I was asking, so I'll =
try to be clearer: should section 3.4 say "SHOULD NOT use TCP =
keepalives=E2=80=9D?

The assumption here is that we cannot mandate anything about TCP =
keepalives because it may be outside of the control of the application.  =
But there is nothing in the protocol that would create interoperability =
problems if an application did have control and used them.  So I =
wouldn=E2=80=99t add that.

> [snip]
>=20
>>=20
>>> I find the described operation of the Custody Option in the =
operation of
>>> Ping and Pong to be somewhat problematic: it allows the Pong sender =
to
>>> unilaterally decide to set the Custody Option, and consequently
>>> quarantine the Pong for an arbitrary amount of time while it =
processes
>>> other operations.
>>>=20
>> Oh.  The intention was that the PINGer gives permission to delay with =
the Custody option. =20
>> I now realize that the text isn=E2=80=99t clear about that.
>>=20
>> s/Unless there is an
>>    option with delaying semantics/Unless the PING carries an
>>    option with delaying semantics/
>>=20
>> Now=20
>> https://github.com/core-wg/coap-tcp-tls/issues/154
>=20
> That fixes part of the problem. 5.4.1 also says "When responding to a =
Ping message, the receiver can include an elective Custody Option in the =
Pong message," making it again sound like it's the entity sending the =
Pong making the decision.
>=20
> And then I can't read the second paragraph of section 5.4.1 in any way =
other than "in addition to the (clearly unilateral) decision to include =
a Custody Option in a Pong, the sender of the Ping can request that this =
happen by including one in the Ping."
>=20
> I think most of the text in 5.4.1 needs to be rewritten to make it =
clear -- and I do suggest normative language here -- that a Ping MAY =
include a Custody Option, and a Pong MUST NOT include a Custody Option =
unless the corresponding Ping also contained one.

Well, the latter MUST NOT would be only about delaying =E2=80=94 a PONG =
MAY very well include a spontaneous Custody option (or similar).

>> (Or a similar future option.)
>=20
> Yes. Or a similar future option.
>=20
>=20
>>> I am similarly perplexed by the hard-coded =E2=80=9Cmust do ALPN =
*unless* the
>>> designated port takes the magical value 5684=E2=80=9D behavior. I =
don=E2=80=99t think
>>> I=E2=80=99ve ever seen a protocol that has such variation based on a =
hard-coded
>>> port number, and it seems unlikely to be deployed correctly (I=E2=80=99=
m imaging
>>> the frustration of: =E2=80=9CI changed both the server and the =
client
>>> configuration from the default port of 5684 to 49152, and it just =
stopped
>>> working. Like, literally the *only* way it works is on port 5684. =
I've
>>> checked firewall settings everywhere and don't see any special =
handling
>>> for that port -- I just can't figure this out, and it's driving me
>>> crazy.=E2=80=9D). Given the nearly universal availability of ALPN in =
pretty much
>>> all modern TLS libraries, it seems much cleaner to just require ALPN
>>> support and call it done. Or *don=E2=80=99t* require ALPN at all and =
call it
>>> done. But *changing* protocol behavior based on magic port numbers =
seems
>>> like it=E2=80=99s going to cause a lot of operational heartburn.
>>>=20
>> Interesting scenario.
>>=20
>> The current rules are an attempt to use ALPN as it is the future, but =
also allow environments (which were specifically cited,
>>=20
>=20
> Not in this document, as far as I can tell. Including design rationale =
for non-obvious choices is generally a Good Thing....
>=20
>> but I forget which ones they were)
>=20
> ...and that's why.

But which environments do not support ALPN is very ephemeral =
information.
(I seem to remember we specifically talked about Microsoft .NET =E2=80=94 =
I don=E2=80=99t think we should build this up to an implementation =
survey about ALPN.)

>> without ALPN to play.  I think that objective is worth some =
complexity, but I=E2=80=99ve opened an issue to discuss this =
nonetheless.
>>=20
>> Now=20
>> https://github.com/core-wg/coap-tcp-tls/issues/155
>=20
> I think this conversation will be very difficult to properly reason =
about unless someone can unearth the rationale that you describe above.
>=20
>>> The final paragraph of section 8.1 is very confusing, making it =
somewhat
>>> unclear which of the three modes must be implemented on a CoAP =
client,
>>>=20
>> The entirety of CoAP over TCP is optional for a CoAP client or =
server.
>=20
> s/CoAP client/coaps+tls client/ -- sorry for the imprecision, as I =
thought this would be obvious from context.

The MTI would then address the constrained-to-cloud use case and ignore =
that there are other use cases.
So we would recommend RFC 7925 cipher suites and make RPK MTI because it =
is MTI in RFC 7252.

(The MTIs revert to default for coaps+ws.)

>=20
>>> and which must be implemented on a CoAP server. Read na=C3=AFvely, =
this sounds
>>> like clients are required to do only one (but one of their choosing) =
of
>>> these three, while servers are required to also do only one (again, =
of
>>> their choosing).
>>>=20
>> Generally, this is determined by what kind of security workflows are =
used; writing down a preference here will have little impact.
>=20
> This again points towards something about CoAP that's giving me a =
vague sense of unease about the whole ecosystem as designed. Right now, =
you have the mutually incompatible options of:
>=20
> 	=E2=80=A2 COAP/UDP
> 	=E2=80=A2 COAP/DLTS/UDP
> 	=E2=80=A2 COAP mapped to HTTP per RFC 7252
> 	=E2=80=A2 COAP mapped to HTTPS per RFC 7252
> 	=E2=80=A2 COAP/TCP
> 	=E2=80=A2 COAP/TLS/TCP with PSK
> 	=E2=80=A2 COAP/TLS/TCP with Raw Public Key
> 	=E2=80=A2 COAP/TLS/TCP with Certs
> 	=E2=80=A2 COAP/WS/HTTP
> 	=E2=80=A2 COAP/WS/HTTPS

They are incompatible only in the sense that IP is incompatible over =
Ethernet from over WiFi:  I can=E2=80=99t connect my laptop (that =
connects fine over WiFi) to Ethernet without a dongle.  But of course =
there is a switch connecting the two.  Actually, the WebSockets use case =
pretty much *requires* the use of a proxy to translate between =
WebSockets from the browser and the device protocol (which likely will =
be CoAP/UDP or CoAP/DTLS/UDP).  Devices should not have to implement =
WebSockets.

> It might be worse than this, as I suspect that your handling of DTLS =
probably parallels your handling of TLS. And these are all =
*configuration* options, not negotiated options. It's made worse by the =
fact that you're defining the resource spaces for many of these to be =
different from the others, so you can't just switch among them to find =
one you have in common: if something is available via coaps+tcp, then =
there's no mechanical way to determine whether it's also available over =
coaps (on UDP), so even an assertion that UDP is MTI doesn't make things =
work.

Yes, the siloing of URIs by URI schemes is unfortunate.

> I think Hannes' response is very telling, so I'll quote it here:
>=20
>> We care only about CoAP over TLS. We are not going to use the =
WebSockets
>> part of the document. In practice for many companies there will not =
be a
>> problem with too many transports since they will only use specific =
ones
>> in their deployment.
>>=20
>=20
> Basically what I'm hearing is that each deployment will have to pick =
one of these mutually incompatible (and increasingly unrelated) flavors =
of COAP. At some point, this becomes indistinguishable from each =
installation having its own proprietary protocol in terms of the =
benefits derived from standardization in the first place.

Very much not so, because they are all bound together by the Web model =
of permissionless-innovation enabled Web proxies.

> I'm sad that these protocols are syntactically different from each =
other and have different state machines, requiring multiple or =
unnecessarily complex libraries to implement them. I'm sad that these =
protocols have disjoint resource spaces, preventing automated     =
failover among them to find one in common. I'm sad that these protocols =
have no in-built negotiation among themselves. I'm sad that these =
protocols have no MTI among the myriad of options, and particularly sad =
that the disjoint resource spaces will forever slam the door on fixing =
that flaw. And I'm sad that this list appears to be long and growing =
longer.
>=20
> Mostly, I'm sad that saying "our device uses CoAP" is becoming an =
increasingly meaningless statement, as you have to be very clear about =
which incompatible variation of CoAP it implements.

We are very aware of that danger.
In fact, the biggest obstacle to interoperation is incompatible security =
flows, and groups such as ACE have been set up to get more =
interoperability there.

Until recently, we tried to get by with UDP transport only, but the =
realities of today=E2=80=99s Internet cannot be ignored.

[snip]

>=20
>>> It seems that the chance of finding devices that could
>>> interoperate under such circumstances is going to be relatively low: =
to
>>> work together, you would have to find a client and a server that =
happened
>>> to make the same implementation choice among these three. What I=E2=80=
=99m used
>>> to in these kinds of cases is: (a) server must implement all, client =
can
>>> choose to implement only one (or more), (b) client must implement =
all,
>>> server can choose to implement only one (or more), or (c) client and
>>> server must implement a specifically named lowest-common =
denominator, and
>>> can negotiate up from there. Pretty much anything else (aside from
>>> strange =E2=80=9Ceveryone must implement two of three=E2=80=9D =
schemes) will end up with
>>> interop issues.
>>>=20
>> The server and client roles are not really defined very well here, as =
either side can use a connection either way once it has been set up.
>>=20
>> My advice would be: If you want interoperability, use CoAP over UDP =
with the security model that you have a security workflow for.
>> If there are operational restrictions making this impossible, respond =
to those operational restrictions.
>>=20
>=20
> This seems precluded by the determination that each transport has a =
disjoint resource space.

That=E2=80=99s where the link bundles come in that we discussed with =
Ben.
Infrastructure such as the Resource Directory can mitigate this =
somewhat.

I have to run now; more about the rest of your message (Observe and =
proxies) later.

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


From nobody Thu May 11 05:34:31 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3C012EC03; Thu, 11 May 2017 05:34:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level: 
X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=Frz1/BK1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=G3kWSe//
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 nNSzBX2NlGBR; Thu, 11 May 2017 05:34:23 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7291512EBEA; Thu, 11 May 2017 05:31:59 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A7369205E9; Thu, 11 May 2017 08:31:58 -0400 (EDT)
Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 11 May 2017 08:31:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=b5HptHxgZXGslckvOauCufSuNFHnL 0mF4Xj+FsfRpts=; b=Frz1/BK14qdGvJrrWKTVWqY2CfzhfsKwVBDWAjKyrNrSR YFHnuTpFG/mPplTamP+ktwVZhoAHpbhNIQFNxXk3Z/xGEs2rM0UdQVE5HIS4+zo2 GGj63UWacj7a9yINA/hpepj5acpQWXE1JUBISmwYQbqAEg7+EkyQWMKDVca7t1V2 sM8tnCg0PbAWsIm6RspOHC03efREe05AZc9xk1g8o3QSR7WM1PnX8S+edivTIoyN sMK4GWacCMZSCKnfRuy2e7U0567oYfX/T65FK3s6o1bjPGzuKL2FRhMbMVq1hNGz vyU5LLEauZN+BgTf6MNLfdNPu8S+/8dyScgtTR3GA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=b5HptH xgZXGslckvOauCufSuNFHnL0mF4Xj+FsfRpts=; b=G3kWSe//pG73FcHZnqsrhQ dJ2zhhfUKL5RK8P02D+CWBmKOYpjQDl+4/E9rUj85TgxdDXYJvoGOHuptv0DMFU0 B8g2X5bhjqmu6e1HZGou9HGVkboxumtvdjEaJJpd0hAsRMrMFLvP3ntvXqpuwunR 23y5JOdv1ocvNFwPcG1NlvQ/5fE5TcIM4AeAmKEb7o83As/Y2M0KH2nca/Q3IO8U M+TrcnNKkta5Z2pl/Kb2+L1OSWywmXSIpsvS5Suxa+wo8jNaN8Id56TQj579URu7 I3p/X9zj3ie1qljuHr7mHIhOPDvng4pCaRrgeP0FFkq3R2ATwuaGVlVVJM5EcYjw ==
X-ME-Sender: 
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 868569E25D; Thu, 11 May 2017 08:31:58 -0400 (EDT)
Message-Id: <1494505918.21813.973220600.15673CC9@webmail.messagingengine.com>
From: Alexey Melnikov 
To: Adam Roach , The IESG 
Cc: jaime.jimenez@ericsson.com, core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-6cc55fe1
References: <149444740052.16728.2139093383077364684.idtracker@ietfa.amsl.com>
In-Reply-To: <149444740052.16728.2139093383077364684.idtracker@ietfa.amsl.com>
Date: Thu, 11 May 2017 13:31:58 +0100
Archived-At: 
Subject: Re: [core] Adam Roach's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 12:34:25 -0000

Hi Adam,

On Wed, May 10, 2017, at 09:16 PM, Adam Roach wrote:
> Adam Roach has entered the following ballot position for
> draft-ietf-core-coap-tcp-tls-08: Discuss

 [snip]

> ISSUE 2: Assignment of port 443 as default
> 
> - Widespread deployment would be damaging to the Internet or an
> enterprise network for reasons of congestion control, scalability, or the
> like. 
> 
> I'd like to thank the authors for helping me to understand the intention
> with the use of port 443 more clearly. Based on their clarifications, I
> need to move my issue about assigning a default of port 443 to coaps+tcp
> from my Comment into the Discuss, as it does have implications for the
> Internet at large that will have long-term damaging effects.
> 
> The rationale being offered for the using the already-assigned port 443
> as a default is that it tends to go through firewalls that other ports
> may not, and that doing so is fine because ALPN makes it possible. These
> arguments, if we accept them, are manifestly true for all future
> TLS-using protocols. Allowing CoAP to re-use an assigned port on this
> basis established precedent for pretty much all future protocols to do
> so, effectively moving the protocol demux point for future protocols from
> port numbers to ALPN IDs (all over port 443). It is hard to imagine an
> outcome *other* *than* firewall manufacturers starting to whitelist
> desired ALPN IDs, which effectively ossifies the available set of IDs to
> whatever is defined at that moment, destroying the future utility of the
> mechanism.
> 
> There are other issues having to do with software architecture, protocol
> demultiplexing in user space rather than kernel space, and operational
> considerations that come into play as well, but they don't technically
> fall under discuss criteria.

I've missed use of port 443 in my review. I agree with you that this is
an issue for coaps+tcp URIs.

It is not an issue for coaps+ws URIs, which are similar to wss URIs
which also use 443 as the default.

Best Regards,
Alexey


From nobody Thu May 11 06:13:38 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507ED129401; Thu, 11 May 2017 06:13:28 -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 WInm3vtMXFQh; Thu, 11 May 2017 06:13:26 -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 C4811129420; Thu, 11 May 2017 06:10:50 -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 v4BDAhkt005208; Thu, 11 May 2017 15:10:43 +0200 (CEST)
Received: from [192.168.217.113] (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 3wNtl66WqPzDH5d; Thu, 11 May 2017 15:10:42 +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: <1494505918.21813.973220600.15673CC9@webmail.messagingengine.com>
Date: Thu, 11 May 2017 15:10:42 +0200
Cc: Adam Roach , The IESG , jaime.jimenez@ericsson.com, core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org
X-Mao-Original-Outgoing-Id: 516201042.157737-da3299eb34007110a17be18a2e53ebbb
Content-Transfer-Encoding: quoted-printable
Message-Id: <805AC400-280B-4639-B77C-EEDC98EDEB48@tzi.org>
References: <149444740052.16728.2139093383077364684.idtracker@ietfa.amsl.com> <1494505918.21813.973220600.15673CC9@webmail.messagingengine.com>
To: Alexey Melnikov 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [core] Adam Roach's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 13:13:28 -0000

On May 11, 2017, at 14:31, Alexey Melnikov  =
wrote:
>=20
> Hi Adam,
>=20
> On Wed, May 10, 2017, at 09:16 PM, Adam Roach wrote:
>> Adam Roach has entered the following ballot position for
>> draft-ietf-core-coap-tcp-tls-08: Discuss
>=20
> [snip]
>=20
>> ISSUE 2: Assignment of port 443 as default
>>=20
>> - Widespread deployment would be damaging to the Internet or an
>> enterprise network for reasons of congestion control, scalability, or =
the
>> like.=20
>>=20
>> I'd like to thank the authors for helping me to understand the =
intention
>> with the use of port 443 more clearly. Based on their clarifications, =
I
>> need to move my issue about assigning a default of port 443 to =
coaps+tcp
>> from my Comment into the Discuss, as it does have implications for =
the
>> Internet at large that will have long-term damaging effects.
>>=20
>> The rationale being offered for the using the already-assigned port =
443
>> as a default is that it tends to go through firewalls that other =
ports
>> may not, and that doing so is fine because ALPN makes it possible. =
These
>> arguments, if we accept them, are manifestly true for all future
>> TLS-using protocols. Allowing CoAP to re-use an assigned port on this
>> basis established precedent for pretty much all future protocols to =
do
>> so, effectively moving the protocol demux point for future protocols =
from
>> port numbers to ALPN IDs (all over port 443). It is hard to imagine =
an
>> outcome *other* *than* firewall manufacturers starting to whitelist
>> desired ALPN IDs, which effectively ossifies the available set of IDs =
to
>> whatever is defined at that moment, destroying the future utility of =
the
>> mechanism.
>>=20
>> There are other issues having to do with software architecture, =
protocol
>> demultiplexing in user space rather than kernel space, and =
operational
>> considerations that come into play as well, but they don't =
technically
>> fall under discuss criteria.
>=20
> I've missed use of port 443 in my review. I agree with you that this =
is
> an issue for coaps+tcp URIs.

Without having verified this with the WG:=20
I don=E2=80=99t think that the choice of the default port 443 for =
coaps+tcp:// is in any way essential.

We chose 443 as a matter of course -- both RFC 7301 (ALPN) and =
operational practice suggested it.
But I believe we can also live with the coaps:// port 5684 as the =
default port for coaps+tcp://.

> It is not an issue for coaps+ws URIs, which are similar to wss URIs
> which also use 443 as the default.

Indeed, coaps+ws:// should keep 443 as the default (as should coap+ws:// =
with port 80), as they are mapped to wss:// and ws://.

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


From nobody Thu May 11 06:36:01 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA82312FEE1; Thu, 11 May 2017 06:35:51 -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 I3e5r6qxHPiU; Thu, 11 May 2017 06:35:50 -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 87E9C12EC5E; Thu, 11 May 2017 06:32:12 -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 v4BDW8Lr022329; Thu, 11 May 2017 15:32:08 +0200 (CEST)
Received: from [192.168.217.113] (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 3wNvCq6jSYzDH6Y; Thu, 11 May 2017 15:32:07 +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: Thu, 11 May 2017 15:32:07 +0200
Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org
X-Mao-Original-Outgoing-Id: 516202327.302926-3515e155f5ed2e0f6abfdfc61cc15cfb
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <149430548476.30014.11810513211435340238.idtracker@ietfa.amsl.com> <7ABC8B29-825A-4FC4-9DF3-7BA877A4561F@tzi.org> 
To: Adam Roach 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [core] Adam Roach's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 13:35:52 -0000

Continuing from this morning:

>>> Although the document clearly expects the use of gateways and =
proxies
>>> between these connection-oriented usages of CoAP and UDP-based CoAP,
>>> Appendix A seems to omit discussion or consideration of how this
>>> gatewaying can be performed. The following list of problems is
>>> illustrative of this larger issue, but likely not exhaustive. (I'll =
note
>>> that all of these issues evaporate if you move to a simpler scheme =
that
>>> merely frames otherwise unmodified UDP CoAP messages)
>>>=20
>>> Section A.1 does not indicate what gateways are supposed to do with
>>> out-of-order notifications. The TCP side requires these to be =
delivered
>>> in-order; so, do this mean that gateways observing a gap in sequence
>>> numbers need to quarantine the newly received message so that it can
>>> deliver the missing one first? Or does it deliver the newly-received
>>> message and then discard the =E2=80=9Cstale=E2=80=9D one when it =
arrives? I don=E2=80=99t think
>>> that leaving this up to implementations is particularly advisable.
>>>=20
>> Yes, we had that discussion on the list.  There is little point in =
trying to do anything here but the latter. =20
>> We could state that more explicitly here, or leave that to =
implementers=E2=80=99 advice documents such as draft-ietf-lwig-coap =
(we=E2=80=99ll need to  rework section 6 of that now anyway).
>>=20
>=20
> Say that out loud, or someone will get it wrong. I mean, I outlined =
the two potentially sensible things. There are infinite nonsensical =
things. Absent guidance, people will implement out of both categories.

Let=E2=80=99s do that.  Now =
https://github.com/core-wg/coap-tcp-tls/issues/161

>>> Section A.3 is a bit more worrisome. I understand the desired
>>> optimization here, but where you reduce traffic in one direction, =
you run
>>> the risk of exploding it in the other. For example, consider a =
coap+tcp
>>> client connecting to a gateway that communicates with a =
CoAP-over-UDP
>>> server. When that client wants to check the health of its =
observations,
>>> it can send a Ping and receive a Pong that confirms that they are =
all
>>> alive and well. In order to be able to send a Pong that *means* =
=E2=80=9Call your
>>> observations are alive and well,=E2=80=9D the gateway has to verify =
that all the
>>> observations are alive and well.
>>>=20
>> Oh.  The PONG says the proxy hasn=E2=80=99t crashed, so the =
observations are alive and well in the proxy.
>=20
> That's not what this document says, and why I was careful to quote =
from the document above.

Since observation relationships are hop-by-hop in CoAP (i.e., terminate =
at the next proxy), I can=E2=80=99t agree with your reading.
But again, we can state all this more explicitly.   Now =
https://github.com/core-wg/coap-tcp-tls/issues/162

>=20
>>   How that makes sure it gets fresh data from the next hop (by =
observe, by polling) is up to the proxy.  There is no intention that a =
PING suddenly makes a proxy do a check, when it otherwise has ignored =
its duty to check that before.
>=20
> You are making a bunch of assumptions here that are completely =
undocumented.
>=20
>>> A simple implementation of a gateway
>>> will likely check on each observed resource individually when it =
gets a
>>> Ping, and then send a Pong after it hears back about all of them. =
So, as
>>> a client, I can set up, let=E2=80=99s say, two dozen observations =
through this
>>> gateway. Then, with each Ping I send, the gateway sends two dozen =
checks
>>> towards the server. This kind of message amplification attack is an
>>> awesome way to DoS both the gateway and the server. I believe the
>>> document needs a treatment of how UDP/TCP gateways handle =
notification
>>> health checks, along with techniques for mitigating this specific
>>> attack.
>>>=20
>> See above.  We probably need to say that PINGs check the connection =
(and thus the fate-sharing observation state) but are not meant to make =
proxies frantically check the observation relationships to their data =
sources.   Now https://github.com/core-wg/coap-tcp-tls/issues/156
>=20
> Yes. That's the solution. I strongly suggest outlining this attack as =
one consequence if implementors ignore such advice. Sending checks when =
you get a Ping is the easiest thing to code, by far, so unless you =
explain that it could be potentially quite harmful, people *will* do it =
even if you say not to. (In fact, saying not to without being clear =
about *why* not could be worse than saying nothing; cf. =
=
)

Thanks.  I added that to 156 (and I learned a new term :-).

[snip]

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


From nobody Thu May 11 07:00:12 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B706E131446; Thu, 11 May 2017 07:00:04 -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 BS4R7eo4kpfj; Thu, 11 May 2017 06:59:56 -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 E9DF3130889; Thu, 11 May 2017 06:55: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 [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v4BDtRSs009724; Thu, 11 May 2017 15:55:27 +0200 (CEST)
Received: from [192.168.217.113] (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 3wNvkk6YfYzDH73; Thu, 11 May 2017 15:55:26 +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: <0F431FE8-DD65-4AF2-A65F-4229EC7E4EA3@nostrum.com>
Date: Thu, 11 May 2017 15:55:26 +0200
Cc: Jaime Jimenez , core-chairs@ietf.org, The IESG , core@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org
X-Mao-Original-Outgoing-Id: 516203726.098954-d1bc3ae29edad2179f4fce8e58d81712
Content-Transfer-Encoding: quoted-printable
Message-Id: <318F80FB-BADF-49BB-983C-9BFCA28CBC9C@tzi.org>
References: <149438315533.29515.17605324258067615896.idtracker@ietfa.amsl.com> <59D34C32-4AB4-4F42-8390-C7CA5FE92F86@tzi.org> <0F431FE8-DD65-4AF2-A65F-4229EC7E4EA3@nostrum.com>
To: Ben Campbell 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 14:00:05 -0000

On May 11, 2017, at 04:07, Ben Campbell  wrote:
>=20
>>=20
>> On May 10, 2017, at 2:38 PM, Carsten Bormann  wrote:
>>=20
>> Hi Ben,
>>=20
>> now for the other parts.
>>=20
>>> =
----------------------------------------------------------------------
>>> DISCUSS:
>>> =
----------------------------------------------------------------------
>>>=20
>>> 1) This draft removes the reliability and ordering features COAP =
when
>>> used
>>> over reliable transports, under the assumption that the transport =
will
>>> provide.
>>=20
>> Yes.
>>=20
>>> But the draft also includes the assumption that COAP proxies
>>> exist.
>>=20
>> This is not a new situation; we have had UDP-to-UDP proxies before =
(as well as cross-protocol proxies).
>=20
> Sure, but I guess I was more talking about proxies that translate =
between two transports, which of course could not exist until we started =
talking about additional transports.

The cognitive dissonance here comes from the fact that there is no way =
to specify a reliability level on a TCP hop, and some people have =
assumed that specifying a reliability level on a UDP hop somehow binds a =
proxy to use the same level on the next hop.  But that assumption is not =
justified.

>=20
>>=20
>>> This has the potential for creating a problem, since the transport =
can
>>> only
>>> provide guaranty reliable delivery and ordering to the next hop. =
Once
>>> you
>>> have a proxy in play, you loose that guaranty end to end.
>>=20
>> There is no guarantee in any of the transports.  End-to-end semantics =
require end-to-end support.
>=20
>=20
>=20
>>=20
>>> This is further complicated because this draft contemplates
>>> cross-transport
>>> proxies, where one side may be over WebSocket (and I assume might be
>>> over
>>> TCP) and the other side over UDP. If the client sends via TCP but a
>>> proxy
>>> changes it to UDP, the client has no way to specify the reliability
>>> properties to be used on the UDP connection. If one imagines a =
client
>>> that uses
>>> UDP to a forward proxy, which speaks TCP to a reverse-proxy, which =
then
>>> switches back to UDP, any reliability properties specified by the =
client
>>> will get
>>> lost.
>>=20
>> That has been true for UDP-to-UDP proxies, too.
>> (I wrote a little bit about that in =
https://mailarchive.ietf.org/arch/msg/core/Gpk8y4J78Pm7C8lKqMtxWdrzce0 =
.)
>=20
> With UDP, it was at least possible for a proxy to preserve the =
reliability type.

Yes.  The UDP reliability type is moderately useful as a hint.  If we =
want to add a hinting mechanism to TCP, we can put in an option =E2=80=94 =
this could then also be defined to give more useful hints (and then =
would be useful for UDP, too).

> A proxy could strip that, but it didn=E2=80=99t _have_ to strip that. =
In the scenarios I mention, it=E2=80=99s not possible for the proxy to =
preserve the reliability type, because it never sees it.=20

Well, TCP is reliable, so it is possible to preserve that reliability on =
the next hop.
What you can=E2=80=99t do today is proxy from unreliable UDP to TCP and =
mark the TCP transaction as unreliable because you expect the next proxy =
to follow that mark in selecting its reliability type on the next UDP =
hop.  If that scenario sounds contrived, well, it is.

>=20
>=20
>>=20
>>=20
>>> Also, a proxy can potentially reorder messages, even if it uses TCP =
on
>>> both
>>> sides. If one leaves ordering to the transport, then one needs to =
add
>>> rules
>>> about proxies maintaining that order.
>>=20
>> There are no new rules here =E2=80=94 everything a UDP-to-UDP CoAP =
proxy needed to do also needs to be done if one side is TCP.
>=20
> So maybe I misunderstand something here, at least about ordering in =
COAP. Doesn=E2=80=99t COAP/UDP have an application layer =
order-preservation mechanism?

Yes, but only for notification.  Complete request/response exchanges can =
use causal ordering at the application layer (send the next request only =
after receiving the response for the previous request), so, like HTTP, =
they don=E2=80=99t have any ordering at the transfer protocol level.
For ordering notifications, Observe (RFC7641) has a simple sequence =
numbering scheme.  We don=E2=80=99t need that on TCP, as all =
notifications from a single observation interest share a TCP connection =
and are thus already ordered by that connection.

> Is it not at least _possible_ for a UDP-UDP proxy to preserve that =
mechanism across transport instances?

For observe, a simple UDP-UDP proxy could hand through the observe =
sequence number if it uses observe on both ends.
This is a bit tenuous, as proxying adds jitter and the temporal range =
covered by the sequence number is limited, but the configurations where =
this matters are probably pathological.
A UDP-UDP proxy needs to generate its own sequence number if it uses =
polling on the origin server side.  It needs to discard out-of-order =
notifications if it is a caching proxy.  I would prefer to write up all =
these implementation strategies in the lwig-coap draft, which has a =
whole section on CoAP on various transports.

[snip]

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


From nobody Thu May 11 08:14:42 2017
Return-Path: 
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E31461300CE; Thu, 11 May 2017 08:14:33 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ben Campbell 
To: "The IESG" 
Cc: draft-ietf-core-coap-tcp-tls@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149451567392.16604.5915539927877259790.idtracker@ietfa.amsl.com>
Date: Thu, 11 May 2017 08:14:33 -0700
Archived-At: 
Subject: [core] Ben Campbell's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 15:14:34 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-core-coap-tcp-tls-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

1) [removed, please see update in comments]

2) It seems problematic to encode the transport choice in the URI
scheme.
 Section 7 says "They are hosted
in distinct namespaces because each URI scheme implies a distinct
origin
server." IIUC, this means any given resource can only be reached over a
specific transport. That seems to break the idea of cross-transport
proxies
as discussed in section 7.

It also does not seem to fit with a primary motivation for this draft.
That
is, one might want to use TCP because of local NAT/FW issues. But if
there is
a resource with a "coap" scheme, I cannot switch to TCP when I'm behind
a
problematic middlebox, and have an expectation of reaching the same
resource.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Update: I removed point 1 from my discuss. But I do still think it would
be useful to add a paragraph about how COAP reliability features are only
hop-by-hop.

Subtantive:

3.2: I agree with Adam that this length scheme seems very complex for
the
return

3.3: Since the initiator can start sending messages before receiving a
CSM
from the responder, how long should the initiator wait for a CSM before
bailing?

3.4: Can you offer any guidance about how often to send keep-alives? I
note
that these keepalives are not necessarily bi-directional. Aren't there
some
NAT/FW cases where bi-directional traffic is needed to keep bindings
from
timing out?

This and other places explicitly mention that in-flight messages may be
lost
when the transport is closed or reset. This creates uncertainty about
whether
such messages have been processed or not. Is that really okay?

4: After the discussion resulting from Mark's Art-Art review, I expected
to
see more emphasis about WebSocket being intended for browser-based
clients.
There's a couple of in-passing mentions of browser-clients buried in
the
text; I would have expected something more up front.

4.2: Is it really worth making the framing code behave differently for
WebSocket than for TCP?

5.3: Do I understand correctly that once an option is established, it
cannot
be removed unless replaced? (Short of tearing down the connection and
starting over, anyway.)

7.2: The text mentions 443 as a default port, but really seems to make
5684
the default. If 443 is really a default, then this needs  discussion
about
why and why it's okay to squat on HTTPS.

The text about whether ALPN is required is confusing. Why not just
require
ALPN and move one, rather than special casing it by port choice? (There
seems
to be some circular logic about requiring 5685 to support clients that
don't
do ALPN, then saying clients MUST do ALPN unless they are using port
5685.)

7.3: I agree with Adam's DISCUSS comment. And even if people decide that
the
well-known bit can be specified in CORE, I think it does future users of
a
well-known URIs for ws a disservice to make them dig through this spec
to
find the update to 6455.  It would be better to pull that into a
separate
draft. That's also a material addition post IETF last call, so we should
consider
repeating the LC.

10.2: Is the registration policy "analogous to" that of [RFC7252] S12.2,
or
"identical to" it. If the answer is not "identical", then the policy
should be detailed here.

Editorial:

Figures 7 and 8: "Payload (if any)" - Can we assume that if one uses
either
extended length format, one has a payload?

3.3: Is the guidance about what errors to return if you don't implement
a
server any different here than for UDP?

4.3 and 4.4 seem to primarily repeat details that are the same for WS as
for
TCP, even though the introduction to the WS part says that it won't do
that
:-)

5.3: "One CSM MUST be sent by both endpoints...": s/both/each

7.6: The "updates" in this section are confusing. I understand this to
mean
that the procedures for TCP and WS are identical to those for UDP except
for
the mentioned steps. But the language of the form of "This step from
[RFC7252] is updated to:" makes it sound like this intends to actually
change
the language in 7252 to this new language. If the latter, then that
effectively removes UDP support from 7252 as updated.

This could easily be fixed by changing that to something to the effect
of
"When using TCP, this step changes to ..."

Appendix A: Why is this an appendix? Updates to a standards track RFC
seem to
warrant a more prominent position in the draft.



From nobody Thu May 11 14:38:41 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1DC12EAE1; Thu, 11 May 2017 14:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level: 
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 h7AXPRT368su; Thu, 11 May 2017 14:38:36 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 796F8129461; Thu, 11 May 2017 14:33:00 -0700 (PDT)
Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4BLWsdv071401 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 May 2017 16:32:55 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local
To: Ben Campbell , The IESG 
Cc: jaime.jimenez@ericsson.com, core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org
References: <149451567392.16604.5915539927877259790.idtracker@ietfa.amsl.com>
From: Adam Roach 
Message-ID: <285fccb8-de64-7ea6-1ad0-ac3408ec188c@nostrum.com>
Date: Thu, 11 May 2017 16:32:35 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.0
MIME-Version: 1.0
In-Reply-To: <149451567392.16604.5915539927877259790.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------A7D05669EA17F455A37E499B"
Content-Language: en-US
Archived-At: 
Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 21:38:40 -0000

This is a multi-part message in MIME format.
--------------A7D05669EA17F455A37E499B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 5/11/17 10:14, Ben Campbell wrote:
> 2) It seems problematic to encode the transport choice in the URI scheme.
>
> Section 7 says "They are hosted in distinct namespaces because each URI scheme implies a distinct origin server." IIUC, this means any given resource can only be reached over a specific transport. That seems to break the idea of cross-transport proxies as discussed in section 7.
>
> It also does not seem to fit with a primary motivation for this draft. That is, one might want to use TCP because of local NAT/FW issues. But if there is a resource with a "coap" scheme, I cannot switch to TCP when I'm behind a problematic middlebox, and have an expectation of reaching the same resource.


I've been turning this over in my mind, and I think there are two 
problems here. The fundamental problem is that this document is encoding 
all kinds of protocol options into the URI scheme, which is an 
architecturally worrisome precedent for *all* URI-using protocols, 
current and future (by which I mean to say I don't think it's in CORE's 
unilateral purview to decide this is okay). This problem is compounded 
for CoAP in particular by treating the resource spaces associated with 
each scheme as distinct.

I don't know whether the second issue is intentional or just a 
misunderstanding about whether it is allowable to have different schemes 
share a resource space (it is; cf. [1]), but I think we can come up with 
a solution to the first problem that allows the second to become moot.

Looking to what we've done elsewhere in the IETF: considering the 
present moment, recent past, and near future, we effectively have six 
protocols in the wild for securely retrieving hypermedia across the 
Internet: HTTP 1.x, SPDY1, SPDY2, SPDY3, H2, and QUIC. Note that these 
protocols vary in syntax, semantics, and even transport-layer protocols. 
The URI schemes for these six different protocols are https, https, 
https, https, https, and https, respectively.

I think that's a good model. One pleasant advantage of this model is 
that it completely eliminates the resource space issue I describe above.


Concretely, then, I propose that the URI schemes in this document be 
assigned as follows:

For CoAP over TCP: coap

For CoAP over TLS over TCP: coaps

For CoAP over WS: coap

For CoAP over WSS: coaps


We then make UDP support mandatory to implement [2]. Now, let's talk 
about TCP. I'm leaving WebSockets out of this description for a moment, 
for reasons that I will explain later.

The general process for accessing a CoAP resource would be: try to 
contact the remote node over UDP using a Confirmable message. After some 
reasonable timespan (I would propose just prior to the third 
transmission [second retransmission] of a message), if no ACK had been 
received, those nodes that support TCP would try to initiate a TCP 
connection (same host, same port, different transport) in parallel with 
the third UDP transmission. If the TCP connection succeeds, abandon the 
UDP attempts and start the transaction over on the TCP connection [3].

Two additionally proposed minor details on this scheme that I think 
increase its appeal:

 1. Nodes SHOULD cache, on a per-authority basis, whether UDP failed
    (but TCP worked) in the past; and, if such a failure was observed
    within a reasonable timeframe (hours or maybe days), use TCP instead
    of UDP for subsequent contact. This cache would be flushed whenever
    an IP address or routing table change is observed.

 2. Nodes SHOULD allow configuration, both globally and on a
    per-authority basis, to skip the UDP attempt, so as to optimize
    connection times when UDP is administratively known to be nonviable
    or otherwise undesirable.


Turning now to WebSockets. As far as I can tell, the use of WebSockets 
is intended for a radically different deployment architecture than TCP 
-- it looks very much like TCP is meant to accommodate one or both of 
the parties being a constrained node, while WebSockets clearly is not: 
there is no way it makes sense for a constrained device to implement 
CoAP over WebSockets over HTTP on the conceit that it's simpler than 
using HTTP. So, this means that CoAP/WebSockets is intended to run only 
between two high-powered network hosts.

(I'd like to take a quick pause to say that these radically different 
use cases suggest that it would be a Really Good Idea to split 
CoAP/WebSockets out into its own document that builds on top of the 
CoAP/TCP document.)

Okay, so let's try to back out an architecture of *why* you have two 
non-contrained hosts using CoAP over WebSockets. Clearly, one of them is 
a browser, or you'd just use straight-up CoAP, right? In fact, the 
WebSockets client has to be the browser here. Further, if this is simply 
a browser sending and receiving data to and from a server, there are 
already a host of well-defined and broadly-deployed web technologies 
that they could use instead of CoAP.

That means that the the only sensible conclusion is that the server is 
one of: (a) a proxy for constrained device(s) that the browser wants to 
contact, (b) a proxy for non-constrained device(s) that speak only CoAP 
(presumably so constrained devices can also connect to it), or (c) both. 
In all three cases, the proxy needs to have its own mapping that 
converts from resources at its own authority to the corresponding 
resources on the authority/ies for which is is serving as a proxy. This 
is important, and we'll come back to it later.

As far as I can tell, that is the *only* context in which one might use 
CoAP/WebSockets. I mean, if there's some other architecture that makes 
sense here, I'd like to hear about it, but I think the logic above is 
pretty sound.

In that context, then: a CoAP node implemented inside a web browser that 
gets ahold of a coap: or coaps: URI can do precisely one thing: use 
WebSockets to connect to the authority, using the CoAP/WebSockets 
semantics defined in this document. It can't try UDP or TCP, because 
these affordances aren't available from a web execution context. So if 
the authority in the URL doesn't support CoAP/WebSockets, the client is 
done.

Now, what about other, non-browser nodes that happen to get ahold of 
these URIs? Well, now we're back to the fact that we made UDP MTI: these 
same servers are listening for normal CoAP over UDP (and maybe TCP, if 
they want to). So, remember how we said that this thing is necessarily a 
proxy fronting other resources, and it has its own mapping from its 
local resources to remote ones? That's what makes the whole UDP and TCP 
thing work: it just needs to act like the same proxy for CoAP/UDP and 
CoAP/TCP as it does for CoAP/WS.

/a

_____

[1] RFC section 4.1: "SIP and SIPS URIs that are identical except for 
the scheme itself (e.g., sip:alice@example.com and 
sips:alice@example.com) refer to the same resource."

[2] This is, I think, architecturally consistent with what's already 
been done. In fact, this may already be the case; I can't quickly find 
language covering this.

[3] The operation on the TCP connection would need to use the same 
Message ID as the UDP attempts did, to ensure idempotency -- it's 
possible that one or more of the transmitted UDP packets did make it to 
the remote node, but the ACKs did not arrive back at the originator. 
This does necessitate un-removing the Message ID field from TCP, but I 
think that's a Good Thing anyway.


--------------A7D05669EA17F455A37E499B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 5/11/17 10:14, Ben Campbell wrote:

    

    

      
2) It seems problematic to encode the transport choice in the URI scheme.

Section 7 says "They are hosted in distinct namespaces because each URI scheme implies a distinct origin server." IIUC, this means any given resource can only be reached over a specific transport. That seems to break the idea of cross-transport proxies as discussed in section 7.

It also does not seem to fit with a primary motivation for this draft. That is, one might want to use TCP because of local NAT/FW issues. But if there is a resource with a "coap" scheme, I cannot switch to TCP when I'm behind a problematic middlebox, and have an expectation of reaching the same resource.

    

    


    

    
I've been turning this over in my mind, and I think there are two
      problems here. The fundamental problem is that this document is
      encoding all kinds of protocol options into the URI scheme, which
      is an architecturally worrisome precedent for *all* URI-using
      protocols, current and future (by which I mean to say I don't
      think it's in CORE's unilateral purview to decide this is okay).
      This problem is compounded for CoAP in particular by treating the
      resource spaces associated with each scheme as distinct.

    
I don't know whether the second issue is intentional or just a
      misunderstanding about whether it is allowable to have different
      schemes share a resource space (it is; cf. [1]), but I think we
      can come up with a solution to the first problem that allows the
      second to become moot.

    
Looking to what we've done elsewhere in the IETF: considering the
      present moment, recent past, and near future, we effectively have
      six protocols in the wild for securely retrieving hypermedia
      across the Internet: HTTP 1.x, SPDY1, SPDY2, SPDY3, H2, and QUIC.
      Note that these protocols vary in syntax, semantics, and even
      transport-layer protocols. The URI schemes for these six different
      protocols are https, https, https, https, https, and https,
      respectively.

    
I think that's a good model. One pleasant advantage of this model
      is that it completely eliminates the resource space issue I
      describe above.

    


    

    
Concretely, then, I propose that the URI schemes in this document
      be assigned as follows:

    
For CoAP over TCP: coap

    
For CoAP over TLS over TCP: coaps

    
For CoAP over WS: coap

    
For CoAP over WSS: coaps

    


    

    
We then make UDP support mandatory to implement [2]. Now, let's
      talk about TCP. I'm leaving WebSockets out of this description for
      a moment, for reasons that I will explain later.

    

    
The general process for accessing a CoAP resource would be: try
      to contact the remote node over UDP using a Confirmable message.
      After some reasonable timespan (I would propose just prior to the
      third transmission [second retransmission] of a message), if no
      ACK had been received, those nodes that support TCP would try to
      initiate a TCP connection (same host, same port, different
      transport) in parallel with the third UDP transmission. If the TCP
      connection succeeds, abandon the UDP attempts and start the
      transaction over on the TCP connection [3].

    
Two additionally proposed minor details on this scheme that I
      think increase its appeal: 

    

    
    
      
  1. Nodes SHOULD cache, on a per-authority basis, whether UDP
        failed (but TCP worked) in the past; and, if such a failure was
        observed within a reasonable timeframe (hours or maybe days),
        use TCP instead of UDP for subsequent contact. This cache would
        be flushed whenever an IP address or routing table change is
        observed.
    
        
    
      
    2. 
      
  2. Nodes SHOULD allow configuration, both globally and on a
        per-authority basis, to skip the UDP attempt, so as to optimize
        connection times when UDP is administratively known to be
        nonviable or otherwise undesirable.
    
      
    3. 
    

    


    

    
Turning now to WebSockets. As far as I can tell, the use of
      WebSockets is intended for a radically different deployment
      architecture than TCP -- it looks very much like TCP is meant to
      accommodate one or both of the parties being a constrained node,
      while WebSockets clearly is not: there is no way it makes sense
      for a constrained device to implement CoAP over WebSockets over
      HTTP on the conceit that it's simpler than using HTTP. So, this
      means that CoAP/WebSockets is intended to run only between two
      high-powered network hosts.

    

    
(I'd like to take a quick pause to say that these radically
      different use cases suggest that it would be a Really Good Idea to
      split CoAP/WebSockets out into its own document that builds on top
      of the CoAP/TCP document.)

    
Okay, so let's try to back out an architecture of *why* you have
      two non-contrained hosts using CoAP over WebSockets. Clearly, one
      of them is a browser, or you'd just use straight-up CoAP, right?
      In fact, the WebSockets client has to be the browser here.
      Further, if this is simply a browser sending and receiving data to
      and from a server, there are already a host of well-defined and
      broadly-deployed web technologies that they could use instead of
      CoAP.

    
That means that the the only sensible conclusion is that the
      server is one of: (a) a proxy for constrained device(s) that the
      browser wants to contact, (b) a proxy for non-constrained
      device(s) that speak only CoAP (presumably so constrained devices
      can also connect to it), or (c) both. In all three cases, the
      proxy needs to have its own mapping that converts from resources
      at its own authority to the corresponding resources on the
      authority/ies for which is is serving as a proxy. This is
      important, and we'll come back to it later.

    

    
As far as I can tell, that is the *only* context in which one
      might use CoAP/WebSockets. I mean, if there's some other
      architecture that makes sense here, I'd like to hear about it, but
      I think the logic above is pretty sound.

    
In that context, then: a CoAP node implemented inside a web
      browser that gets ahold of a coap: or coaps: URI can do precisely
      one thing: use WebSockets to connect to the authority, using the
      CoAP/WebSockets semantics defined in this document. It can't try
      UDP or TCP, because these affordances aren't available from a web
      execution context. So if the authority in the URL doesn't support
      CoAP/WebSockets, the client is done.

    

    
Now, what about other, non-browser nodes that happen to get ahold
      of these URIs? Well, now we're back to the fact that we made UDP
      MTI: these same servers are listening for normal CoAP over UDP
      (and maybe TCP, if they want to). So, remember how we said that
      this thing is necessarily a proxy fronting other resources, and it
      has its own mapping from its local resources to remote ones?
      That's what makes the whole UDP and TCP thing work: it just needs
      to act like the same proxy for CoAP/UDP and CoAP/TCP as it does
      for CoAP/WS.

    

    
/a

    

    
_____

    
[1] RFC section 4.1: "SIP and SIPS URIs that are identical except
      for the scheme itself (e.g., sip:alice@example.com and
      sips:alice@example.com) refer to the same resource."

    
[2] This is, I think, architecturally consistent with what's
      already been done. In fact, this may already be the case; I can't
      quickly find language covering this.

    
[3] The operation on the TCP connection would need to use the
      same Message ID as the UDP attempts did, to ensure idempotency --
      it's possible that one or more of the transmitted UDP packets did
      make it to the remote node, but the ACKs did not arrive back at
      the originator. This does necessitate un-removing the Message ID
      field from TCP, but I think that's a Good Thing anyway.

  


--------------A7D05669EA17F455A37E499B--


From nobody Thu May 11 15:20:39 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FE5129411; Thu, 11 May 2017 15:20:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level: 
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 sAKRkfpF-yGN; Thu, 11 May 2017 15:20:27 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A4E8612951F; Thu, 11 May 2017 15:16:00 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4BMFtNo076338 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 May 2017 17:15:56 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell 
In-Reply-To: <285fccb8-de64-7ea6-1ad0-ac3408ec188c@nostrum.com>
Date: Thu, 11 May 2017 17:15:55 -0500
Cc: The IESG , Jaime Jimenez , core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1261A5A7-BE38-4EA3-AA43-8F29020BC2D0@nostrum.com>
References: <149451567392.16604.5915539927877259790.idtracker@ietfa.amsl.com> <285fccb8-de64-7ea6-1ad0-ac3408ec188c@nostrum.com>
To: Adam Roach 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 22:20:30 -0000

> On May 11, 2017, at 4:32 PM, Adam Roach  wrote:
>=20
> On 5/11/17 10:14, Ben Campbell wrote:
>> 2) It seems problematic to encode the transport choice in the URI =
scheme.
>>=20
>> Section 7 says "They are hosted in distinct namespaces because each =
URI scheme implies a distinct origin server." IIUC, this means any given =
resource can only be reached over a specific transport. That seems to =
break the idea of cross-transport proxies as discussed in section 7.
>>=20
>> It also does not seem to fit with a primary motivation for this =
draft. That is, one might want to use TCP because of local NAT/FW =
issues. But if there is a resource with a "coap" scheme, I cannot switch =
to TCP when I'm behind a problematic middlebox, and have an expectation =
of reaching the same resource.
>>=20
>=20
> I've been turning this over in my mind, and I think there are two =
problems here. The fundamental problem is that this document is encoding =
all kinds of protocol options into the URI scheme, which is an =
architecturally worrisome precedent for *all* URI-using protocols, =
current and future (by which I mean to say I don't think it's in CORE's =
unilateral purview to decide this is okay). This problem is compounded =
for CoAP in particular by treating the resource spaces associated with =
each scheme as distinct.
>=20
> I don't know whether the second issue is intentional or just a =
misunderstanding about whether it is allowable to have different schemes =
share a resource space (it is; cf. [1]), but I think we can come up with =
a solution to the first problem that allows the second to become moot.
>=20
> Looking to what we've done elsewhere in the IETF: considering the =
present moment, recent past, and near future, we effectively have six =
protocols in the wild for securely retrieving hypermedia across the =
Internet: HTTP 1.x, SPDY1, SPDY2, SPDY3, H2, and QUIC. Note that these =
protocols vary in syntax, semantics, and even transport-layer protocols. =
The URI schemes for these six different protocols are https, https, =
https, https, https, and https, respectively.
>=20
> I think that's a good model. One pleasant advantage of this model is =
that it completely eliminates the resource space issue I describe above
>=20
>=20
> Concretely, then, I propose that the URI schemes in this document be =
assigned as follows:
>=20
> For CoAP over TCP: coap
>=20
> For CoAP over TLS over TCP: coaps
>=20
> For CoAP over WS: coap
>=20
> For CoAP over WSS: coaps

I agree this appears to be the right model. I also recall Carsten =
mentioning elsewhere that the WG had made an earlier architectural =
decision to encode transport in the URLs. If that=E2=80=99s really the =
case, I=E2=80=99d be interested in hearing the reasoning behind it. I am =
skeptical that said reasoning would still hold in light of the =
architectural problems with doing so that have been identified .

>=20
>=20
> We then make UDP support mandatory to implement [2]. Now, let's talk =
about TCP. I'm leaving WebSockets out of this description for a moment, =
for reasons that I will explain later.
> The general process for accessing a CoAP resource would be: try to =
contact the remote node over UDP using a Confirmable message. After some =
reasonable timespan (I would propose just prior to the third =
transmission [second retransmission] of a message), if no ACK had been =
received, those nodes that support TCP would try to initiate a TCP =
connection (same host, same port, different transport) in parallel with =
the third UDP transmission. If the TCP connection succeeds, abandon the =
UDP attempts and start the transaction over on the TCP connection [3].
>=20
> Two additionally proposed minor details on this scheme that I think =
increase its appeal:=20
> 	=E2=80=A2 Nodes SHOULD cache, on a per-authority basis, whether =
UDP failed (but TCP worked) in the past; and, if such a failure was =
observed within a reasonable timeframe (hours or maybe days), use TCP =
instead of UDP for subsequent contact. This cache would be flushed =
whenever an IP address or routing table change is observed.
>=20
> 	=E2=80=A2 Nodes SHOULD allow configuration, both globally and on =
a per-authority basis, to skip the UDP attempt, so as to optimize =
connection times when UDP is administratively known to be nonviable or =
otherwise undesirable.

While this probably falls under your second bullet, I would include the =
possibility of an out-of-band mechanism to determine which transport the =
server supports/prefers. For example, DNS. In particular, Carsten =
mentioned draft-silverajan-core-coap-protocol-negotiation, which I =
understand might eventually offer such a mechanism.


>=20
> Turning now to WebSockets. As far as I can tell, the use of WebSockets =
is intended for a radically different deployment architecture than TCP =
-- it looks very much like TCP is meant to accommodate one or both of =
the parties being a constrained node, while WebSockets clearly is not: =
there is no way it makes sense for a constrained device to implement =
CoAP over WebSockets over HTTP on the conceit that it's simpler than =
using HTTP. So, this means that CoAP/WebSockets is intended to run only =
between two high-powered network hosts.
> (I'd like to take a quick pause to say that these radically different =
use cases suggest that it would be a Really Good Idea to split =
CoAP/WebSockets out into its own document that builds on top of the =
CoAP/TCP document.)
>=20
> Okay, so let's try to back out an architecture of *why* you have two =
non-contrained hosts using CoAP over WebSockets. Clearly, one of them is =
a browser, or you'd just use straight-up CoAP, right? In fact, the =
WebSockets client has to be the browser here. Further, if this is simply =
a browser sending and receiving data to and from a server, there are =
already a host of well-defined and broadly-deployed web technologies =
that they could use instead of CoAP.
>=20
> That means that the the only sensible conclusion is that the server is =
one of: (a) a proxy for constrained device(s) that the browser wants to =
contact, (b) a proxy for non-constrained device(s) that speak only CoAP =
(presumably so constrained devices can also connect to it), or (c) both. =
In all three cases, the proxy needs to have its own mapping that =
converts from resources at its own authority to the corresponding =
resources on the authority/ies for which is is serving as a proxy. This =
is important, and we'll come back to it later.
> As far as I can tell, that is the *only* context in which one might =
use CoAP/WebSockets. I mean, if there's some other architecture that =
makes sense here, I'd like to hear about it, but I think the logic above =
is pretty sound.
>=20
> In that context, then: a CoAP node implemented inside a web browser =
that gets ahold of a coap: or coaps: URI can do precisely one thing: use =
WebSockets to connect to the authority, using the CoAP/WebSockets =
semantics defined in this document. It can't try UDP or TCP, because =
these affordances aren't available from a web execution context. So if =
the authority in the URL doesn't support CoAP/WebSockets, the client is =
done.
> Now, what about other, non-browser nodes that happen to get ahold of =
these URIs? Well, now we're back to the fact that we made UDP MTI: these =
same servers are listening for normal CoAP over UDP (and maybe TCP, if =
they want to). So, remember how we said that this thing is necessarily a =
proxy fronting other resources, and it has its own mapping from its =
local resources to remote ones? That's what makes the whole UDP and TCP =
thing work: it just needs to act like the same proxy for CoAP/UDP and =
CoAP/TCP as it does for CoAP/WS.
> /a
> _____
>=20
> [1] RFC section 4.1: "SIP and SIPS URIs that are identical except for =
the scheme itself (e.g., sip:alice@example.com and =
sips:alice@example.com) refer to the same resource."
>=20
> [2] This is, I think, architecturally consistent with what's already =
been done. In fact, this may already be the case; I can't quickly find =
language covering this.
>=20
> [3] The operation on the TCP connection would need to use the same =
Message ID as the UDP attempts did, to ensure idempotency -- it's =
possible that one or more of the transmitted UDP packets did make it to =
the remote node, but the ACKs did not arrive back at the originator. =
This does necessitate un-removing the Message ID field from TCP, but I =
think that's a Good Thing anyway.
>=20


From nobody Fri May 12 03:01:29 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D8813149B; Fri, 12 May 2017 03:01:27 -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 oiJXw4Bvycot; Fri, 12 May 2017 03:01:25 -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 A34CD12EA94; Fri, 12 May 2017 02:48: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 v4C9m6Ln026400; Fri, 12 May 2017 11:48:06 +0200 (CEST)
Received: from [192.168.217.113] (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 3wPQBt0vy2zDHQJ; Fri, 12 May 2017 11:48:06 +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: <285fccb8-de64-7ea6-1ad0-ac3408ec188c@nostrum.com>
Date: Fri, 12 May 2017 11:48:05 +0200
Cc: Ben Campbell , The IESG , =?utf-8?Q?Jaime_Jim=C3=A9nez?= , core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org
X-Mao-Original-Outgoing-Id: 516275285.37576-1ec4a5e378acba2bdda77f58fe54e2cf
Content-Transfer-Encoding: quoted-printable
Message-Id: <2972BABD-430C-4C8D-A10D-E01A86034702@tzi.org>
References: <149451567392.16604.5915539927877259790.idtracker@ietfa.amsl.com> <285fccb8-de64-7ea6-1ad0-ac3408ec188c@nostrum.com>
To: Adam Roach 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 May 2017 10:01:27 -0000

Hi Adam,

thank you for this design sketch.

I fully support your quest to find a solution that avoids resource =
siloing.

I=E2=80=99ll call the approach of trying out several transports at once =
=E2=80=9Chappy bearing balls=E2=80=9D for now :-)
(We don=E2=80=99t have eyeballs in the IoT :-)

I=E2=80=99m still a bit nauseous from all that probing and caching (and =
negative caching).  It sounds like a big deployment headache, and a way =
to add indeterminism and inexplicable delays into something that could =
have been very simple.  Having a transport *hint* in the URI still =
sounds like a way to reduce this when the determination can already be =
made at the server side ([1]).

In the IoT space we typically have information from configuration and =
from places such as the Resource Directory that could enhance a URI with =
information about the best transport type to use for it (DNS is not =
always in use, by the way).  Baking this into the way transports are =
selected goes further down the road that a URI is not by itself all you =
need to make the request, but to a certain extent that has always been =
the case by including a DNS name (which may be one reason why DNS is not =
as much in use with CoAP).

What doesn=E2=80=99t work at all for me is deduplication across =
transports:

> [3] The operation on the TCP connection would need to use the same =
Message ID as the UDP attempts did, to ensure idempotency -- it's =
possible that one or more of the transmitted UDP packets did make it to =
the remote node, but the ACKs did not arrive back at the originator. =
This does necessitate un-removing the Message ID field from TCP, but I =
think that's a Good Thing anyway.

How is a server supposed to find out two messages that reach it over =
different transports are actually the same?
Sure, including message-IDs would be one thing (which are otherwise of =
no use in TCP).
But what about two clients happening to use the same message-ID?  The =
server would need to associate the copies of the request it got to the =
same client.  This would require that the client uses matching ephemeral =
ports for UDP and TCP, and I don=E2=80=99t know how to get this through =
NATs (which are one of the big use cases we are addressing).

So I would like to de-emphasize the happy bearing balls for =
non-idempotent requests =E2=80=94 there is usually something that a =
client wants to do with a server anyway before getting to those.

In summary: I like being able to do happy bearing balls.  I=E2=80=99d =
also like to be able to not use it, based on transport hints.

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

[1] It seems you have those transport hints in SIP.  But SIP doesn=E2=80=99=
t have to deal with URI resolution based on base URIs, so it has more =
freedom in putting parameters into the URI.  The reason our transport =
information is in the scheme is that we couldn=E2=80=99t find a better =
place.  I would love to hear there is.


From nobody Fri May 12 08:03:06 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFDED12ECED; Fri, 12 May 2017 08:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level: 
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 DBbZY4foFYJa; Fri, 12 May 2017 08:02:57 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D815F12EB6A; Fri, 12 May 2017 07:57:37 -0700 (PDT)
Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4CEvWom087716 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 12 May 2017 09:57:33 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local
To: Carsten Bormann 
Cc: Ben Campbell , The IESG , =?UTF-8?Q?Jaime_Jim=c3=a9nez?= , core-chairs@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org
References: <149451567392.16604.5915539927877259790.idtracker@ietfa.amsl.com> <285fccb8-de64-7ea6-1ad0-ac3408ec188c@nostrum.com> <2972BABD-430C-4C8D-A10D-E01A86034702@tzi.org>
From: Adam Roach 
Message-ID: <787b0d28-61e9-d3fa-f78c-fcdd25593213@nostrum.com>
Date: Fri, 12 May 2017 09:57:27 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.0
MIME-Version: 1.0
In-Reply-To: <2972BABD-430C-4C8D-A10D-E01A86034702@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 May 2017 15:03:00 -0000

On 5/12/17 04:48, Carsten Bormann wrote:
> Hi Adam,
>
> thank you for this design sketch.
>
> I fully support your quest to find a solution that avoids resource siloing.

To be clear, while that's a goal here, it's far from the primary goal. 
The high-order bit in my book is correctly dealing with what URI schemes 
actually mean, since that has implications well beyond CoAP.

> I鈥檒l call the approach of trying out several transports at once 鈥渉appy bearing balls鈥 for now :-)
> (We don鈥檛 have eyeballs in the IoT :-)
>
> I鈥檓 still a bit nauseous from all that probing and caching (and negative caching).

The caching is an optimization with obvious trade-offs, and I'm more 
than happy to leave it to implementations as to whether they think it's 
something they need.

>    It sounds like a big deployment headache, and a way to add indeterminism and inexplicable delays into something that could have been very simple.

As you correctly point out above, there are no eyeballs involved. I 
doubt that Things care about the occasional 15-second delay. In any 
case, the configuration I propose is intended to shortcut these delays 
if NATs are known to be a problem a priori.

>    Having a transport *hint* in the URI still sounds like a way to reduce this when the determination can already be made at the server side ([1]).
>
> In the IoT space we typically have information from configuration and from places such as the Resource Directory that could enhance a URI with information about the best transport type to use for it (DNS is not always in use, by the way).  Baking this into the way transports are selected goes further down the road that a URI is not by itself all you need to make the request, but to a certain extent that has always been the case by including a DNS name (which may be one reason why DNS is not as much in use with CoAP).

I really don't follow this paragraph.

> What doesn鈥檛 work at all for me is deduplication across transports:
>
>> [3] The operation on the TCP connection would need to use the same Message ID as the UDP attempts did, to ensure idempotency -- it's possible that one or more of the transmitted UDP packets did make it to the remote node, but the ACKs did not arrive back at the originator. This does necessitate un-removing the Message ID field from TCP, but I think that's a Good Thing anyway.
> How is a server supposed to find out two messages that reach it over different transports are actually the same?
> Sure, including message-IDs would be one thing (which are otherwise of no use in TCP).
> But what about two clients happening to use the same message-ID?  The server would need to associate the copies of the request it got to the same client.  This would require that the client uses matching ephemeral ports for UDP and TCP, and I don鈥檛 know how to get this through NATs (which are one of the big use cases we are addressing).
>
> So I would like to de-emphasize the happy bearing balls for non-idempotent requests 鈥 there is usually something that a client wants to do with a server anyway before getting to those.

It sounds like we can come up with something here, then -- perhaps 
UDP&TCP clients would be required to make first contact using a request 
that is inherently idempotent. (I mean, I have some other ideas about 
how we could perform deduplication, but I'm sure you'd find them 
distasteful for constrained implementations.)

> In summary: I like being able to do happy bearing balls.  I鈥檇 also like to be able to not use it, based on transport hints.

I'm fine with that in principle, but your transport hints can't be part 
of your URI scheme. That's just not what schemes mean.

/a


From nobody Fri May 12 14:17:18 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7291314BB; Fri, 12 May 2017 14:17:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.734
X-Spam-Level: 
X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 hLr7m4rT1McK; Fri, 12 May 2017 14:17:01 -0700 (PDT)
Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 0C359126DED; Fri, 12 May 2017 14:12:55 -0700 (PDT)
Received: from mail-qt0-f177.google.com (mail-qt0-f177.google.com [209.85.216.177]) by linode64.ducksong.com (Postfix) with ESMTPSA id 5AC0F3A0A2; Fri, 12 May 2017 17:12:53 -0400 (EDT)
Received: by mail-qt0-f177.google.com with SMTP id f55so9305115qta.3; Fri, 12 May 2017 14:12:53 -0700 (PDT)
X-Gm-Message-State: AODbwcBBxmndEuK8IDt6M4QYOtlV+mMbdjmctDRyNMnps/ZG8lbs8KYR kM+Atot/8MDE8wfBgeFzJbgFqLBcXA==
X-Received: by 10.200.40.193 with SMTP id j1mr6158200qtj.186.1494623573075; Fri, 12 May 2017 14:12:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.178.74 with HTTP; Fri, 12 May 2017 14:12:52 -0700 (PDT)
In-Reply-To: <2D57FF92-3A56-43BC-A815-27801E31F770@tzi.org>
References: <149179722452.3118.982908107963516290@ietfa.amsl.com> <5E5238DC-B835-4BDF-B50D-8D594A46C4D4@tzi.org> <767F913A-586B-42A2-B021-F9AC5C478702@mnot.net> <2D57FF92-3A56-43BC-A815-27801E31F770@tzi.org>
From: Patrick McManus 
Date: Fri, 12 May 2017 17:12:52 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Carsten Bormann 
Cc: Mark Nottingham , art@ietf.org, draft-ietf-core-coap-tcp-tls.all@ietf.org,  IETF Discussion Mailing List , core@ietf.org
Content-Type: multipart/alternative; boundary="001a11406bf6257010054f5a2b50"
Archived-At: 
Subject: Re: [core] [art] Artart last call review of draft-ietf-core-coap-tcp-tls-07
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 May 2017 21:17:04 -0000

--001a11406bf6257010054f5a2b50
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I have a few thoughts on this draft too.

6455-Websockets was a point in time solution for a problem that was solved
later and better by HTTP/2 (RFC 7540) with the introduction of parallelism,
multiplexing, and non 1:1 bi-directional message capabilities (which 6455
only solves 1/3 of).. 6455 is now considered historical and legacy cruft by
many. I don't know of anyone that would think that if 6455 did not exist it
should be introduced into today's ecosystem. (we would still want a
dev-facing interface doing some of the same things as websockets at a js
layer, but it would not be implemented on the wire 6455 style.)

If the motivation of the websockets-coap binding is to deal with
bi-directional problems better than HTTP/1, the answer to me seems to be to
use HTTP/2 (and maybe an extension of the existing http mapping) rather
than building a parallel system of gateways, proxies, and tunnels on top of
6455. It is unfortunate enough (perhaps unavoidable?) that we have a
parallel stack of constrained protocols without building a gatewaying
system between them rooted in legacy baggage.

The draft as much as acknowledges this with some not totally convincing
handwaving (that is not meant pejoratively - I've been known to hand wave
:))

Although HTTP/2 could also potentially address these requirements,
there would be
   additional costs and delays introduced by such a transition.
   Currently, there are also fewer HTTP/2 implementations available for
   constrained devices in comparison to CoAP.

The aspects of the proposed solution that would seem to pose the largest
challenges for constrained devices, (tcp and tls) are also present in
wss:// as well - which begs the question of whether this is designing a
nominally constrained-device ecosystem actually for
not-so-badly-constrained gateways and they should be using our primary
security, application, and transport standards directly. This parallel
stack has to end somewhere, right?

also, if you stay within the semantics of http, but require 7540 or its
successors for reasons of performance, you will pick up quic for free when
we get there - which is just a specific instance of the general argument
with forking standards.

lastly I think the security considerations (both in that section and
elsewhere) could use some work.

The purpose of websockets-6455 is to deploy a mechanism, consistent with
the web security model, for non-privileged javascript to be able to
communicate using communication patterns that do not fit into the HTTP/1
request/reply pattern well. To be consistent with that security model a
websockets end point needs to opt into doing websockets, potentially doing
a particular sub-protocol, and be expecting this request to have been
triggered by a particular Origin.

The net effect is to prohibit random javascript from the web from spraying
around arbitrary TCP streams behind every user agent's firewall, or
otherwise generating arbitrary botnets (beyond what is allowed by SOP
anyhow).

The coap-tcp-tls-websockets forward-proxy model builds an arbitrary gateway
from websockets to coap based on proxy-uri and would seem to run afoul of
the security model by spraying arbitrary coap around instead of arbitrary
tcp :).. Reverse proxy models, being locked down to particular origins,
work better.

(and as a final nit the websocket handshake examples do not have an Origin
request header as required by 6455 for browsers, and I think browsers are
in scope of this document - but thinking and talking about Origin is a key
part of when websockets is and is not appropriate.).

-Patrick



On Wed, May 10, 2017 at 12:31 AM, Carsten Bormann  wrote:

>
> > On May 9, 2017, at 23:30, Mark Nottingham  wrote:
> >
> > To close this loop -- the change in -08 isn't sufficiently prominent
> IME; while the general nature of the change is listed in the Abstract, th=
e
> actual normative text is very hard to find.
>
> Certainly, let=E2=80=99s see what the IESG decides here.
>
> > Given that this is a pretty fundamental change in the operation of a UR=
I
> scheme, I'd think it at least deserves its own section, if not a separate
> document.
>
> I don=E2=80=99t agree that this is such a fundamental change here =E2=80=
=94 the
> /.well-known name space in the URI already was special (by the fact that =
ws
> URIs are mapped to http URIs, which do have /.well-known reserved already=
).
>
> But that doesn=E2=80=99t matter, we should find the best editorial way to=
 document
> making the well-known URI concept available to WebSocket URIs.
>
> Gr=C3=BC=C3=9Fe, Carsten
>
>

--001a11406bf6257010054f5a2b50
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I have a few thoughts on this draft too.

6455-Websockets was a point in time solution for a problem=
 that was solved later and better by HTTP/2 (RFC 7540) with the introductio=
n of parallelism, multiplexing, and non 1:1 bi-directional message capabili=
ties (which 6455 only solves 1/3 of).. 6455 is now considered historical an=
d legacy cruft by many. I don't know of anyone that would think that if=
 6455 did not exist it should be introduced into today's ecosystem. (we=
 would still want a dev-facing interface doing some of the same things as w=
ebsockets at a js layer, but it would not be implemented on the wire 6455 s=
tyle.)

If the motivation of the websockets-coa=
p binding is to deal with bi-directional problems better than HTTP/1, the a=
nswer to me seems to be to use HTTP/2 (and maybe an extension of the existi=
ng http mapping) rather than building a parallel system of gateways, proxie=
s, and tunnels on top of 6455. It is unfortunate enough (perhaps unavoidabl=
e?) that we have a parallel stack of constrained protocols without building=
 a gatewaying system between them rooted in legacy baggage.
<=
br>
The draft as much as acknowledges this with some not totally =
convincing handwaving (that is not meant pejoratively - I've been known=
 to hand wave :))
Although HTTP/=
2 could also potentially address these requirements, there would be
   additional costs and delays introduced by such a transition.
   Currently, there are also fewer HTTP/2 implementations available for
   constrained devices in comparison to CoAP.
 T=
he aspects of the proposed solution that would seem to pose the largest cha=
llenges for constrained devices, (tcp and tls) are also present in wss:// a=
s well - which begs the question of whether this is designing a nominally c=
onstrained-device ecosystem actually for not-so-badly-constrained gateways =
and they should be using our primary security, application, and transport s=
tandards directly. This parallel stack has to end somewhere, right?

also, if you stay within the semantics of http, but r=
equire 7540 or its successors for reasons of performance, you will pick up =
quic for free when we get there - which is just a specific instance of the =
general argument with forking standards.

lastly I =
think the security considerations (both in that section and elsewhere) coul=
d use some work.

The purpose of websockets-64=
55 is to deploy a mechanism, consistent
 with the web security model, for non-privileged javascript to be able=20
to communicate using communication patterns that do not fit into the=20
HTTP/1 request/reply pattern well. To be consistent with that security=20
model a websockets end point needs to opt into doing websockets,=20
potentially doing a particular sub-protocol, and be expecting this=20
request to have been triggered by a particular Origin.

=

The
 net effect is to prohibit random javascript from the web from spraying=20
around arbitrary TCP streams behind every user agent's firewall, or=20
otherwise generating arbitrary botnets (beyond what is allowed by SOP=20
anyhow).

The coap-tcp-tls-websockets=20
forward-proxy model builds an arbitrary gateway from websockets to coap=20
based on proxy-uri and would seem to run afoul of the security model by=20
spraying arbitrary coap around instead of arbitrary tcp :).. Reverse=20
proxy models, being locked down to particular origins, work better.

(and as
 a final nit the websocket handshake examples do not have an Origin request=
=20
header as required by 6455 for browsers, and I think browsers are in=20
scope of this document - but thinking and talking about Origin is a key par=
t of when websockets is and is not appropriate.).

-Patrick



On Wed, May 10, 2017 at 12:31 AM, Ca=
rsten Bormann <cabo@tzi.org> wrote:


> On May 9, 2017, at 23:30, Mark Nottingham <mnot@mnot.net> wrote:

>

> To close this loop -- the change in -08 isn't sufficiently promine=
nt IME; while the general nature of the change is listed in the Abstract, t=
he actual normative text is very hard to find.



Certainly, let=E2=80=99s see what the IESG decides here.



> Given that this is a pretty fundamental change in the operation of a U=
RI scheme, I'd think it at least deserves its own section, if not a sep=
arate document.



I don=E2=80=99t agree that this is such a fundamental change here =
=E2=80=94 the /.well-known name space in the URI already was special (by th=
e fact that ws URIs are mapped to http URIs, which do have /.well-known res=
erved already).



But that doesn=E2=80=99t matter, we should find the best editorial way to d=
ocument making the well-known URI concept available to WebSocket URIs.



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







--001a11406bf6257010054f5a2b50--


From nobody Sat May 13 09:17:43 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADD212ACAF for ; Sat, 13 May 2017 09:17:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 bh1-t7nsWaJP for ; Sat, 13 May 2017 09:17:40 -0700 (PDT)
Received: from smtp109.iad3a.emailsrvr.com (smtp109.iad3a.emailsrvr.com [173.203.187.109]) (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 AF4B5129415 for ; Sat, 13 May 2017 09:15:03 -0700 (PDT)
Received: from smtp38.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp38.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id CC426587A; Sat, 13 May 2017 12:15:02 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp38.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 5BBBE582B;  Sat, 13 May 2017 12:15:02 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.1.3.67] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Sat, 13 May 2017 12:15:02 -0400
From: Cullen Jennings 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Sat, 13 May 2017 10:15:01 -0600
Cc: =?utf-8?Q?Christian_Ams=C3=BCss?= , =?utf-8?Q?Ari_Ker=C3=A4nen?= 
To: core 
Message-Id: <06D60C67-7B3F-4A7B-A683-763B28F8620B@iii.ca>
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Subject: [core] SENML proposal: Allow base attributes in any Record
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 May 2017 16:17:41 -0000

We had a good call about URI , URL, and how this all links together but =
one of the discussion made us realize that for aggregated collections, =
the current spec is less than ideal and that problem reflected up in =
multiple ways. So here is the proposal ...=20

We got back to allowing base attributes to occur in any record and be =
the base value any record after that up to the point where the base =
attribute gets set to something else. Take the example of a sensor with =
IP 2001:db8::2 that is an indoor temperature and humidity sensor that =
also aggregates in the reading from a similar outdoor device at IP =
2001:db8::1. You could represent this wth=20

   [
     {"bt":1.320078429e+09,
      "n":"2001:db8::2-temperature","u":"Cel","v":25.2},
     {"n":"2001:db8::2-humidity","u":"%RH","v":30},
     {"n":"2001:db8::1-temperature","u":"Cel","v":12.3},
     {"n":"2001:db8::1-humidity","u":"%RH","v":67}
 ]

Note the IP part of the name is different in the last two records =
because that is the unique sensor they came from.

But it would be nicer to be able to say=20


 [
     {"bn":"2001:db8::2","bt":1.320078429e+09,
      "n":"temperature","u":"Cel","v":25.2},
     {"n":"humidity","u":"%RH","v":30},
     {"bn":"2001:db8::1",
      "n":"temperature","u":"Cel","v":12.3},
     {"n":"humidity","u":"%RH","v":67}
 ]

This gives us better compression because we can use a base name for the =
common IP part of the sensor name.=20

A very common use case for core is aggregating measurements into one =
pack so I think this is an important use case. It also resolves the =
issue we were having with lining up with names and URL which is how we =
realized we had this issue.=20

So my proposal is go back to how we used to have it and allow base =
attributes in Records other than than the first Record. I realize this =
is flip flopping on a previous decision but I think we forgot about this =
use case when we went to base values only in the first Record.=20

Let me know if you see any problems with this.=20

Thanks,=20
Cullen











From nobody Sun May 14 21:37:02 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C91120721 for ; Sun, 14 May 2017 21:37:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.698
X-Spam-Level: 
X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 Jpgtv0n2X0_T for ; Sun, 14 May 2017 21:36:59 -0700 (PDT)
Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5BC1200F3 for ; Sun, 14 May 2017 21:33:02 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1494822778; h=from:subject:to:date:message-id; bh=1MS65/e4T08al4cJ3WOVQSHWT6CcOdZYnYgUMrpiAtM=; b=ilL07bNNCSBJ/b+vOJj80Qq4U1mDhLZZOvXeHVw/vNEYTB6V6ejf5Uw8ERSXHowjn1Irz9B/88w Mx+Z9+LdNMPzoSuTDRi9oISgPDIP/tdXOweXL7xvhgEjcLagtlWPL/PJgFbV86xzuucZP+EnmxBoH 3dUDe2uNXYHypoZLGTeIZQ9KDW+Mhi6NpWBBg/W7wmm8FmwR5fpeED5kFLI1URhsveXQRUPJc0TCu qHdy2edg8TGRfstzFBxgkS39c8D9T80pBvbhxC3ist3qTTU3LeZGGWtgvr8y8qCTZ7nwebh5LHkg4 KN9L6fU36nOSrXQpYiqdFGZuo4H6D6NH9EFw==
Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 14 May 2017 21:32:58 -0700
Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 14 May 2017 21:32:30 -0700
From: Jim Schaad 
To: 
Date: Sun, 14 May 2017 21:21:44 -0700
Message-ID: <003501d2cd32$c4417a10$4cc46e30$@augustcellars.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdLNMilfa5ceDMFXSzWGbktOvFqaPw==
X-Originating-IP: [24.21.96.37]
Archived-At: 
Subject: [core] DTLS and Epochs
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 04:37:00 -0000

I am working on getting my DTLS code to work correctly and I have come
across something that I do not understand.  I did not see any messages in
the mailing list that dealt with this so I would like to get an explanation
if possible.

RFC 7252 states that a response is not to be correlated with a request
unless the message id, the DTLS session and the DTLS epoch are the same.  I
can understand the reasoning behind the id and session being the same,
however I am unsure of the reason that the epoch would need to be the same
as well.  I cannot see of a reason why the epoch should matter.  The
security session is still the same.  I could understand that there would be
a reason to kill an association if additional client or server
authentication information had been passed along, but while that would
change the epoch, an epoch can change just because enough messages have been
sent over the pipe.

Can somebody please explain the reasoning to me.

Jim



From nobody Mon May 15 05:07:31 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1338124BE8 for ; Mon, 15 May 2017 05:07:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.801
X-Spam-Level: 
X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5] 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 eMA3BjW1E2oX for ; Mon, 15 May 2017 05:07:27 -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 1F8F9129A8F for ; Mon, 15 May 2017 05:02:40 -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 v4FC2bH5005967 for ; Mon, 15 May 2017 14:02:37 +0200 (CEST)
Received: from mail-it0-f47.google.com (mail-it0-f47.google.com [209.85.214.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wRK2j1XN8zDJK2 for ; Mon, 15 May 2017 14:02:37 +0200 (CEST)
Received: by mail-it0-f47.google.com with SMTP id o5so41268710ith.1 for ; Mon, 15 May 2017 05:02:37 -0700 (PDT)
X-Gm-Message-State: AODbwcBv8g69OJj9O0/+LBEZ9asXxTAVTXJraABpNvEEtdAGkxeTUTG4 iHkFcNLyxpvYWVKDNz2vcqhoxFq4Tw==
X-Received: by 10.36.120.23 with SMTP id p23mr5122107itc.106.1494849756071; Mon, 15 May 2017 05:02:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.163.87 with HTTP; Mon, 15 May 2017 05:01:55 -0700 (PDT)
In-Reply-To: <003501d2cd32$c4417a10$4cc46e30$@augustcellars.com>
References: <003501d2cd32$c4417a10$4cc46e30$@augustcellars.com>
From: Klaus Hartke 
Date: Mon, 15 May 2017 14:01:55 +0200
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Jim Schaad 
Cc: "core@ietf.org WG" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [core] DTLS and Epochs
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 12:07:30 -0000

Hi Jim,

the requirement was added for the case that the epoch changes due to
client or server authentication.

Example:

      1. A client connects to a server using DTLS. The server
         authenticates with a server certificate; the client
         is unauthenticated.

      2. The client sends a request that requires the client
         to be authenticated.

      3. The server requests the client to authenticate.

      4. The client authenticates with a client certificate;
         a new epoch starts.

      5. The server processes the request, assuming it comes
         from the now authenticated client. Oops!

Requiring that the request is sent in the same epoch as the response
prevents this. It seems the language in the RFC was made too broad
when trying to say that, though. An erratum could make it more
precise.

Klaus


On 15 May 2017 at 06:21, Jim Schaad  wrote:
> I am working on getting my DTLS code to work correctly and I have come
> across something that I do not understand.  I did not see any messages in
> the mailing list that dealt with this so I would like to get an explanation
> if possible.
>
> RFC 7252 states that a response is not to be correlated with a request
> unless the message id, the DTLS session and the DTLS epoch are the same.  I
> can understand the reasoning behind the id and session being the same,
> however I am unsure of the reason that the epoch would need to be the same
> as well.  I cannot see of a reason why the epoch should matter.  The
> security session is still the same.  I could understand that there would be
> a reason to kill an association if additional client or server
> authentication information had been passed along, but while that would
> change the epoch, an epoch can change just because enough messages have been
> sent over the pipe.
>
> Can somebody please explain the reasoning to me.
>
> Jim


From nobody Mon May 15 05:54:38 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC3C12EAAB for ; Mon, 15 May 2017 05:54:38 -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_40=-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 TjN0abfkq943 for ; Mon, 15 May 2017 05:54:37 -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 5C1B412EAAC for ; Mon, 15 May 2017 05:50:04 -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 v4FCnXlY012659; Mon, 15 May 2017 14:49:33 +0200 (CEST)
Received: from [192.168.217.113] (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 3wRL4s384LzDGn6; Mon, 15 May 2017 14:49:33 +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, 15 May 2017 14:49:32 +0200
Cc: "core@ietf.org WG" 
X-Mao-Original-Outgoing-Id: 516545372.737919-8d2c0b18ae98378352f0b4896fe0b1e5
Content-Transfer-Encoding: quoted-printable
Message-Id: <093E78D2-431A-47E4-81C9-7B37B8B14E90@tzi.org>
References: <003501d2cd32$c4417a10$4cc46e30$@augustcellars.com> 
To: Jim Schaad 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [core] DTLS and Epochs
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 12:54:38 -0000

Hi Jim,

Klaus described one of several conceivable ways in which an epoch change =
might change the security state enough that simply ignoring it at the =
application layer creates problems.

When we designed CoAP, we were thinking about ways to handle this set of =
issues.
In the end, DTSTTCPW won.
(=E2=80=9CWork=E2=80=9D here means =E2=80=9Cis arguably secure, and =
still doesn=E2=80=99t completely break secure applications=E2=80=9D.)

Anything more powerful that what we have now probably requires =
substantial analysis.
I would not be comfortable with fixing this at the errata level =E2=80=94 =
the above decision very much was not an erratum.

I could imagine that we fix this together with providing the =
well-requested feature of session resumption after an IP address =
changed.

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


From nobody Mon May 15 06:03:40 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF152127137 for ; Mon, 15 May 2017 06:03:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.7
X-Spam-Level: 
X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5] 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 H3fxkhoFTdTX for ; Mon, 15 May 2017 06:03:38 -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 9AF57126CD6 for ; Mon, 15 May 2017 05:57:52 -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 v4FCvodV019575 for ; Mon, 15 May 2017 14:57:50 +0200 (CEST)
Received: from mail-it0-f48.google.com (mail-it0-f48.google.com [209.85.214.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wRLGP52zMzDGnP for ; Mon, 15 May 2017 14:57:49 +0200 (CEST)
Received: by mail-it0-f48.google.com with SMTP id o5so42125004ith.1 for ; Mon, 15 May 2017 05:57:49 -0700 (PDT)
X-Gm-Message-State: AODbwcA4k18Z3/qxy/5U5HFw/wPxnkzNMkaWZJEmHFW/aJj0fIQOXnSL UwGC0QzeuW7aAZRNIeqNrxmTwZU+TA==
X-Received: by 10.36.74.82 with SMTP id k79mr5094979itb.58.1494853068624; Mon, 15 May 2017 05:57:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.163.87 with HTTP; Mon, 15 May 2017 05:57:08 -0700 (PDT)
In-Reply-To: <093E78D2-431A-47E4-81C9-7B37B8B14E90@tzi.org>
References: <003501d2cd32$c4417a10$4cc46e30$@augustcellars.com>  <093E78D2-431A-47E4-81C9-7B37B8B14E90@tzi.org>
From: Klaus Hartke 
Date: Mon, 15 May 2017 14:57:08 +0200
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Carsten Bormann 
Cc: Jim Schaad , "core@ietf.org WG" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [core] DTLS and Epochs
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 13:03:39 -0000

Carsten Bormann wrote:
> Anything more powerful that what we have now probably requires substantial analysis.

+1

Klaus


From nobody Mon May 15 07:37:14 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C02612EAB7 for ; Mon, 15 May 2017 07:37:13 -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_40=-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 3HvfqGe_2qki for ; Mon, 15 May 2017 07:37:12 -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 6A47B129B40 for ; Mon, 15 May 2017 07:32:27 -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 v4FEWKKf008483 for ; Mon, 15 May 2017 16:32:20 +0200 (CEST)
Received: from [192.168.217.113] (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 3wRNMS0YJSzDGrs; Mon, 15 May 2017 16:32:20 +0200 (CEST)
From: Carsten Bormann 
Content-Type: text/plain; charset=utf-8
X-Mao-Original-Outgoing-Id: 516551539.272591-4d33a5cb0d705da8b73a7181c053504d
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 15 May 2017 16:32:19 +0200
Message-Id: <76EA187B-4A41-4363-B49E-75064626190A@tzi.org>
To: core 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 14:37:13 -0000

I have generate a first editors=E2=80=99 draft of what might become =
draft-ietf-core-coap-tcp-tls-09, addressing IESG input on the draft.
(This draft addresses DISCUSSes, but almost no COMMENTS; see =
https://github.com/core-wg/coap-tcp-tls/issues for an overview what else =
needs to be done.)

This has a bit of Brownian motion (default ports etc.), but also one =
important change:

IESG members have asked us to stop proliferating URI schemes, and as a =
result the draft remains with coap:// and coaps:// for all new =
transports.

Please see:

=
https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-coap-tcp-tls&url2=3D=
https://raw.githubusercontent.com/core-wg/coap-tcp-tls/gh-pages/iesg/draft=
-ietf-core-coap-tcp-tls.txt

for the changes from -08, and

https://core-wg.github.io/coap-tcp-tls/iesg/

for a full document.

For example,

https://core-wg.github.io/coap-tcp-tls/iesg/#rfc.section.7.8

is a new section, but many other sections concerned with URIs and URI =
schemes have received changes.

It is important if the WG can live with this change, or whether we need =
to incur further delay pushing back on this change.
Please let us know!

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


From nobody Mon May 15 07:55:11 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C5412947E for ; Mon, 15 May 2017 07:55:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 962cc-pg-avI for ; Mon, 15 May 2017 07:55:06 -0700 (PDT)
Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [IPv6:2a03:cc00:ff0:100::2]) (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 A9715128CFF for ; Mon, 15 May 2017 07:52:41 -0700 (PDT)
Received: from vsmta13.fe.internet.bosch.com (unknown [10.4.98.53]) by imta23.fe.bosch.de (Postfix) with ESMTP id 0C83C158014F for ; Mon, 15 May 2017 16:52:39 +0200 (CEST)
Received: from SI-MBX1027.de.bosch.com (vsgw23.fe.internet.bosch.com [10.4.98.23]) by vsmta13.fe.internet.bosch.com (Postfix) with ESMTP id AC64B2E405AF for ; Mon, 15 May 2017 16:52:38 +0200 (CEST)
Received: from FE-MBX1027.de.bosch.com (10.3.230.85) by SI-MBX1027.de.bosch.com (10.3.230.41) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 15 May 2017 16:52:38 +0200
Received: from FE-MBX1027.de.bosch.com ([fe80::e193:5977:194:af]) by FE-MBX1027.de.bosch.com ([fe80::e193:5977:194:af%16]) with mapi id 15.00.1236.000; Mon, 15 May 2017 16:52:38 +0200
From: "Kraus Achim (INST/ECS4)" 
To: "core@ietf.org" 
Thread-Topic: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input
Thread-Index: AQHSzYjEmLAfuDCvqUe/TlUr6Et4PaH1eM4g
Date: Mon, 15 May 2017 14:52:37 +0000
Message-ID: 
References: <76EA187B-4A41-4363-B49E-75064626190A@tzi.org>
In-Reply-To: <76EA187B-4A41-4363-B49E-75064626190A@tzi.org>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.22.82.228]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-23070.006
X-TMASE-MatchedRID: 8+bhjh9TQnE4HKI/yaqRmxLuW4a3q2WGkos2tunL8DRnnK6mXN72m1MZ FM5H6MXK2n1rQvEoKbzSVx1C+DAdvSuqPI5HBA4g1poecQqOJjApxoenBUOrIUl0DwbiOKLRIac +Jx3wkJE7qYsdU3vhDx3Ju+pmIrzGmNrlAIQG7r/M1jffIgQXhv1SyBI1YaMgtXl9IxEPXOpBnf R7YW+CYyN6s2o51UEPbDn5XlsLysdDeuA2fujoFcAmcZEx8XHJIfyQNHR2naZo5YsPsbyLXctX/ 2vvKRGk1fOVBra3tGe+ofRWlf2DTCyTPIfegtsCLRNiY8cLz7g7UrmIzxDooMzvOkSymob/Olt9 1MBw1ebi8zVgXoAltj2Xsf5MVCB15A2KZtey50PdB/CxWTRRu4as+d5/8j56e03i/bh1M5A9Lyi Cb8acVo4o6Gblle81QT7od4r7AZafPxyRyYpT4Q==
Archived-At: 
Subject: Re: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 14:55:09 -0000

SGkgQ2Fyc3RlbiwNCg0KPiBJRVNHIG1lbWJlcnMgaGF2ZSBhc2tlZCB1cyB0byBzdG9wIHByb2xp
ZmVyYXRpbmcgVVJJIHNjaGVtZXMsIGFuZCBhcyBhIHJlc3VsdCB0aGUgZHJhZnQgcmVtYWlucyB3
aXRoIGNvYXA6Ly8gYW5kIGNvYXBzOi8vIGZvciBhbGwgbmV3IHRyYW5zcG9ydHMuDQoNCkFzc3Vt
aW5nIGEgc3lzdGVtLCB3aGljaCBzdXBwb3J0cyBDb0FQIG92ZXIgVURQIGFuZCBvdmVyIFRDUCwg
aG93IHNob3VsZCBzdWNoIGEgc3lzdGVtIHNlbGVjdCwgaWYgVURQIG9yIFRDUCBpcyBpbnRlbmRl
ZCB0byBiZSB1c2VkIGZvciBhIGdpdmVuIGRlc3RpbmF0aW9uPw0KDQpNaXQgZnJldW5kbGljaGVu
IEdyw7zDn2VuIC8gQmVzdCByZWdhcmRzDQoNCiBBY2hpbSBLcmF1cw0KDQooSU5TVC9FQ1M0KSAN
CkJvc2NowqBTb2Z0d2FyZSBJbm5vdmF0aW9uc8KgR21iSCB8IFN0dXR0Z2FydGVyIFN0cmHDn2Ug
MTMwIHwgNzEzMzIgV2FpYmxpbmdlbiB8IEdFUk1BTlkgfCB3d3cuYm9zY2gtc2kuY29tDQoNClNp
dHo6IEJlcmxpbiwgUmVnaXN0ZXJnZXJpY2h0OiBBbXRzZ2VyaWNodCBDaGFybG90dGVuYnVyZzsg
SFJCIDE0ODQxMSBCIA0KR2VzY2jDpGZ0c2bDvGhydW5nOiBEci4tSW5nLiBSYWluZXIgS2FsbGVu
YmFjaCwgTWljaGFlbCBIYWhuIA0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy
b206IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDYXJz
dGVuIEJvcm1hbm4NClNlbnQ6IE1vbnRhZywgMTUuIE1haSAyMDE3IDE2OjMyDQpUbzogY29yZSA8
Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFtjb3JlXSBFZGl0b3JzJyBkcmFmdCBvZiBjaGFuZ2Vz
IHRvIGRyYWZ0LWlldGYtY29yZS1jb2FwLXRjcC10bHMtMDggYWZ0ZXIgSUVTRyBpbnB1dA0KDQpJ
IGhhdmUgZ2VuZXJhdGUgYSBmaXJzdCBlZGl0b3Jz4oCZIGRyYWZ0IG9mIHdoYXQgbWlnaHQgYmVj
b21lIGRyYWZ0LWlldGYtY29yZS1jb2FwLXRjcC10bHMtMDksIGFkZHJlc3NpbmcgSUVTRyBpbnB1
dCBvbiB0aGUgZHJhZnQuDQooVGhpcyBkcmFmdCBhZGRyZXNzZXMgRElTQ1VTU2VzLCBidXQgYWxt
b3N0IG5vIENPTU1FTlRTOyBzZWUgaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvY29hcC10Y3At
dGxzL2lzc3VlcyBmb3IgYW4gb3ZlcnZpZXcgd2hhdCBlbHNlIG5lZWRzIHRvIGJlIGRvbmUuKQ0K
DQpUaGlzIGhhcyBhIGJpdCBvZiBCcm93bmlhbiBtb3Rpb24gKGRlZmF1bHQgcG9ydHMgZXRjLiks
IGJ1dCBhbHNvIG9uZSBpbXBvcnRhbnQgY2hhbmdlOg0KDQpJRVNHIG1lbWJlcnMgaGF2ZSBhc2tl
ZCB1cyB0byBzdG9wIHByb2xpZmVyYXRpbmcgVVJJIHNjaGVtZXMsIGFuZCBhcyBhIHJlc3VsdCB0
aGUgZHJhZnQgcmVtYWlucyB3aXRoIGNvYXA6Ly8gYW5kIGNvYXBzOi8vIGZvciBhbGwgbmV3IHRy
YW5zcG9ydHMuDQoNClBsZWFzZSBzZWU6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlm
Zj91cmwxPWRyYWZ0LWlldGYtY29yZS1jb2FwLXRjcC10bHMmdXJsMj1odHRwczovL3Jhdy5naXRo
dWJ1c2VyY29udGVudC5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvZ2gtcGFnZXMvaWVzZy9kcmFm
dC1pZXRmLWNvcmUtY29hcC10Y3AtdGxzLnR4dA0KDQpmb3IgdGhlIGNoYW5nZXMgZnJvbSAtMDgs
IGFuZA0KDQpodHRwczovL2NvcmUtd2cuZ2l0aHViLmlvL2NvYXAtdGNwLXRscy9pZXNnLw0KDQpm
b3IgYSBmdWxsIGRvY3VtZW50Lg0KDQpGb3IgZXhhbXBsZSwNCg0KaHR0cHM6Ly9jb3JlLXdnLmdp
dGh1Yi5pby9jb2FwLXRjcC10bHMvaWVzZy8jcmZjLnNlY3Rpb24uNy44DQoNCmlzIGEgbmV3IHNl
Y3Rpb24sIGJ1dCBtYW55IG90aGVyIHNlY3Rpb25zIGNvbmNlcm5lZCB3aXRoIFVSSXMgYW5kIFVS
SSBzY2hlbWVzIGhhdmUgcmVjZWl2ZWQgY2hhbmdlcy4NCg0KSXQgaXMgaW1wb3J0YW50IGlmIHRo
ZSBXRyBjYW4gbGl2ZSB3aXRoIHRoaXMgY2hhbmdlLCBvciB3aGV0aGVyIHdlIG5lZWQgdG8gaW5j
dXIgZnVydGhlciBkZWxheSBwdXNoaW5nIGJhY2sgb24gdGhpcyBjaGFuZ2UuDQpQbGVhc2UgbGV0
IHVzIGtub3chDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3Jn
DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg==


From nobody Mon May 15 08:21:29 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5857F1294BD for ; Mon, 15 May 2017 08:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5] 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 d2teDIBXqLB0 for ; Mon, 15 May 2017 08:21:24 -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 92098127333 for ; Mon, 15 May 2017 08:16:27 -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 v4FFGOiU012892 for ; Mon, 15 May 2017 17:16:24 +0200 (CEST)
Received: from mail-it0-f51.google.com (mail-it0-f51.google.com [209.85.214.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wRPLH6rywzDGsm for ; Mon, 15 May 2017 17:16:23 +0200 (CEST)
Received: by mail-it0-f51.google.com with SMTP id g126so70543758ith.0 for ; Mon, 15 May 2017 08:16:23 -0700 (PDT)
X-Gm-Message-State: AODbwcB9zV/FSop82eKZquyDuG2zqfn8TyWAdnLMgoQuAmNOiUKkGMLn oZy5CuWHYl3Gp/LD1wpXPfESV9XFsA==
X-Received: by 10.36.75.12 with SMTP id q12mr5810897ita.34.1494861382790; Mon, 15 May 2017 08:16:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.163.87 with HTTP; Mon, 15 May 2017 08:15:42 -0700 (PDT)
In-Reply-To: 
References: <76EA187B-4A41-4363-B49E-75064626190A@tzi.org> 
From: Klaus Hartke 
Date: Mon, 15 May 2017 17:15:42 +0200
X-Gmail-Original-Message-ID: 
Message-ID: 
To: "core@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 15:21:26 -0000

Kraus Achim (INST/ECS4) wrote:
> Assuming a system, which supports CoAP over UDP and over TCP, how should such a system select, if UDP or TCP is intended to be used for a given destination?

This one is even more fun:

    coap://2259499800/path/to/resource

Is this CoAP over UDP or TCP to a server with IP address 134.173.59.24
(there are URI parsers that accept "dotless" IPv4 addresses) or CoAP
over SMS to a server with phone number +225-949-9800?

Klaus


From nobody Mon May 15 08:44:28 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BEB12EAE7 for ; Mon, 15 May 2017 08:44:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.602
X-Spam-Level: 
X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 3xEViNEzQSVR for ; Mon, 15 May 2017 08:44:22 -0700 (PDT)
Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669A5129461 for ; Mon, 15 May 2017 08:37:48 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1494862666; h=from:subject:to:date:message-id; bh=nYk7yrBV6e6ZG7OkNypXLd8f+p/sk2dAoj0ZFvmHlXw=; b=D8UKXPSMHwPFxXZgsr5od9rqhHHJp41EGqhTIq4g0a3SPhbsO+kLh31uDvUkaoCuuKmyFRUkSnv jQ5OGeEQyxJHAzDUYkhHBjLqknuUwfJYXMTEXWQn3VLrHed17OKZOJXJtXL0gOZy4B6M9jteGcLqd 0Gt15PrkAFXDoNvvsAq8NFDHqThCoJWf6wHOoQ7FLrs9ApKg8shUirWopyM7UEUraMVu2qHqu4mKW Io/y4LNiNRCKZcbPcqEZzRIKHeIAvk9fj2h2zrhzfTdCx2tSfVH2wJyBH7bnGh+Ulmd3QJ+5KkdTH 8d+5HSQOU5LcoBN5dj0JcAa4UVXtwJmYJdzA==
Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 15 May 2017 08:37:45 -0700
Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 15 May 2017 08:37:37 -0700
From: Jim Schaad 
To: 'Klaus Hartke' 
CC: 
References: <003501d2cd32$c4417a10$4cc46e30$@augustcellars.com> 
In-Reply-To: 
Date: Mon, 15 May 2017 08:26:50 -0700
Message-ID: <005e01d2cd8f$ae548dc0$0afda940$@augustcellars.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQDNpaiTKhTjOCugYu4GMFgItWlKOAHYofZfo/EOhfA=
X-Originating-IP: [24.21.96.37]
Archived-At: 
Subject: Re: [core] DTLS and Epochs
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 15:44:27 -0000

At this point I would have to ask why similar language is not in the TLS =
draft as well.

Note however that this has nothing to do with epochs and everything to =
do with additional authentication.  I think that an errata is called for =
to clarify this.

It turns out that my DTLS libraries are unable to give me the fact that =
an epoch has changed, but would know if additional authentication was =
done.  Two very different operations.

Jim


-----Original Message-----
From: Klaus Hartke [mailto:hartke@tzi.org]=20
Sent: Monday, May 15, 2017 5:02 AM
To: Jim Schaad 
Cc: core@ietf.org WG 
Subject: Re: [core] DTLS and Epochs

Hi Jim,

the requirement was added for the case that the epoch changes due to =
client or server authentication.

Example:

      1. A client connects to a server using DTLS. The server
         authenticates with a server certificate; the client
         is unauthenticated.

      2. The client sends a request that requires the client
         to be authenticated.

      3. The server requests the client to authenticate.

      4. The client authenticates with a client certificate;
         a new epoch starts.

      5. The server processes the request, assuming it comes
         from the now authenticated client. Oops!

Requiring that the request is sent in the same epoch as the response =
prevents this. It seems the language in the RFC was made too broad when =
trying to say that, though. An erratum could make it more precise.

Klaus


On 15 May 2017 at 06:21, Jim Schaad  wrote:
> I am working on getting my DTLS code to work correctly and I have come =

> across something that I do not understand.  I did not see any messages =

> in the mailing list that dealt with this so I would like to get an=20
> explanation if possible.
>
> RFC 7252 states that a response is not to be correlated with a request =

> unless the message id, the DTLS session and the DTLS epoch are the=20
> same.  I can understand the reasoning behind the id and session being=20
> the same, however I am unsure of the reason that the epoch would need=20
> to be the same as well.  I cannot see of a reason why the epoch should =

> matter.  The security session is still the same.  I could understand=20
> that there would be a reason to kill an association if additional=20
> client or server authentication information had been passed along, but =

> while that would change the epoch, an epoch can change just because=20
> enough messages have been sent over the pipe.
>
> Can somebody please explain the reasoning to me.
>
> Jim


From nobody Mon May 15 08:55:30 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9121C12E04A for ; Mon, 15 May 2017 08:55:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.209
X-Spam-Level: 
X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=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 5wR1NqP2shsx for ; Mon, 15 May 2017 08:55:27 -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 D532312E741 for ; Mon, 15 May 2017 08:45:13 -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 v4FFj0V2005549; Mon, 15 May 2017 17:45:00 +0200 (CEST)
Received: from [100.102.200.25] (ip-109-47-3-25.web.vodafone.de [109.47.3.25]) (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 3wRPzJ35XHzDGtF; Mon, 15 May 2017 17:45:00 +0200 (CEST)
Content-Type: multipart/alternative; boundary=Apple-Mail-DC018F20-5785-459C-B80D-D07A1C998CE6
Mime-Version: 1.0 (1.0)
From: Carsten Bormann 
X-Mailer: iPhone Mail (14E304)
In-Reply-To: 
Date: Mon, 15 May 2017 17:44:59 +0200
Cc: "core@ietf.org" 
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <76EA187B-4A41-4363-B49E-75064626190A@tzi.org> 
To: "Kraus Achim (INST/ECS4)" 
Archived-At: 
Subject: Re: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 15:55:29 -0000

--Apple-Mail-DC018F20-5785-459C-B80D-D07A1C998CE6
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Well, I just tried to realize what the IESG thought was right. But I can't f=
ail to notice that the existing solution didn't really address the situation=
 very well either, except where the server (or other entity supplying the li=
nk) knew exactly what the client should be doing. Section 7.8 is trying to g=
ive some guidance, but it will hardly ever be good enough to propose solutio=
ns for all possible situations.=20

Sent from mobile

> On 15. May 2017, at 16:52, Kraus Achim (INST/ECS4)  wrote:
>=20
> Hi Carsten,
>=20
>> IESG members have asked us to stop proliferating URI schemes, and as a re=
sult the draft remains with coap:// and coaps:// for all new transports.
>=20
> Assuming a system, which supports CoAP over UDP and over TCP, how should s=
uch a system select, if UDP or TCP is intended to be used for a given destin=
ation?
>=20
> Mit freundlichen Gr=C3=BC=C3=9Fen / Best regards
>=20
> Achim Kraus
>=20
> (INST/ECS4)=20
> Bosch Software Innovations GmbH | Stuttgarter Stra=C3=9Fe 130 | 71332 Waib=
lingen | GERMANY | www.bosch-si.com
>=20
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B=20=

> Gesch=C3=A4ftsf=C3=BChrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn=20
>=20
>=20
>=20
> -----Original Message-----
> From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann
> Sent: Montag, 15. Mai 2017 16:32
> To: core 
> Subject: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-=
08 after IESG input
>=20
> I have generate a first editors=E2=80=99 draft of what might become draft-=
ietf-core-coap-tcp-tls-09, addressing IESG input on the draft.
> (This draft addresses DISCUSSes, but almost no COMMENTS; see https://githu=
b.com/core-wg/coap-tcp-tls/issues for an overview what else needs to be done=
.)
>=20
> This has a bit of Brownian motion (default ports etc.), but also one impor=
tant change:
>=20
> IESG members have asked us to stop proliferating URI schemes, and as a res=
ult the draft remains with coap:// and coaps:// for all new transports.
>=20
> Please see:
>=20
> https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-coap-tcp-tls&url2=3D=
https://raw.githubusercontent.com/core-wg/coap-tcp-tls/gh-pages/iesg/draft-i=
etf-core-coap-tcp-tls.txt
>=20
> for the changes from -08, and
>=20
> https://core-wg.github.io/coap-tcp-tls/iesg/
>=20
> for a full document.
>=20
> For example,
>=20
> https://core-wg.github.io/coap-tcp-tls/iesg/#rfc.section.7.8
>=20
> is a new section, but many other sections concerned with URIs and URI sche=
mes have received changes.
>=20
> It is important if the WG can live with this change, or whether we need to=
 incur further delay pushing back on this change.
> Please let us know!
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>=20
>=20

--Apple-Mail-DC018F20-5785-459C-B80D-D07A1C998CE6
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Well, I just tried to realize what the=
 IESG thought was right. But I can't fail to notice that the existing soluti=
on didn't really address the situation very well either, except where the se=
rver (or other entity supplying the link) knew exactly what the client shoul=
d be doing. Section 7.8 is trying to give some guidance, but it will hardly e=
ver be good enough to propose solutions for all possible situations. 
Sent from mobile

On 15. May 2017, at 16:52, Kraus Achim (INST/ECS4) <Achim.Kraus@bosch-si.com> wrote:

=

Hi Carsten,

IESG members have asked us to stop pro=
liferating URI schemes, and as a result the draft remains with coap:// and c=
oaps:// for all new transports.

Assuming a system, which supports CoAP over UDP and over TCP, how should s=
uch a system select, if UDP or TCP is intended to be used for a given destin=
ation?

Mit freundlichen Gr=C3=BC=C3=9Fen / B=
est regards

 Achim Kraus

(INST/ECS4) 
Bosch Software Innovations&=
nbsp;GmbH | Stuttgarter Stra=C3=9Fe 130 | 71332 Waiblingen | GERMANY | www.bosch-si.com
<=
br>Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 1484=
11 B 
Gesch=C3=A4ftsf=C3=BChrung: Dr.-Ing. Rainer Kallenbach=
, Michael Hahn 


-----Original Message-----
From: core [mailto:core-bounces@ietf.org] On Behalf Of Ca=
rsten Bormann
Sent: Montag, 15. Mai 2017 16:32
To: core <core@ietf.org>
Subject: [core] Editors' draft of changes to draft-ietf-core-coap=
-tcp-tls-08 after IESG input

I have generat=
e a first editors=E2=80=99 draft of what might become draft-ietf-core-coap-t=
cp-tls-09, addressing IESG input on the draft.
(This draft a=
ddresses DISCUSSes, but almost no COMMENTS; see https://github.com/core-wg/coap-tcp-tls/issue=
s for an overview what else needs to be done.)
This has a bit of Brownian motion (default ports etc.), but also one=
 important change:

IESG members have asked u=
s to stop proliferating URI schemes, and as a result the draft remains with c=
oap:// and coaps:// for all new transports.

Please see:

https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-coap-tcp-tls=
&url2=3Dhttps://raw.githubusercontent.com/core-wg/coap-tcp-tls/gh-pages/=
iesg/draft-ietf-core-coap-tcp-tls.txt

f=
or the changes from -08, and

https://core-wg.github.io/coap-tc=
p-tls/iesg/

for a full document.=


For example,

https:/=
/core-wg.github.io/coap-tcp-tls/iesg/#rfc.section.7.8

is a new section, but many other sections concerned with URIs=
 and URI schemes have received changes.

It i=
s important if the WG can live with this change, or whether we need to incur=
 further delay pushing back on this change.
Please let us kn=
ow!

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

_______________________________________________core mailing list
co=
re@ietf.org
https://www.ietf.org/mailman/listinfo/core
__=
_____________________________________________
core mailing l=
ist
core@ietf.org
https://ww=
w.ietf.org/mailman/listinfo/core


=

--Apple-Mail-DC018F20-5785-459C-B80D-D07A1C998CE6--


From nobody Mon May 15 08:56:06 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3757F129AFA for ; Mon, 15 May 2017 08:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 R7KqouzAySHH for ; Mon, 15 May 2017 08:56:02 -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 E8B0112EA52 for ; Mon, 15 May 2017 08:46:06 -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 v4FFjutG006192; Mon, 15 May 2017 17:45:56 +0200 (CEST)
Received: from [100.102.200.25] (ip-109-47-3-25.web.vodafone.de [109.47.3.25]) (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 3wRQ0N4z8QzDGtG; Mon, 15 May 2017 17:45:56 +0200 (CEST)
Content-Type: multipart/alternative; boundary=Apple-Mail-3B3EC1C7-CE6A-4323-9D7D-D8E44041C7F7
Mime-Version: 1.0 (1.0)
From: Carsten Bormann 
X-Mailer: iPhone Mail (14E304)
In-Reply-To: 
Date: Mon, 15 May 2017 17:45:55 +0200
Cc: "core@ietf.org" 
Content-Transfer-Encoding: 7bit
Message-Id: <8989F449-90C7-48EA-895F-5346624A5713@tzi.org>
References: <76EA187B-4A41-4363-B49E-75064626190A@tzi.org> 
To: "Kraus Achim (INST/ECS4)" 
Archived-At: 
Subject: Re: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 15:56:04 -0000

--Apple-Mail-3B3EC1C7-CE6A-4323-9D7D-D8E44041C7F7
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

And the flip answer is "happy bearing balls" (we don't have eyeballs in thin=
gs)...

Sent from mobile

> On 15. May 2017, at 16:52, Kraus Achim (INST/ECS4)  wrote:
>=20
> Hi Carsten,
>=20
>> IESG members have asked us to stop proliferating URI schemes, and as a re=
sult the draft remains with coap:// and coaps:// for all new transports.
>=20
> Assuming a system, which supports CoAP over UDP and over TCP, how should s=
uch a system select, if UDP or TCP is intended to be used for a given destin=
ation?
>=20
> Mit freundlichen Gr=C3=BC=C3=9Fen / Best regards
>=20
> Achim Kraus
>=20
> (INST/ECS4)=20
> Bosch Software Innovations GmbH | Stuttgarter Stra=C3=9Fe 130 | 71332 Waib=
lingen | GERMANY | www.bosch-si.com
>=20
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B=20=

> Gesch=C3=A4ftsf=C3=BChrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn=20
>=20
>=20
>=20
> -----Original Message-----
> From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann
> Sent: Montag, 15. Mai 2017 16:32
> To: core 
> Subject: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-=
08 after IESG input
>=20
> I have generate a first editors=E2=80=99 draft of what might become draft-=
ietf-core-coap-tcp-tls-09, addressing IESG input on the draft.
> (This draft addresses DISCUSSes, but almost no COMMENTS; see https://githu=
b.com/core-wg/coap-tcp-tls/issues for an overview what else needs to be done=
.)
>=20
> This has a bit of Brownian motion (default ports etc.), but also one impor=
tant change:
>=20
> IESG members have asked us to stop proliferating URI schemes, and as a res=
ult the draft remains with coap:// and coaps:// for all new transports.
>=20
> Please see:
>=20
> https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-coap-tcp-tls&url2=3D=
https://raw.githubusercontent.com/core-wg/coap-tcp-tls/gh-pages/iesg/draft-i=
etf-core-coap-tcp-tls.txt
>=20
> for the changes from -08, and
>=20
> https://core-wg.github.io/coap-tcp-tls/iesg/
>=20
> for a full document.
>=20
> For example,
>=20
> https://core-wg.github.io/coap-tcp-tls/iesg/#rfc.section.7.8
>=20
> is a new section, but many other sections concerned with URIs and URI sche=
mes have received changes.
>=20
> It is important if the WG can live with this change, or whether we need to=
 incur further delay pushing back on this change.
> Please let us know!
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>=20
>=20

--Apple-Mail-3B3EC1C7-CE6A-4323-9D7D-D8E44041C7F7
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


And the flip answer is "happy bearing b=
alls" (we don't have eyeballs in things)...

Sent from mobile

On 15. May 2017, at 16:52=
, Kraus Achim (INST/ECS4) <Ac=
him.Kraus@bosch-si.com> wrote:

Hi Carsten,

IESG members have asked us to stop proliferating URI schemes, and as a=
 result the draft remains with coap:// and coaps:// for all new transports.<=
/span>

Assuming a system, which suppo=
rts CoAP over UDP and over TCP, how should such a system select, if UDP or T=
CP is intended to be used for a given destination?
Mit freundlichen Gr=C3=BC=C3=9Fen / Best regards

 Achim Kraus

(INST/ECS4) 
Bosch Software Innovations GmbH | Stuttgarter Stra=C3=
=9Fe 130 | 71332 Waiblingen | GERMANY | =
www.bosch-si.com

Sitz: Berlin, Register=
gericht: Amtsgericht Charlottenburg; HRB 148411 B 
Gesch=C3=A4=
ftsf=C3=BChrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn 
<=
/span>


-----Original Message-----=

From: core [mailto=
:core-bounces@ietf.org] On Behalf Of Carsten Bormann
Sen=
t: Montag, 15. Mai 2017 16:32
To: core <core@ietf.org>
Subject: [core] Editor=
s' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input

I have generate a first editors=E2=80=99 draft o=
f what might become draft-ietf-core-coap-tcp-tls-09, addressing IESG input o=
n the draft.
(This draft addresses DISCUSSes, but almost no C=
OMMENTS; see http=
s://github.com/core-wg/coap-tcp-tls/issues for an overview what else nee=
ds to be done.)

This has a bit of Brownian m=
otion (default ports etc.), but also one important change:
<=
/span>
IESG members have asked us to stop proliferating URI schemes=
, and as a result the draft remains with coap:// and coaps:// for all new tr=
ansports.

Please see:

https://tools.ietf.org/r=
fcdiff?url1=3Ddraft-ietf-core-coap-tcp-tls&url2=3Dhttps://raw.githubuser=
content.com/core-wg/coap-tcp-tls/gh-pages/iesg/draft-ietf-core-coap-tcp-tls.=
txt

for the changes from -08, and

https://core-wg.github.io/coap-tcp-tls/iesg/

for a full document.

For exa=
mple,

https://core-wg.github.io/coap-tcp-tls/i=
esg/#rfc.section.7.8

is a new section, b=
ut many other sections concerned with URIs and URI schemes have received cha=
nges.

It is important if the WG can live wi=
th this change, or whether we need to incur further delay pushing back on th=
is change.
Please let us know!

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

______________=
_________________________________
core mailing listcore@ietf.org
<=
a href=3D"https://www.ietf.org/mailman/listinfo/core">https://www.ietf.org/m=
ailman/listinfo/core
___________________________________=
____________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core<=
/a>


=

--Apple-Mail-3B3EC1C7-CE6A-4323-9D7D-D8E44041C7F7--


From nobody Tue May 16 04:57:23 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BB0129BBD for ; Tue, 16 May 2017 04:57:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 xu5R14ucSyTI for ; Tue, 16 May 2017 04:57:20 -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 2CD3B129461 for ; Tue, 16 May 2017 04:53:33 -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 v4GBrUoT007409 for ; Tue, 16 May 2017 13:53:30 +0200 (CEST)
Received: from client-0191.vpn.uni-bremen.de (client-0191.vpn.uni-bremen.de [134.102.107.191]) (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 3wRwnj66R3zDHBG; Tue, 16 May 2017 13:53:29 +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: Tue, 16 May 2017 13:53:26 +0200
Cc: "core@ietf.org" 
X-Mao-Original-Outgoing-Id: 516628406.031567-0acda348dbeef15673bb49d28fc58415
Content-Transfer-Encoding: quoted-printable
Message-Id: <228B9781-A545-4312-854E-625539545E1A@tzi.org>
References: <76EA187B-4A41-4363-B49E-75064626190A@tzi.org>  
To: Klaus Hartke 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 11:57:22 -0000

> On May 15, 2017, at 17:15, Klaus Hartke  wrote:
>=20
> Kraus Achim (INST/ECS4) wrote:
>> Assuming a system, which supports CoAP over UDP and over TCP, how =
should such a system select, if UDP or TCP is intended to be used for a =
given destination?
>=20
> This one is even more fun:
>=20
>    coap://2259499800/path/to/resource
>=20
> Is this CoAP over UDP or TCP to a server with IP address 134.173.59.24

Answer: No.  RFC 3986 says:

   IPv4address   =3D dec-octet "." dec-octet "." dec-octet "." dec-octet

   dec-octet     =3D DIGIT                 ; 0-9
                 / %x31-39 DIGIT         ; 10-99
                 / "1" 2DIGIT            ; 100-199
                 / "2" %x30-34 DIGIT     ; 200-249
                 / "25" %x30-35          ; 250-255


> (there are URI parsers that accept "dotless" IPv4 addresses)

That may have been an amusing quirk for a while, but is not supported by =
the URI standard. =20
I hope people don=E2=80=99t start doing in the CoAP space what has been =
deprecated in the HTTP space for a long time...

> or CoAP over SMS to a server with phone number +225-949-9800?

I don=E2=80=99t think we will be able to address CoAP over SMS with the =
same Authority (RFC 3986) construct that we use for CoAP over IP-based =
transports.  The latter all are based on IP addresses and port numbers =
(even if the port numbers may be for different transport protocols).  =
But the CoAP over SMS document is not before the IESG at this point in =
time.  By the way, we are still looking for reviews for the latter =
(https://tools.ietf.org/html/draft-becker-core-coap-sms-gprs-06) so we =
can adopt it as a WG document.

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


From nobody Tue May 16 07:02:46 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D28129C55 for ; Tue, 16 May 2017 07:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level: 
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, 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 lybbKOkjXTeB for ; Tue, 16 May 2017 07:02:43 -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 10F2C12EBB7 for ; Tue, 16 May 2017 06:58:12 -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 v4GDw9A2018562 for ; Tue, 16 May 2017 15:58:09 +0200 (CEST)
Received: from client-0191.vpn.uni-bremen.de (client-0191.vpn.uni-bremen.de [134.102.107.191]) (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 3wRzYY4YlVzDHFN; Tue, 16 May 2017 15:58:09 +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: <76EA187B-4A41-4363-B49E-75064626190A@tzi.org>
Date: Tue, 16 May 2017 15:58:08 +0200
X-Mao-Original-Outgoing-Id: 516635888.814189-0f3b2462f84fb5129e4e40bce2537821
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <76EA187B-4A41-4363-B49E-75064626190A@tzi.org>
To: core 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [core] Editors' draft of changes to draft-ietf-core-coap-tcp-tls-08 after IESG input
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 14:02:45 -0000

I just pushed a couple more commits, this time addressing some input =
from the IESG that the ADs downgraded from DISCUSS to COMMENT.

In particular the text I generated on cipher suites needs attention from =
implementers and TLS experts.
(The gist is that CoAP over WebSockets should use what is available in =
browsers and secure [JavaScript code may not have a lot of influence on =
the cipher suites anyway], while CoAP over TLS should use what is =
available in constrained devices, i.e. the cipher suites recommended in =
RFC 7925 =E2=80=94 even though any back-end usage of CoAP over TLS may =
want to use RFC 7525 cipher suites instead.)

Please use the links below, which now include the changes for these last =
two commits.

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


> On May 15, 2017, at 16:32, Carsten Bormann  wrote:
>=20
> I have generate a first editors=E2=80=99 draft of what might become =
draft-ietf-core-coap-tcp-tls-09, addressing IESG input on the draft.
> (This draft addresses DISCUSSes, but almost no COMMENTS; see =
https://github.com/core-wg/coap-tcp-tls/issues for an overview what else =
needs to be done.)
>=20
> This has a bit of Brownian motion (default ports etc.), but also one =
important change:
>=20
> IESG members have asked us to stop proliferating URI schemes, and as a =
result the draft remains with coap:// and coaps:// for all new =
transports.
>=20
> Please see:
>=20
> =
https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-coap-tcp-tls&url2=3D=
https://raw.githubusercontent.com/core-wg/coap-tcp-tls/gh-pages/iesg/draft=
-ietf-core-coap-tcp-tls.txt
>=20
> for the changes from -08, and
>=20
> https://core-wg.github.io/coap-tcp-tls/iesg/
>=20
> for a full document.
>=20
> For example,
>=20
> https://core-wg.github.io/coap-tcp-tls/iesg/#rfc.section.7.8
>=20
> is a new section, but many other sections concerned with URIs and URI =
schemes have received changes.
>=20
> It is important if the WG can live with this change, or whether we =
need to incur further delay pushing back on this change.
> Please let us know!
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20
>=20
>=20


From nobody Tue May 16 22:11:15 2017
Return-Path: 
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5602912EAF6; Tue, 16 May 2017 22:11:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: core@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149499787331.6639.13723189481173509706@ietfa.amsl.com>
Date: Tue, 16 May 2017 22:11:13 -0700
Archived-At: 
Subject: [core] I-D Action: draft-ietf-core-coap-tcp-tls-09.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 May 2017 05:11:13 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Constrained RESTful Environments of the IETF.

        Title           : CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
        Authors         : Carsten Bormann
                          Simon Lemay
                          Hannes Tschofenig
                          Klaus Hartke
                          Bilhanan Silverajan
                          Brian Raymor
	Filename        : draft-ietf-core-coap-tcp-tls-09.txt
	Pages           : 47
	Date            : 2017-05-16

Abstract:
   The Constrained Application Protocol (CoAP), although inspired by
   HTTP, was designed to use UDP instead of TCP.  The message layer of
   the CoAP over UDP protocol includes support for reliable delivery,
   simple congestion control, and flow control.

   Some environments benefit from the availability of CoAP carried over
   reliable transports such as TCP or TLS.  This document outlines the
   changes required to use CoAP over TCP, TLS, and WebSockets
   transports.  It also formally updates RFC 7252 fixing an erratum in
   the URI syntax, RFC 7641 for use with the new transports, and RFC
   7959 to enable the use of larger messages over a reliable transport.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-09
https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-tcp-tls-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu May 18 09:07:47 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF8E129434; Thu, 18 May 2017 09:07:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.004
X-Spam-Level: *
X-Spam-Status: No, score=1.004 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOCALPART_IN_SUBJECT=1.107, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 jQ3woZ182WnG; Thu, 18 May 2017 09:07:41 -0700 (PDT)
Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87BA5129B43; Thu, 18 May 2017 09:02:29 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1495123338; h=from:subject:to:date:message-id; bh=/tdKbrVWKSSl1b0+cSHQ+ULUQ/70SCla8HUvALkfKJ0=; b=Bu+Li9qipWLxYoUDKE/c/3AMZg9F2/ho8lbDDvhTO3DVdZXlH/4q8zGfECosr1A2LKR6C6ouADn CWI22BgYrFZUoPQLbuGObrD8kxd6kp+r55Yce0VZpL/IVfIFTlYtCF0FeJeg3NEJvOxJcKHdXRr31 MP6hb18jE03w0HDLD4fxCEd2A+4AUxQBJqk9qtpA+r0MHlkUR5+zbvsR4sWzc4g9ln7nd44ZfF3Cd ixC7Lfju4oDYXp5Ot57DcW+ByCRxeQF8eXoeSQL7X0wEurYoEKGUhyqnzyG6e8hgcUyu3uhkghWWc fycM1yZguTsIag1tMYZgH6XWQtmF9Nhm3YzA==
Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 18 May 2017 09:02:18 -0700
Received: from Hebrews (192.168.1.157) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 18 May 2017 09:02:17 -0700
From: Jim Schaad 
To: 
CC: 
Date: Thu, 18 May 2017 08:51:28 -0700
Message-ID: <018101d2cfee$9e07e7d0$da17b770$@augustcellars.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdLPiXFIiaP3rkeTR+qUlbYYqTbZGg==
X-Originating-IP: [192.168.1.157]
Archived-At: 
Subject: [core] draft-ietf-core-coap-tcp-tls
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 May 2017 16:07:46 -0000

This document is missing any statements about making sure that the same
session (TLS, TCP, WebSockets,...) is used when matching requests and
replys.  While this may seem to be obvious, the statement does exist for
DTLS and thus should be echoed here.

Jim



From nobody Thu May 18 09:43:06 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC88129B01; Thu, 18 May 2017 09:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 kxIbIhaE6ogk; Thu, 18 May 2017 09:43:03 -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 4B71F129AEB; Thu, 18 May 2017 09:35:12 -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 v4IGYeM7016170; Thu, 18 May 2017 18:34:40 +0200 (CEST)
Received: from [192.168.217.113] (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 3wTGxD2XRzzDGms; Thu, 18 May 2017 18:34:40 +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: <018101d2cfee$9e07e7d0$da17b770$@augustcellars.com>
Date: Thu, 18 May 2017 18:34:39 +0200
Cc: draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org
X-Mao-Original-Outgoing-Id: 516818079.737833-e11e97842ccd458422ab2bff8e0ee11e
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <018101d2cfee$9e07e7d0$da17b770$@augustcellars.com>
To: Jim Schaad 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [core] draft-ietf-core-coap-tcp-tls
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 May 2017 16:43:04 -0000

On May 18, 2017, at 17:51, Jim Schaad  wrote:
>=20
> This document is missing any statements about making sure that the =
same
> session (TLS, TCP, WebSockets,...) is used when matching requests and
> replys.  While this may seem to be obvious, the statement does exist =
for
> DTLS and thus should be echoed here.

Hi Jim,

3.3 (for the TCP and TLS/TCP cases) says:

   Responses MUST be returned over the same connection as
   the originating request. =20

and goes on:

   Concurrent requests are differentiated by
   their Token, which is scoped locally to the connection.


4.3 (for the WebSockets cases) redundantly(*) says:

   Responses MUST be returned over the same
   connection as the originating request.

and also goes on:

   Concurrent requests are
   differentiated by their Token, which is scoped locally to the
   connection.

Is there more we need to say?

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


(*) Para 1 of Section 4 says "this section only specifies the =
differences between the
   transports.=E2=80=9D.  But I think it does not hurt to state this =
important point again.


From nobody Fri May 19 10:22:43 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930D712957B; Fri, 19 May 2017 10:22:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.698
X-Spam-Level: 
X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 7OeYQRpCdSUD; Fri, 19 May 2017 10:22:40 -0700 (PDT)
Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02BD912957A; Fri, 19 May 2017 10:22:40 -0700 (PDT)
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1495214551; h=from:subject:to:date:message-id; bh=s2cD+PVEraD+ogZFososdr8Q7FAuBIsTTklaUhBy9F4=; b=YXThb9oWBn7xt6mUHq4IFbTzxi7zauAbjvwDWhv7cWblUX+ds3BFfIDBZbEoz06CM70S6VipVjI VVjulVtZUeNzM8iMHvEFHaIdmZXrz9FVf5OU986/I2nXmvPmK+RNJYKfAesQmc1rGyK+xGYPO+NPp cXobkrld3+0ueDWd/pzBAclgIYLkOAfEu78Gs3u5pDvl4TWwkIIglgokmPNemo0vex1JgBRkvicnc jod6YpbjViPOz3tbrXBOHhuFDs5E10z90WNrnd84D0CwrFmsVqbG+deaHjsQwM7ifmEssQI9nrayy DaFJmLz/c5tC7GWkz0jWqBZPV4acdCr8paWw==
Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 19 May 2017 10:22:31 -0700
Received: from Hebrews (192.168.1.157) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 19 May 2017 10:22:28 -0700
From: Jim Schaad 
To: 'Carsten Bormann' 
CC: , 
References: <018101d2cfee$9e07e7d0$da17b770$@augustcellars.com> 
In-Reply-To: 
Date: Fri, 19 May 2017 10:11:33 -0700
Message-ID: <022001d2d0c2$fac87640$f05962c0$@augustcellars.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKoOlOZ8gelY6FJ07PskkuhAXozQQGok5KyoEJ9s+A=
X-Originating-IP: [192.168.1.157]
Archived-At: 
Subject: Re: [core] draft-ietf-core-coap-tcp-tls
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 17:22:42 -0000

I was looking for something stronger - such as the language from the =
CoAP draft

The following rules are added for matching a response to a request:
   The DTLS session MUST be the same, and the epoch MUST be the same.

I could not find the language as I was searching for similar language =
dealing with matching.   The language is adequate, but something that =
matches the other draft would still have been my preference.  =20

Jim


-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org]=20
Sent: Thursday, May 18, 2017 9:35 AM
To: Jim Schaad 
Cc: draft-ietf-core-coap-tcp-tls@ietf.org; core@ietf.org
Subject: Re: [core] draft-ietf-core-coap-tcp-tls

On May 18, 2017, at 17:51, Jim Schaad  wrote:
>=20
> This document is missing any statements about making sure that the=20
> same session (TLS, TCP, WebSockets,...) is used when matching requests =

> and replys.  While this may seem to be obvious, the statement does=20
> exist for DTLS and thus should be echoed here.

Hi Jim,

3.3 (for the TCP and TLS/TCP cases) says:

   Responses MUST be returned over the same connection as
   the originating request. =20

and goes on:

   Concurrent requests are differentiated by
   their Token, which is scoped locally to the connection.


4.3 (for the WebSockets cases) redundantly(*) says:

   Responses MUST be returned over the same
   connection as the originating request.

and also goes on:

   Concurrent requests are
   differentiated by their Token, which is scoped locally to the
   connection.

Is there more we need to say?

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


(*) Para 1 of Section 4 says "this section only specifies the =
differences between the
   transports.=E2=80=9D.  But I think it does not hurt to state this =
important point again.



From nobody Mon May 22 13:09:28 2017
Return-Path: 
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 396F2120454; Mon, 22 May 2017 13:09:26 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ben Campbell 
To: "The IESG" 
Cc: draft-ietf-core-coap-tcp-tls@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149548376623.16443.17405907888159334729.idtracker@ietfa.amsl.com>
Date: Mon, 22 May 2017 13:09:26 -0700
Archived-At: 
Subject: [core] Ben Campbell's No Objection on draft-ietf-core-coap-tcp-tls-09: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 20:09:26 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-core-coap-tcp-tls-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Update2: I've cleared my DISCUSS position, since version 09 removed the
use of the scheme to select the transport. I would have liked to see a
bit more precision from Adam's suggested design in the section on
transport selection, but I don't consider that discuss-worthy.

Update: I removed point 1 from my discuss. But I do still think it would
be useful to add a paragraph about how COAP reliability features are only
hop-by-hop.

Subtantive:

3.2: I agree with Adam that this length scheme seems very complex for
the
return

3.3: Since the initiator can start sending messages before receiving a
CSM
from the responder, how long should the initiator wait for a CSM before
bailing?

3.4: Can you offer any guidance about how often to send keep-alives? I
note
that these keepalives are not necessarily bi-directional. Aren't there
some
NAT/FW cases where bi-directional traffic is needed to keep bindings
from
timing out?

This and other places explicitly mention that in-flight messages may be
lost
when the transport is closed or reset. This creates uncertainty about
whether
such messages have been processed or not. Is that really okay?

4: After the discussion resulting from Mark's Art-Art review, I expected
to
see more emphasis about WebSocket being intended for browser-based
clients.
There's a couple of in-passing mentions of browser-clients buried in
the
text; I would have expected something more up front.

4.2: Is it really worth making the framing code behave differently for
WebSocket than for TCP?

5.3: Do I understand correctly that once an option is established, it
cannot
be removed unless replaced? (Short of tearing down the connection and
starting over, anyway.)

7.2: The text mentions 443 as a default port, but really seems to make
5684
the default. If 443 is really a default, then this needs  discussion
about
why and why it's okay to squat on HTTPS.

The text about whether ALPN is required is confusing. Why not just
require
ALPN and move one, rather than special casing it by port choice? (There
seems
to be some circular logic about requiring 5685 to support clients that
don't
do ALPN, then saying clients MUST do ALPN unless they are using port
5685.)

7.3: I agree with Adam's DISCUSS comment. And even if people decide that
the
well-known bit can be specified in CORE, I think it does future users of
a
well-known URIs for ws a disservice to make them dig through this spec
to
find the update to 6455.  It would be better to pull that into a
separate
draft. That's also a material addition post IETF last call, so we should
consider
repeating the LC.

10.2: Is the registration policy "analogous to" that of [RFC7252] S12.2,
or
"identical to" it. If the answer is not "identical", then the policy
should be detailed here.

Editorial:

Figures 7 and 8: "Payload (if any)" - Can we assume that if one uses
either
extended length format, one has a payload?

3.3: Is the guidance about what errors to return if you don't implement
a
server any different here than for UDP?

4.3 and 4.4 seem to primarily repeat details that are the same for WS as
for
TCP, even though the introduction to the WS part says that it won't do
that
:-)

5.3: "One CSM MUST be sent by both endpoints...": s/both/each

7.6: The "updates" in this section are confusing. I understand this to
mean
that the procedures for TCP and WS are identical to those for UDP except
for
the mentioned steps. But the language of the form of "This step from
[RFC7252] is updated to:" makes it sound like this intends to actually
change
the language in 7252 to this new language. If the latter, then that
effectively removes UDP support from 7252 as updated.

This could easily be fixed by changing that to something to the effect
of
"When using TCP, this step changes to ..."

Appendix A: Why is this an appendix? Updates to a standards track RFC
seem to
warrant a more prominent position in the draft.



From nobody Mon May 22 13:48:23 2017
Return-Path: 
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E3F12702E; Mon, 22 May 2017 13:48:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach 
To: "The IESG" 
Cc: draft-ietf-core-coap-tcp-tls@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149548610222.24921.6807834750685175839.idtracker@ietfa.amsl.com>
Date: Mon, 22 May 2017 13:48:22 -0700
Archived-At: 
Subject: [core] Adam Roach's No Objection on draft-ietf-core-coap-tcp-tls-09: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 20:48:22 -0000

Adam Roach has entered the following ballot position for
draft-ietf-core-coap-tcp-tls-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have removed my DISCUSS, but want to be clear that I remain quite
distressed about the design aspects of this document. I have adjusted my
comments below to trim them down to only those issues that remain in -09.
Beyond the comments left over from -08, I am perplexed that no concrete
mechanism for UDP/TCP failover is provided, nor is any discussion of the
management aspects of configuring between them, nor is any discussion of
which transport protocol(s) may be considered MTI.

I also wish to highlight the somewhat buried request from my original
comments that I believe this document would be vastly improved by
splitting it into one document that deals with TCP, and another that
deals with WebSockets. They are intended for radically different
environments, and a large majority of implementors will care about one
but not the other. Combining into a single document just creates more
work for them.

General 鈥 this is a very bespoke approach to what could have been mostly
solved with a single four-byte 鈥渓ength鈥 header; it is complicated on the
wire, and in implementation; and the format variations among CoAP over
UDP, TLS, and WebSockets are going to make gateways much harder to
implement and less efficient (as they will necessarily have to
disassemble messages and rebuild them to change between formats). The
protocol itself mentions gateways in several places, but does not discuss
how they are expected to map among the various flavors of CoAP defined in
this document. Some of the changes seem unnecessary, but it could be that
I鈥檓 missing the motivation for them. Ideally, the introduction would work
harder at explaining why CoAP over these transports is as different from
CoAP over UDP as it is, focusing in particular on why the complexity of
having three syntactically incompatible headers is justified by the
benefits provided by such variations.

Additionally, it鈥檚 not clear from the introduction what the motivation
for using the mechanisms in this document is as compared to the
techniques described in section 10 (and its subsections) of RFC 7252.
With the exception of subscribing to resource state (which could be
added), it seems that such an approach is significantly easier to
implement and more clearly defined than what is in this document; and it
appears to provide the combined benefits of all four transports discussed
in this document. My concern here is that an explosion of transport
options makes it less likely that a client and server can find two in
common: the limit of the probability of two implementations having a
transport in common as the number of transports approaches infinity is
zero. Due to this likely decrease in interoperability, I鈥檇 expect to see
some pretty powerful motivation in here for defining a third, fourth,
fifth, and sixth way to carry CoAP when only TCP is available (I count
RFC 7252 http and https as the first and second ways in this
accounting).

Specific comments follow.

Section 3.3, paragraph 3 says that an initiator may send messages prior
to receiving the remote side鈥檚 CSM, even though the message may be larger
than would be allowed by that CSM.  What should the recipient of an
oversized message do in this case? In fact, I don鈥檛 see in here what a
recipient of a message larger than it allowed for in its CSM is supposed
to do in response at *any* stage of the connection. Is it an error? If
so, how do you indicate it? Or is the Max-Message-Size option just a
suggestion for the other side? This definitely needs clarification.
(Aside 鈥 it seems odd and somewhat backwards that TCP connections are
provided an affordance for fine-grained control over message sizes, while
UDP communications are not.)

Section 5 and its subsections define a new set of message types,
presumably for use only on connection-oriented protocols, although this
is only implied, and never stated. For example, some implementors may see
CSM, Ping, and Pong as potentially useful in UDP; and, finding no
prohibition in this document against using them, decide to give it a go.
Is that intended? If not, I strongly suggest an explicit prohibition
against using these in UDP contexts.

Section 5.3.2 says that implementations supporting block-wise transfers
SHOULD indicate the Block-wise Transfer Option. I can't figure out why
this is anything other than a "MUST". It seems odd that this document
would define a way to communicate this, and then choose to leave the
communicated options as 鈥淵ES鈥 and 鈥淵OUR GUESS IS AS GOOD AS MINE鈥 rather
than the simpler and more useful 鈥淵ES鈥 and 鈥淣O鈥.

I find the described operation of the Custody Option in the operation of
Ping and Pong to be somewhat problematic: it allows the Pong sender to
unilaterally decide to set the Custody Option, and consequently
quarantine the Pong for an arbitrary amount of time while it processes
other operations. This seems impossible to distinguish from a
failure-due-to-timeout from the perspective of the Ping sender. Why not
limit this behavior only to Ping messages that include the Custody
Option?

I am similarly perplexed by the hard-coded 鈥渕ust do ALPN *unless* the
designated port takes the magical value 5684鈥 behavior. I don鈥檛 think
I鈥檝e ever seen a protocol that has such variation based on a hard-coded
port number, and it seems unlikely to be deployed correctly (I鈥檓 imaging
the frustration of: 鈥淚 changed both the server and the client
configuration from the default port of 5684 to 49152, and it just stopped
working. Like, literally the *only* way it works is on port 5684. I've
checked firewall settings everywhere and don't see any special handling
for that port -- I just can't figure this out, and it's driving me
crazy.鈥). Given the nearly universal availability of ALPN in pretty much
all modern TLS libraries, it seems much cleaner to just require ALPN
support and call it done. Or *don鈥檛* require ALPN at all and call it
done. But *changing* protocol behavior based on magic port numbers seems
like it鈥檚 going to cause a lot of operational heartburn.

[I have removed my comments about section 8.1, as I believe EKR is
managing the TLS-related issues for this document]

Although the document clearly expects the use of gateways and proxies
between these connection-oriented usages of CoAP and UDP-based CoAP,
Appendix A seems to omit discussion or consideration of how this
gatewaying can be performed. The following list of problems is
illustrative of this larger issue, but likely not exhaustive. (I'll note
that all of these issues evaporate if you move to a simpler scheme that
merely frames otherwise unmodified UDP CoAP messages)

Section A.1 does not indicate what gateways are supposed to do with
out-of-order notifications. The TCP side requires these to be delivered
in-order; so, do this mean that gateways observing a gap in sequence
numbers need to quarantine the newly received message so that it can
deliver the missing one first? Or does it deliver the newly-received
message and then discard the 鈥渟tale鈥 one when it arrives? I don鈥檛 think
that leaving this up to implementations is particularly advisable.

Section A.3 is a bit more worrisome. I understand the desired
optimization here, but where you reduce traffic in one direction, you run
the risk of exploding it in the other. For example, consider a coap+tcp
client connecting to a gateway that communicates with a CoAP-over-UDP
server. When that client wants to check the health of its observations,
it can send a Ping and receive a Pong that confirms that they are all
alive and well. In order to be able to send a Pong that *means* 鈥渁ll your
observations are alive and well,鈥 the gateway has to verify that all the
observations are alive and well. A simple implementation of a gateway
will likely check on each observed resource individually when it gets a
Ping, and then send a Pong after it hears back about all of them. So, as
a client, I can set up, let鈥檚 say, two dozen observations through this
gateway. Then, with each Ping I send, the gateway sends two dozen checks
towards the server. This kind of message amplification attack is an
awesome way to DoS both the gateway and the server. I believe the
document needs a treatment of how UDP/TCP gateways handle notification
health checks, along with techniques for mitigating this specific
attack.

Section A.4 talks about the rather different ways of dealing with
unsubscribing from a resource. Presumably, gateways that get a reset to a
notification are expected to synthesize a new GET to deregister on behalf
of the client? Or is it okay if they just pass along the reset, and
expect the server to know that it means the same thing as a
deregistration? Without explicit guidance here, I expect server and
gateway implementors to make different choices and end up with a lack of
interop.

>From i-d nits (this appears to be in reference to Figure 1):
** There is 1 instance of too long lines in the document, the longest one
being 3 characters in excess of 72.



From nobody Tue May 23 10:26:28 2017
Return-Path: 
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A78A129C32; Tue, 23 May 2017 10:26:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: core@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149556038141.11645.16250582178931925171@ietfa.amsl.com>
Date: Tue, 23 May 2017 10:26:21 -0700
Archived-At: 
Subject: [core] I-D Action: draft-ietf-core-senml-08.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 17:26:21 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Constrained RESTful Environments of the IETF.

        Title           : Media Types for Sensor Measurement Lists (SenML)
        Authors         : Cullen Jennings
                          Zach Shelby
                          Jari Arkko
                          Ari Keranen
                          Carsten Bormann
	Filename        : draft-ietf-core-senml-08.txt
	Pages           : 46
	Date            : 2017-05-23

Abstract:
   This specification defines media types for representing simple sensor
   measurements and device parameters in the Sensor Measurement Lists
   (SenML).  Representations are defined in JavaScript Object Notation
   (JSON), Concise Binary Object Representation (CBOR), eXtensible
   Markup Language (XML), and Efficient XML Interchange (EXI), which
   share the common SenML data model.  A simple sensor, such as a
   temperature sensor, could use this media type in protocols such as
   HTTP or CoAP to transport the measurements of the sensor or to be
   configured.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-senml/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-core-senml-08
https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue May 23 10:27:05 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038B0129C37 for ; Tue, 23 May 2017 10:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.779
X-Spam-Level: 
X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 YCDSiGZqpNaf for ; Tue, 23 May 2017 10:27:03 -0700 (PDT)
Received: from smtp101.ord1c.emailsrvr.com (smtp101.ord1c.emailsrvr.com [108.166.43.101]) (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 693A4129C32 for ; Tue, 23 May 2017 10:27:03 -0700 (PDT)
Received: from smtp13.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp13.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 36DF7A01A5; Tue, 23 May 2017 13:26:59 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp13.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id BE650A0144;  Tue, 23 May 2017 13:26:58 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.1.3.67] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Tue, 23 May 2017 13:26:59 -0400
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Cullen Jennings 
In-Reply-To: <06D60C67-7B3F-4A7B-A683-763B28F8620B@iii.ca>
Date: Tue, 23 May 2017 11:26:57 -0600
Cc: =?utf-8?Q?Christian_Ams=C3=BCss?= 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <06D60C67-7B3F-4A7B-A683-763B28F8620B@iii.ca>
To: core 
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Subject: Re: [core] SENML proposal: Allow base attributes in any Record
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 17:27:05 -0000

> On May 13, 2017, at 10:15 AM, Cullen Jennings  wrote:
>=20
>=20
> We had a good call about URI , URL, and how this all links together =
but one of the discussion made us realize that for aggregated =
collections, the current spec is less than ideal and that problem =
reflected up in multiple ways. So here is the proposal ...=20
>=20
> We got back to allowing base attributes to occur in any record and be =
the base value any record after that up to the point where the base =
attribute gets set to something else. Take the example of a sensor with =
IP 2001:db8::2 that is an indoor temperature and humidity sensor that =
also aggregates in the reading from a similar outdoor device at IP =
2001:db8::1. You could represent this wth=20
>=20
>   [
>     {"bt":1.320078429e+09,
>      "n":"2001:db8::2-temperature","u":"Cel","v":25.2},
>     {"n":"2001:db8::2-humidity","u":"%RH","v":30},
>     {"n":"2001:db8::1-temperature","u":"Cel","v":12.3},
>     {"n":"2001:db8::1-humidity","u":"%RH","v":67}
> ]
>=20
> Note the IP part of the name is different in the last two records =
because that is the unique sensor they came from.
>=20
> But it would be nicer to be able to say=20
>=20
>=20
> [
>     {"bn":"2001:db8::2","bt":1.320078429e+09,
>      "n":"temperature","u":"Cel","v":25.2},
>     {"n":"humidity","u":"%RH","v":30},
>     {"bn":"2001:db8::1",
>      "n":"temperature","u":"Cel","v":12.3},
>     {"n":"humidity","u":"%RH","v":67}
> ]
>=20
> This gives us better compression because we can use a base name for =
the common IP part of the sensor name.=20
>=20
> A very common use case for core is aggregating measurements into one =
pack so I think this is an important use case. It also resolves the =
issue we were having with lining up with names and URL which is how we =
realized we had this issue.=20
>=20
> So my proposal is go back to how we used to have it and allow base =
attributes in Records other than than the first Record. I realize this =
is flip flopping on a previous decision but I think we forgot about this =
use case when we went to base values only in the first Record.=20
>=20
> Let me know if you see any problems with this.=20
>=20
> Thanks,=20
> Cullen
>=20
>=20
>=20

I got a few looks good from folks so I have updated this into the latest =
draft at https://www.ietf.org/id/draft-ietf-core-senml-08.txt=20







From nobody Tue May 23 18:11:58 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6CF12E872; Tue, 23 May 2017 18:11:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 WAFjU8I1WofM; Tue, 23 May 2017 18:11:47 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0090.outbound.protection.outlook.com [104.47.40.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84B5129473; Tue, 23 May 2017 18:11:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Y3PqGLJtcasfIXQmfuJTStKcGwEUhKjZqRT7YMUER70=; b=YNLz3E2kI3/XxVAxvgcOwnj4d1IExJ+X/GeCh+OPVl4AKtln7aZ66kBZRSlVamFEvGcKbtzKBNXYLHZOFC1A8bfTAnGXWlguwqwd1n5Odo1u5LPyjnNmpjNWvC3LUkrX4UHphcAQgUWaNEK0DaPZZzb47Lvv5GEc25p+29xCsGk=
Received: from BY2PR21MB0084.namprd21.prod.outlook.com (10.162.78.141) by BY2PR21MB0020.namprd21.prod.outlook.com (10.162.77.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.0; Wed, 24 May 2017 01:11:44 +0000
Received: from BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) by BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) with mapi id 15.01.1143.000; Wed, 24 May 2017 01:11:43 +0000
From: Brian Raymor 
To: Hannes Tschofenig , Carsten Bormann , Eric Rescorla 
CC: "core-chairs@ietf.org" , The IESG , "core@ietf.org" , "draft-ietf-core-coap-tcp-tls@ietf.org" 
Thread-Topic: [core] Eric Rescorla's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
Thread-Index: AQHSyVSAMpIwzIhBiUGz2Gs5B08R+qHtXEWAgBVTRFA=
Date: Wed, 24 May 2017 01:11:43 +0000
Message-ID: 
References: <149411155754.23175.15150224037348429928.idtracker@ietfa.amsl.com>  <28837957-421a-eeff-8304-cfafb80ca234@gmx.net>
In-Reply-To: <28837957-421a-eeff-8304-cfafb80ca234@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [174.61.159.182]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR21MB0020; 7:beYPhwz32i4wDnM+s+k5J28Zmw+wKyI/ASBGkIIu8JVDrO72pjYqiKmyUmrSCIc4+S3gjKQHhbRY/F6NMXuoJayjdT77zpJ3VT6RqpccKRD2zpe3RO149Y3UWEr3442m+TFOR2StpeoeV2hxqmeVpdE/KQQ8PB1rOq/QQ3X3zcAkPkk68TvW4LJg1O1Ahq1yBkBQK1VdTekazoJf9Y/ipsqucxsP9Fmgrh9vTPj7K2Aoc06EtM20Ck5D1176tBVJQnXwWdSzG3FDaebzxadSGOD0ymmHSkifacvBSNY+ifgUn+cH3nv4g1kZgtfSHCF+lZdkGEl7x0ktQNvj3qiaHu5VA2pKZIsjMkcH1MPKzpg=
x-ms-traffictypediagnostic: BY2PR21MB0020:
x-ms-office365-filtering-correlation-id: def5aac5-78a7-4f31-194d-08d4a241d798
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);  SRVR:BY2PR21MB0020; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(166708455590820);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700054)(100105000095)(100000701053)(100105300095)(100000702053)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703053)(100105400095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(100000704053)(100105200095)(100000705053)(100105500095); SRVR:BY2PR21MB0020; BCL:0; PCL:0; RULEID:(100000800053)(100110000095)(100000801053)(100110300095)(100000802053)(100110100095)(100000803053)(100110400095)(100000804053)(100110200095)(100000805045)(100110500095); SRVR:BY2PR21MB0020; 
x-forefront-prvs: 031763BCAF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39410400002)(39450400003)(39400400002)(39840400002)(39850400002)(24454002)(377454003)(8936002)(5005710100001)(10090500001)(53936002)(66066001)(25786009)(9686003)(55016002)(53546009)(6436002)(54906002)(6506006)(6306002)(77096006)(229853002)(99286003)(6246003)(8676002)(81166006)(38730400002)(2950100002)(189998001)(4326008)(74316002)(3660700001)(7696004)(3846002)(102836003)(5660300001)(33656002)(6116002)(10290500003)(72206003)(478600001)(230783001)(2906002)(966005)(122556002)(2900100001)(76176999)(54356999)(305945005)(3280700002)(86362001)(7736002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR21MB0020; H:BY2PR21MB0084.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2017 01:11:43.7153 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR21MB0020
Archived-At: 
Subject: Re: [core] Eric Rescorla's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 01:11:49 -0000

DQpPbiAwNS8xMC8yMDE3IDAzOjI0IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyB3cm90ZToNCltvcmln
aW5hbCByZXNwb25zZSBAIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvY29y
ZS9jdXJyZW50L21zZzA4NzM5Lmh0bWxdDQoNCj4+IA0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gRElT
Q1VTUzoNCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gLQ0KPj4NCj4+IEFmdGVyIHJlYWRpbmcgTWFyayBO
b3R0aW5naGFtJ3MgcmV2aWV3LCBJJ20gcGVyc3VhZGVkIHdlIHNob3VsZCBhdCANCj4+IGxlYXN0
IGRpc2N1c3MgdGhlIHJlbGF0aW9uc2hpcCBvZiB0aGlzIHdvcmsgdG8gdGhlIHBhcmFsbGVsIHdv
cmsgaW4gSFRUUC4NCj4+IA0KPHNuaXA+DQoNCj4gSSBhbHNvIGRvIG5vdCBzZWUgYSBjb21wZXRp
dGlvbiBiZXR3ZWVuIENvQVAgYW5kIEhUVFAvMi4gV2hhdCB0aGlzIGluaXRpYWxseSB0cmllZCB0
byBkbyBpcyB0byBkZXNjcmliZSBob3cgc29tZQ0KPiBjb21wYW5pZXMgKEFSTSwgTWljcm9zb2Z0
LCBaZWJyYSkgaGF2ZSBiZWVuIGRlcGxveWluZyBDb0FQIGluIGVudGVycHJpc2UgbmV0d29ya3Mg
dGhhdCBibG9jayBVRFAgdHJhZmZpYy4NCg0KU2Ftc3VuZyB0b28uIEFuZCBwZXJoYXBzIG9uZSBv
ZiBvdXIgT0NGK0lFVEYgcGFydGljaXBhbnRzIGNvdWxkIHNwZWFrIHRvIHRoZSBjdXJyZW50IE9D
RiBhbmQvb3IgSW9UaXZpdHkgc3RhdHVzLiBTZWUgYWxzbyB0aGlzIHByZXNlbnRhdGlvbiAtIGh0
dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0tMjAxNi10MnRyZy0wMy9zbGlk
ZXMvc2xpZGVzLWludGVyaW0tMjAxNi10MnRyZy0wMy1zZXNzYS1pb3Rpdml0eS1zdGF0dXMtYW5k
LWZ1dHVyZS1kaXJlY3Rpb24tMDAucGRmDQoNCj4gV2h5IGl0IHRha2VzIDIgeWVhcnMgdG8gc3Rh
bmRhcmRpemUgc3VjaCBiYXNpYyBmZWF0dXJlcyBpcyBhIG15c3RlcnkgdG8gbWUuDQo+IEluIHRo
ZSBsb25nIHJ1biwgdGhlIHN0b3J5IGZvciBJb1QgZGV2aWNlcyBtYXkgYmUgUVVJQyAmIEhUVFAv
MiBidXQgdG9kYXkgSFRUUC8yIG9uIElvVCBkZXZpY2VzIGlzIGVzc2VudGlhbGx5IG5vbi1leGlz
dGVudC4NCg0KRW5jb3VyYWdlZCBieSBEYXZlIFRoYWxlciwgdGhlcmUgd2FzIGEgY2FuZGlkIGRp
c2N1c3Npb24gb2YgcmF0aW9uYWxlIGluIGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2NvYXAt
dGNwLXRscy9pc3N1ZXMvNTAuIEFzIEhhbm5lcyB3cm90ZSBpbiB0aGUgaXNzdWU6DQoNCiAgICBJ
IGNhbiBnaXZlIHlvdSB0aGUgbW90aXZhdGlvbiB3aHkgd2UgYXJlIGludGVyZXN0ZWQgaW4gQ29B
UCBvdmVyIFRMUyAvVENQLiBXZSBoYXZlIGFuIGV4aXN0aW5nIGltcGxlbWVudGF0aW9uIG9mIExX
TTJNLA0KICAgIHdoaWNoIHVzZXMgQ29BUC4gV2Ugc3BlbnQgYSBsb3Qgb2YgdGltZSBnZXR0aW5n
IHRoYXQgaW1wbGVtZW50YXRpb24gcm9jay1zb2xpZC4gU29tZSBlbnRlcnByaXNlIGRlcGxveW1l
bnRzLCB3aGljaCBoYXBwZW4NCiAgICB0byBoYXZlIGludGVyZXN0aW5nIGZpcmV3YWxsIHBvbGlj
aWVzLCBkbyBub3QgYWxsb3cgdXMgdG8gdXNlIFVEUC4gSGVuY2UsIHdlIHdlcmUgaW50ZXJlc3Rl
ZCB0byBhZGQgYSBUQ1AtYmFzZWQgdHJhbnNwb3J0IHRvIENvQVAuICAgICANCiAgICBNYWtpbmcg
dGhpcyBlbmhhbmNlbWVudCB0dXJucyBvdXQgdG8gYmUgcmVhc29uYWJseSBzaW1wbGUuDQoNCiAg
ICBBcyBDYXJzdGVuIGV4cGxhaW5lZCwgQ29BUCBoYXMgZm91bmQgaXRzIHdheSBpbnRvIHZhcmlv
dXMgU0RPcyBhbmQgdGhhdCdzIHdoYXQgcGVvcGxlIG5vdyBpbXBsZW1lbnQuIENvQVAgaXMgc29y
dC1vZiB1bmRlcnN0b29kDQogICAgYW5kIHRoZXJlIGFyZSBsb3RzIG9mIGltcGxlbWVudGF0aW9u
cyBhdmFpbGFibGUuIFN3aXRjaGluZyB0byBzb21ldGhpbmcgZWxzZSB0YWtlcyB0aW1lIGFuZCBy
ZXNvdXJjZXMuIFRoZXJlIGFyZSBhbHNvIG11Y2ggZmV3ZXIgDQogICAgaW1wbGVtZW50YXRpb25z
IG9mIEhUVFAvMiBmb3IgZW1iZWRkZWQgZGV2aWNlcyBhdmFpbGFibGUuICBNYXliZSBpbiBhIGZl
dyB5ZWFycyB3ZSB3aWxsIGJlIHVzaW5nIEhUVFAvMiBpbnN0ZWFkIG9mIENvQVAgb3ZlciANCiAg
ICBUQ1AvVExTIGJ1dCB0b2RheSB3ZSBqdXN0IHdhbnQgdG8gZ2V0IG91ciBleGlzdGluZyBkZXBs
b3ltZW50cyBkb2N1bWVudCBhbmQgc3RhbmRhcmRpemVkLiBJIGFtIHN1cmUgdGhhdCBwZW9wbGUg
d2lsbCB0YWtlIGEgY2xvc2VyIGxvb2sgDQogICAgYXQgdGhlIGRpZmZlcmVudCBvcHRpb25zIGlu
IG1vcmUgZGV0YWlsIGluIHRoZSBmdXR1cmUuDQoNCldoaWxlIHRoZSBESVNDVVNTIGlzIHBlcmZl
Y3RseSByZWFzb25hYmxlIChJIHJhaXNlZCBzaW1pbGFyIHF1ZXN0aW9ucyBhYm91dCBJRVRGIGd1
aWRhbmNlIGluIHRoZSBnaXRodWIgaXNzdWUgYWJvdmUpLCBpdCBmZWVscyBpbm9wcG9ydHVuZSB0
aGF0IHRoaXMgc3BlY2lmaWMgY29uY2VybiBpcyBiZWluZyBleHByZXNzZWQgc28gbGF0ZSBpbiB0
aGUgcHJvY2VzcyByYXRoZXIgdGhhbiBkdXJpbmcgcHJvcG9zZWQgYWRvcHRpb24gb2YgdGhlIHdv
cmtpbmcgZHJhZnQgZXNwZWNpYWxseSBzaW5jZSBib3RoIFdHcyBhcmUgaW4gdGhlIHNhbWUgQXJl
YS4gDQoNCkRhdmUgVGhhbGVyJ3MgaXNzdWUgd2FzIHByb21wdGVkIGJ5IEdhYnJpZWwgTW9udGVu
ZWdybydzIEhUVFBiaXMgcHJlc2VudGF0aW9uIGF0IElFVEYgOTYgd2hpY2ggZXhwbG9yZWQgcHJv
dG9jb2wgcmV1c2UgLyBIVFRQLzIgYXZhaWxhYmlsaXR5IC0gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
cHJvY2VlZGluZ3MvOTYvc2xpZGVzL3NsaWRlcy05Ni1odHRwYmlzLTMucGRmLiAgVGhpcyB3YXMg
YSBzZWNvbmQgbmF0dXJhbCBvcHBvcnR1bml0eSBmb3IgZWFybHkgcXVlc3Rpb25zIHRvIGJlIHJh
aXNlZCBiZXR3ZWVuIHRoZSBIVFRQYmlzIGFuZCBDb1JFIGNoYWlycz8NCg0KLi4uQnJpYW4NCg0K
DQo=


From nobody Tue May 23 18:22:47 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7972312EB05; Tue, 23 May 2017 18:22:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.481
X-Spam-Level: 
X-Spam-Status: No, score=-0.481 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 qLb_0ea-UWWC; Tue, 23 May 2017 18:22:44 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6A4011279EB; Tue, 23 May 2017 18:22:44 -0700 (PDT)
Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4O1MXs5004052 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 May 2017 20:22:34 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local
To: Brian Raymor , Hannes Tschofenig , Carsten Bormann , Eric Rescorla 
Cc: "core-chairs@ietf.org" , The IESG , "core@ietf.org" , "draft-ietf-core-coap-tcp-tls@ietf.org" 
References: <149411155754.23175.15150224037348429928.idtracker@ietfa.amsl.com>  <28837957-421a-eeff-8304-cfafb80ca234@gmx.net> 
From: Adam Roach 
Message-ID: <2ba93ff7-c2f2-c5e4-cd67-0f7c1d412051@nostrum.com>
Date: Tue, 23 May 2017 20:22:28 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [core] Eric Rescorla's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 01:22:45 -0000

On 5/23/17 20:11, Brian Raymor wrote:
>      I can give you the motivation why we are interested in CoAP over TLS /TCP. We have an existing implementation of LWM2M,
>      which uses CoAP. We spent a lot of time getting that implementation rock-solid. Some enterprise deployments, which happen
>      to have interesting firewall policies, do not allow us to use UDP. Hence, we were interested to add a TCP-based transport to CoAP.
>      Making this enhancement turns out to be reasonably simple.


I'll note that the rationale for using WebSockets for this purpose 
appears to be significantly less clear, and the combination of TCP and 
WebSockets into a single document even more so.

/a


From nobody Tue May 23 19:56:29 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1646212943A; Tue, 23 May 2017 19:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 QDgQ54hghccQ; Tue, 23 May 2017 19:56:17 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0121.outbound.protection.outlook.com [104.47.37.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9A6A1200C1; Tue, 23 May 2017 19:56:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8sn570Gn5k+OsjqtgtP1N+Dkyc50qhmCrEYWvNmr9Qs=; b=SRz6B3BrLY+Pa2IfG15c+tEZQB0Cs1wAdq92qRKHFqF4GTokYhakQLLHMuh0+T35hbI6VTqzOIHwThfvlXH/0U6EEeSBCYVuWQzSbq/MqJIPszmfPMR6zK5LMcdP93VqG/48zjdswjGrubAEfe0DY1tqTwKBvUvr4AY005VkLko=
Received: from BY2PR21MB0084.namprd21.prod.outlook.com (10.162.78.141) by BY2PR21MB0082.namprd21.prod.outlook.com (10.162.78.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.0; Wed, 24 May 2017 02:56:15 +0000
Received: from BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) by BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) with mapi id 15.01.1143.000; Wed, 24 May 2017 02:56:15 +0000
From: Brian Raymor 
To: Adam Roach , Hannes Tschofenig , Carsten Bormann , Eric Rescorla 
CC: "core-chairs@ietf.org" , The IESG , "core@ietf.org" , "draft-ietf-core-coap-tcp-tls@ietf.org" 
Thread-Topic: [core] Eric Rescorla's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
Thread-Index: AQHSyVSAMpIwzIhBiUGz2Gs5B08R+qHtXEWAgBVTRFCAABY3AIAAGUYA
Date: Wed, 24 May 2017 02:56:14 +0000
Message-ID: 
References: <149411155754.23175.15150224037348429928.idtracker@ietfa.amsl.com>  <28837957-421a-eeff-8304-cfafb80ca234@gmx.net>  <2ba93ff7-c2f2-c5e4-cd67-0f7c1d412051@nostrum.com>
In-Reply-To: <2ba93ff7-c2f2-c5e4-cd67-0f7c1d412051@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: nostrum.com; dkim=none (message not signed) header.d=none;nostrum.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [174.61.159.182]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR21MB0082; 7:b7ruLf9Yo1ste87hsfdEjJSLdHETGmxZSSRu0qNmMqcGHwYBbPq/FlXzNywTGE9K5BkThRDk/ryB38pyldlPfI/3mFMdsoSVdompk4ZLtg3rHgtgg+Ze50oUgyFXjSaqP73P0K+4lhakzh9Taa1y5ueMOjufCw4Wc0imvUENyQ/YBerqjHFUc7Dy+iRwP818LC81+z8Q93mDHPX9MxW9X7Kue14N7I9pd8zxcK1r4MmPNVNbsWqEF+Xz1j7/oWJFFveICRpW+U2j7F/JfrwAIpkfOsz93lMBIQ6soy9ZRfu5bbrAJ9Rs9NWZ9xKyr3t+8QGrbti43g86fw41D1dadgqbDKyg/634CFaqWzFqzfY=
x-ms-traffictypediagnostic: BY2PR21MB0082:
x-ms-office365-filtering-correlation-id: f6e35597-3832-44fb-e361-08d4a250719d
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);  SRVR:BY2PR21MB0082; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700054)(100105000095)(100000701054)(100105300095)(100000702054)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(100000703054)(100105400095)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123564025)(6072148)(100000704054)(100105200095)(100000705054)(100105500095); SRVR:BY2PR21MB0082; BCL:0; PCL:0; RULEID:(100000800054)(100110000095)(100000801054)(100110300095)(100000802054)(100110100095)(100000803054)(100110400095)(100000804054)(100110200095)(100000805047)(100110500095); SRVR:BY2PR21MB0082; 
x-forefront-prvs: 031763BCAF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39850400002)(39400400002)(39840400002)(39860400002)(39450400003)(377454003)(24454002)(66066001)(4326008)(5660300001)(53936002)(33656002)(2950100002)(230783001)(966005)(122556002)(6246003)(8936002)(38730400002)(6116002)(7736002)(478600001)(8676002)(72206003)(81166006)(102836003)(6436002)(3660700001)(55016002)(3280700002)(74316002)(76176999)(54356999)(50986999)(10090500001)(6506006)(77096006)(86362001)(305945005)(54906002)(9686003)(99286003)(93886004)(53546009)(6306002)(25786009)(5005710100001)(7696004)(229853002)(2900100001)(189998001)(10290500003)(2906002)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR21MB0082; H:BY2PR21MB0084.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2017 02:56:14.9635 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR21MB0082
Archived-At: 
Subject: Re: [core] Eric Rescorla's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 02:56:20 -0000

DQpPbiA1LzIzLzE3IDY6MjIgUE0sIEFkYW0gUm9hY2ggd3JvdGU6DQo+PiAgICAgIEkgY2FuIGdp
dmUgeW91IHRoZSBtb3RpdmF0aW9uIHdoeSB3ZSBhcmUgaW50ZXJlc3RlZCBpbiBDb0FQIG92ZXIg
VExTIC9UQ1AuIFdlIGhhdmUgYW4gZXhpc3RpbmcgaW1wbGVtZW50YXRpb24gb2YgTFdNMk0sDQo+
PiAgICAgIHdoaWNoIHVzZXMgQ29BUC4gV2Ugc3BlbnQgYSBsb3Qgb2YgdGltZSBnZXR0aW5nIHRo
YXQgaW1wbGVtZW50YXRpb24gcm9jay1zb2xpZC4gU29tZSBlbnRlcnByaXNlIGRlcGxveW1lbnRz
LCB3aGljaCBoYXBwZW4NCj4+ICAgICAgdG8gaGF2ZSBpbnRlcmVzdGluZyBmaXJld2FsbCBwb2xp
Y2llcywgZG8gbm90IGFsbG93IHVzIHRvIHVzZSBVRFAuIEhlbmNlLCB3ZSB3ZXJlIGludGVyZXN0
ZWQgdG8gYWRkIGEgVENQLWJhc2VkIHRyYW5zcG9ydCB0byBDb0FQLg0KPj4gICAgICBNYWtpbmcg
dGhpcyBlbmhhbmNlbWVudCB0dXJucyBvdXQgdG8gYmUgcmVhc29uYWJseSBzaW1wbGUuDQoNCj4g
SSdsbCBub3RlIHRoYXQgdGhlIHJhdGlvbmFsZSBmb3IgdXNpbmcgV2ViU29ja2V0cyBmb3IgdGhp
cyBwdXJwb3NlIGFwcGVhcnMgdG8gYmUgc2lnbmlmaWNhbnRseSBsZXNzIGNsZWFyLCBhbmQgdGhl
IGNvbWJpbmF0aW9uIG9mIFRDUCBhbmQgDQo+IFdlYlNvY2tldHMgaW50byBhIHNpbmdsZSBkb2N1
bWVudCBldmVuIG1vcmUgc28uDQoNCkkgYWdyZWUgd2l0aCB3aGF0IEhhbm5lcyB3cm90ZSBpbiBo
aXMgZWFybGllciByZXNwb25zZSB0byB5b3UgLSBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFy
Y2hpdmUvd2ViL2NvcmUvY3VycmVudC9tc2cwODcyOS5odG1sIC0gDQoNCiAgICBUaGUgYXV0aG9y
cyBvZiB0aGUgZG9jdW1lbnQgaGF2ZSBkaWZmZXJlbnQgdmlld3MgYWJvdXQgdGhlIGluY2x1c2lv
biBvZiB0aGUgc3VwcG9ydCBvZiBXZWJTb2NrZXRzIGluIHRoZSBkb2N1bWVudC4NCiAgICBJIGxl
YXZlIGl0IHRvIHRoZSByZXNwb25zaWJsZSBBRCB0byBkZWNpZGUgd2hhdCB0aGUgYmVzdCBkb2N1
bWVudCBzdHJ1Y3R1cmUgaXMgYW5kIHdoYXQgaXMgaW5kZWVkIGNvdmVyZWQgYXMgcGFydCBvZiB0
aGUNCiAgICBDT1JFIHdvcmtpbmcgZ3JvdXAgY2hhcnRlci4NCg0KSSB3b3VsZCBlbmNvdXJhZ2Ug
dGhlIGF1dGhvcnMgb2YgZHJhZnQtc2F2b2xhaW5lbi1jb3JlLWNvYXAtd2Vic29ja2V0cyAoYmFz
ZWQgb24gdGhlaXIgc3BlY2lmaWMgZG9tYWluIGV4cGVydGlzZSkgdG8gd2VpZ2ggaW4gb24gc29t
ZSBvZiB0aGUgV2ViU29ja2V0cyBxdWVzdGlvbnMvY29uY2VybnMgcmFpc2VkIGFyaXNpbmcgZHVy
aW5nIHRoZXNlIHJldmlld3MuIA0KDQouLi5Ccmlhbg0KDQoNCg==


From nobody Tue May 23 20:37:49 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F62D12941C; Tue, 23 May 2017 20:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level: 
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 xB2kq0rKhb7K; Tue, 23 May 2017 20:37:38 -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 6133A126CB6; Tue, 23 May 2017 20:37:38 -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 v4O3bXox016471; Wed, 24 May 2017 05:37:33 +0200 (CEST)
Received: from [172.31.0.79] (athedsl-143215.home.otenet.gr [85.75.231.14]) (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 3wXdPn2XGKzDH3f; Wed, 24 May 2017 05:37:33 +0200 (CEST)
Content-Type: multipart/alternative; boundary=Apple-Mail-893474F8-65B3-4B27-9EEB-9D52EC45631F
Mime-Version: 1.0 (1.0)
From: Carsten Bormann 
X-Mailer: iPhone Mail (14F89)
In-Reply-To: 
Date: Wed, 24 May 2017 06:37:30 +0300
Cc: Adam Roach , Hannes Tschofenig , Eric Rescorla , "core-chairs@ietf.org" , The IESG , "core@ietf.org" , "draft-ietf-core-coap-tcp-tls@ietf.org" 
Content-Transfer-Encoding: 7bit
Message-Id: <0D86F872-62CE-4D06-AB4A-A18F94A1061D@tzi.org>
References: <149411155754.23175.15150224037348429928.idtracker@ietfa.amsl.com>  <28837957-421a-eeff-8304-cfafb80ca234@gmx.net>  <2ba93ff7-c2f2-c5e4-cd67-0f7c1d412051@nostrum.com> 
To: Brian Raymor 
Archived-At: 
Subject: Re: [core] Eric Rescorla's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 03:37:41 -0000

--Apple-Mail-893474F8-65B3-4B27-9EEB-9D52EC45631F
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Websockets is in the same document beause it is 95 % the same problem.  Of c=
ourse, we could split off the 5 % into a separate document as a delta from T=
CP. I fail to see why (except maybe as a ploy to get more of the original au=
thors accommodated).

Sent from mobile

> On 24. May 2017, at 05:56, Brian Raymor  wrote=
:
>=20
>=20
> On 5/23/17 6:22 PM, Adam Roach wrote:
>>>     I can give you the motivation why we are interested in CoAP over TLS=
 /TCP. We have an existing implementation of LWM2M,
>>>     which uses CoAP. We spent a lot of time getting that implementation r=
ock-solid. Some enterprise deployments, which happen
>>>     to have interesting firewall policies, do not allow us to use UDP. H=
ence, we were interested to add a TCP-based transport to CoAP.
>>>     Making this enhancement turns out to be reasonably simple.
>=20
>> I'll note that the rationale for using WebSockets for this purpose appear=
s to be significantly less clear, and the combination of TCP and=20
>> WebSockets into a single document even more so.
>=20
> I agree with what Hannes wrote in his earlier response to you - https://ww=
w.ietf.org/mail-archive/web/core/current/msg08729.html -=20
>=20
>    The authors of the document have different views about the inclusion of=
 the support of WebSockets in the document.
>    I leave it to the responsible AD to decide what the best document struc=
ture is and what is indeed covered as part of the
>    CORE working group charter.
>=20
> I would encourage the authors of draft-savolainen-core-coap-websockets (ba=
sed on their specific domain expertise) to weigh in on some of the WebSocket=
s questions/concerns raised arising during these reviews.=20
>=20
> ...Brian
>=20
>=20
>=20
>=20

--Apple-Mail-893474F8-65B3-4B27-9EEB-9D52EC45631F
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Websockets is in the same document bea=
use it is 95 % the same problem.  Of course, we could split off the 5 %=
 into a separate document as a delta from TCP. I fail to see why (except may=
be as a ploy to get more of the original authors accommodated).

Sent f=
rom mobile

On 5/23/17 6:22 PM, Adam Roach wrot=
e:
 &nbs=
p;   I can give you the motivation why we are interested in C=
oAP over TLS /TCP. We have an existing implementation of LWM2M,
=
     which uses CoAP. We spent a lot of time getti=
ng that implementation rock-solid. Some enterprise deployments, which happen=

     to have interesting firewall pol=
icies, do not allow us to use UDP. Hence, we were interested to add a TCP-ba=
sed transport to CoAP.
     Making this e=
nhancement turns out to be reasonably simple.

I'll note that the ra=
tionale for using WebSockets for this purpose appears to be significantly le=
ss clear, and the combination of TCP and 
WebSockets into a single document even more so.<=
br>

I agree with what Hannes wrote in his=
 earlier response to you - https://www.ietf.org/mail-archive/web/core/curre=
nt/msg08729.html - 

    =
The authors of the document have different views about the inclusion of the s=
upport of WebSockets in the document.
    I l=
eave it to the responsible AD to decide what the best document structure is a=
nd what is indeed covered as part of the
    =
CORE working group charter.

I would encoura=
ge the authors of draft-savolainen-core-coap-websockets (based on their spec=
ific domain expertise) to weigh in on some of the WebSockets questions/conce=
rns raised arising during these reviews. 

.=
..Brian



<=
/span>
=

--Apple-Mail-893474F8-65B3-4B27-9EEB-9D52EC45631F--


From nobody Wed May 24 14:01:56 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F824129BC5 for ; Wed, 24 May 2017 14:01:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.902
X-Spam-Level: 
X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 nbYsuij9tQEb for ; Wed, 24 May 2017 14:01:53 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0123.outbound.protection.outlook.com [104.47.41.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B6E0127B52 for ; Wed, 24 May 2017 14:01:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WOdM0njOfvQlrAC9208fcKeJcJe1D+BhMEKP0MWoUKI=; b=NrB41BSj+Y6sJx6ddkD/6vYZNlvxOWWGIZkPq13BXr4dIOe+awSK3p9L5MfPXWIMLEVMtMVu+choIZ4yc14nbTEMhxjyRmbRY+l+KPuSc0/mfqjXwDP8xOzldPujyU224mjVgfy9ge1dOtmFXq0koHT2AbnjgSGy3VzzCyz/cz8=
Received: from CY1PR03MB2265.namprd03.prod.outlook.com (10.166.207.17) by CY1PR03MB2268.namprd03.prod.outlook.com (10.166.207.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.14; Wed, 24 May 2017 21:01:51 +0000
Received: from CY1PR03MB2265.namprd03.prod.outlook.com ([10.166.207.17]) by CY1PR03MB2265.namprd03.prod.outlook.com ([10.166.207.17]) with mapi id 15.01.1101.021; Wed, 24 May 2017 21:01:50 +0000
From: Dave Thaler 
To: "core@ietf.org" , "draft-hartke-core-e2e-security-reqs@tools.ietf.org" 
Thread-Topic: Review of draft-hartke-core-e2e-security-reqs-02
Thread-Index: AdLU0LHxUYhfD02QSd2bBNDnr/6y3A==
Date: Wed, 24 May 2017 21:01:50 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:d::3fe]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY1PR03MB2268; 7:X3988cSbYRtbijVUJDYgiYQouxE/Xcz/1uuwWqo5Yg1sAVGLTJmiAD9XTFUhKBtTFrMYBHL6ByFmdszRQMXyuC0a8h2Ca7BCvs/vlBIx2k+/l6Udt0m3FT79hvgNAZP5v4tgODMlHNWb0pW3Dk8AvS8zJGJCy7m+f6akq1lxmS92+ktILE6wzuDfnfowy4PHA+JR80vwoGWqpZAUZ/Gc1I2UvB0sk2xIdB6CrzVLQm+RmldMw8OM8iLAFby2r7pGHprmZQNHK+U1vybKGWcnws0tIyyBw86GXOrlnnOjY5PHqXV4yfWoUHUD1dCnE9Xiuoa8FGqpAOYrWwA6pXGRr3XY1Pq0mzW5/mkCeWw2i5M=
x-ms-traffictypediagnostic: CY1PR03MB2268:
x-ms-office365-filtering-correlation-id: 4b44eea0-6e82-4f54-23f9-08d4a2e8197b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:CY1PR03MB2268; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(43050042349365)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(6072148); SRVR:CY1PR03MB2268; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2268; 
x-forefront-prvs: 031763BCAF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39860400002)(39450400003)(39410400002)(39840400002)(39400400002)(3905003)(2501003)(3660700001)(25786009)(7906003)(38730400002)(33656002)(74316002)(8676002)(7736002)(10090500001)(3280700002)(122556002)(50986999)(54356999)(81166006)(230783001)(2900100001)(7110500001)(189998001)(2906002)(10710500007)(8936002)(790700001)(5660300001)(7696004)(236005)(478600001)(5005710100001)(6436002)(8990500004)(966005)(606005)(15650500001)(55016002)(6506006)(10290500003)(2420400007)(102836003)(6116002)(53936002)(86612001)(77096006)(86362001)(6306002)(99286003)(9686003)(54896002)(12290500005)(15398625002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2268; H:CY1PR03MB2265.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR03MB22652AC8DF6A20D641D7B2ACA3FE0CY1PR03MB2265namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2017 21:01:50.8414 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2268
Archived-At: 
Subject: [core] Review of draft-hartke-core-e2e-security-reqs-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 21:01:55 -0000

--_000_CY1PR03MB22652AC8DF6A20D641D7B2ACA3FE0CY1PR03MB2265namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

At last IETF, I took an action item to provide a review of draft-hartke-cor=
e-e2e-security-reqs.

I've put a PDF of my marked up copy with my comments at:
https://www.microsoft.com/en-us/research/wp-content/uploads/2017/05/draft-h=
artke-core-e2e-security-reqs-02.pdf

Hopefully the authors can digest the comments and then we can discuss on th=
e list anything that's non-trivial.

Dave

--_000_CY1PR03MB22652AC8DF6A20D641D7B2ACA3FE0CY1PR03MB2265namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











At last IETF, I took an action item to provide a rev=
iew of draft-hartke-core-e2e-security-reqs.


 


I’ve put a PDF of my marked up copy with my co=
mments at:


http=
s://www.microsoft.com/en-us/research/wp-content/uploads/2017/05/draft-hartk=
e-core-e2e-security-reqs-02.pdf


 


Hopefully the authors can digest the comments and th=
en we can discuss on the list anything that’s non-trivial.=



 


Dave






--_000_CY1PR03MB22652AC8DF6A20D641D7B2ACA3FE0CY1PR03MB2265namp_--


From nobody Fri May 26 10:27:02 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31F4129329; Fri, 26 May 2017 10:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 CmZH21WVBzwy; Fri, 26 May 2017 10:27:00 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0124.outbound.protection.outlook.com [104.47.36.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39F9C1294EC; Fri, 26 May 2017 10:27:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uHZtzCWBee3uC+xyfLZoI2ukG+29FgbuzlG4DUzTAkE=; b=VaQ1c+yO8srLRfy3IGUfrpCMPMpMSJ5R/vPj1IGj4bC64hswkiRfG6VHbmMezwaineiDcqB+YiUD8v2JPTLekqinjMGKXHnyJgsiu50fU53HwMepBPBJB1vt5pAV6fAMRTQUvd3AaSLCjnBWwJEdwmkEEGRJrNvI/MdeZK8v7CA=
Received: from CO2PR03MB2262.namprd03.prod.outlook.com (10.166.92.143) by CO2PR03MB2263.namprd03.prod.outlook.com (10.166.92.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1124.9; Fri, 26 May 2017 17:26:58 +0000
Received: from CO2PR03MB2262.namprd03.prod.outlook.com ([10.166.92.143]) by CO2PR03MB2262.namprd03.prod.outlook.com ([10.166.92.143]) with mapi id 15.01.1124.011; Fri, 26 May 2017 17:26:55 +0000
From: Dave Thaler 
To: Brian Raymor , Hannes Tschofenig , Carsten Bormann , Eric Rescorla 
CC: "core-chairs@ietf.org" , The IESG , "core@ietf.org" , "draft-ietf-core-coap-tcp-tls@ietf.org" 
Thread-Topic: [core] Eric Rescorla's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
Thread-Index: AQHSxrxpEEhegL9g70yjQJ7jbhMft6HtG3cAgABF/4CAFWZ6gIAENR8Q
Date: Fri, 26 May 2017 17:26:55 +0000
Message-ID: 
References: <149411155754.23175.15150224037348429928.idtracker@ietfa.amsl.com>  <28837957-421a-eeff-8304-cfafb80ca234@gmx.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: microsoft.com; dkim=none (message not signed) header.d=none;microsoft.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:3::3fe]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CO2PR03MB2263; 7:FhFtUQHtM+/y6o3aidpjUq/xu9/MF2mRCM1iQNjg3BKWQe0CR7rQ4UlRkSnipkJamz8zNcxcKQVLMBgVu9klPLQ46fo/58DYIKYfbI+V24nJjL0M0MOFUKRsd5tEqJClkwSiIz86l4ReSnQl5X4knAxY3NhLOP/FENgRggVhHzNgkZYujTkKEBe4TBDgTKKTqlfJrcocrbx2Zls0auX3IjNCvzY4cJxN83oDXb2vkMFH5V5wbsAkXIM+LtuX8SOcd1oVK0MeXN9qq4Rj/rSV0xjJLqkKvJxnOHYnw7cn6y5CTnU2Po+vOYeMs+GTLheVZQOkLtJ/75a1EuQDgoRXxe67wKd0DVMgicllsOGhIxI=
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39450400003)(39850400002)(39410400002)(39860400002)(39840400002)(24454002)(102836003)(74316002)(6116002)(93886004)(3280700002)(2906002)(4326008)(2950100002)(3660700001)(81166006)(10290500003)(6246003)(478600001)(86362001)(38730400002)(86612001)(14454004)(230783001)(8936002)(2561002)(966005)(8676002)(6436002)(9686003)(54906002)(6306002)(2900100001)(55016002)(305945005)(99286003)(77096006)(8990500004)(10090500001)(229853002)(7736002)(189998001)(53936002)(25786009)(1511001)(5660300001)(76176999)(122556002)(50986999)(7696004)(33656002)(54356999)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2263; H:CO2PR03MB2262.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-ms-traffictypediagnostic: CO2PR03MB2263:
x-ms-office365-filtering-correlation-id: 2b518d60-c3f3-4e29-e91b-08d4a45c6828
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);  SRVR:CO2PR03MB2263; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(166708455590820)(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700061)(100105000095)(100000701061)(100105300095)(100000702061)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703061)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123558100)(20161123555025)(6072148)(100000704061)(100105200095)(100000705061)(100105500095); SRVR:CO2PR03MB2263; BCL:0; PCL:0; RULEID:(100000800061)(100110000095)(100000801061)(100110300095)(100000802061)(100110100095)(100000803061)(100110400095)(100000804061)(100110200095)(100000805054)(100110500095); SRVR:CO2PR03MB2263; 
x-forefront-prvs: 031996B7EF
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2017 17:26:55.5028 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2263
Archived-At: 
Subject: Re: [core] Eric Rescorla's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 17:27:02 -0000

QnJpYW4gUmF5bW9yIHdyb3RlOg0KPiBTYW1zdW5nIHRvby4gQW5kIHBlcmhhcHMgb25lIG9mIG91
ciBPQ0YrSUVURiBwYXJ0aWNpcGFudHMgY291bGQgc3BlYWsgdG8gdGhlIGN1cnJlbnQgT0NGDQo+
IGFuZC9vciBJb1Rpdml0eSBzdGF0dXMuDQoNCkkgYmVsaWV2ZSBPQ0YganVzdCBzZW50IGEgbGlh
aXNvbiBzdGF0ZW1lbnQgb24gdGhpcyB0b3BpYywgYmFzZWQgb24gT0NGIGNvbnNlbnN1cyBhdCBh
IG1lZXRpbmcgZWFybGllciB0aGlzIHdlZWssIHdoaWNoIHNob3VsZCBhbnN3ZXIgdGhhdCBxdWVz
dGlvbiAoaW4gc2hvcnQ6IGl0J3MgaW1wbGVtZW50ZWQgaW4gaW90aXZpdHksIG5vcm1hdGl2ZWx5
IHJlZmVyZW5jZWQgaW4gT0NGIHNwZWNzIHRoYXQgYXJlIGluIHRoZSBwcm9jZXNzIG9mIGJlaW5n
IHB1Ymxpc2hlZC4uLiBzb3J0IG9mIGxpa2Ugc2l0dGluZyBpbiB0aGUgUkZDIGVkaXRvcnMgcXVl
dWUsIGFuZCBleHBlY3RlZCB0byBiZSBpbiBsb3RzIG9mIHByb2R1Y3RzIHNoaXBwaW5nICJzb29u
IikuDQoNCk15IHVuZGVyc3RhbmRpbmcgKGl0IHdhcyBiZWZvcmUgbXkgdGltZSkgaXMgdGhhdCB0
aGUgY2hvaWNlIG9mIHVzaW5nIENPQVAgKG92ZXIgVURQKSB3YXMgbWFkZSBsb25nIGJlZm9yZSBI
VFRQLzIgd2FzIGEgdGhpbmcgYW5kIHNvIHVzaW5nIENPQVAgb3ZlciBvdGhlciB1bmRlcmx5aW5n
IGxheWVycyB3YXMgYSBuYXR1cmFsIGV4dGVuc2lvbi4gICBPbGRlciBPSUMgc3BlY3MgZGlkIGhh
dmUgYSBwYXJ0aWFsIHNwZWNpZmljYXRpb24gb2YgT0NGIG92ZXIgSFRUUChTKSwgYnV0IGFzIGl0
IHdhcyBuZXZlciBmdWxseSBmbGVzaGVkIG91dCBpdCB3YXMgcmVtb3ZlZCBmcm9tIGxhdGVyIHNw
ZWNzIGFuZCBjdXJyZW50IElvdGl2aXR5IGNvZGUgaW1wbGVtZW50aW5nIE9DRiBwcm90b2NvbHMg
anVzdCB1c2VzIGNvYXAuDQoNCj4gRW5jb3VyYWdlZCBieSBEYXZlIFRoYWxlciwgdGhlcmUgd2Fz
IGEgY2FuZGlkIGRpc2N1c3Npb24gb2YgcmF0aW9uYWxlIGluDQo+IGh0dHBzOi8vZ2l0aHViLmNv
bS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvNTAuIEFzIEhhbm5lcyB3cm90ZSBpbiB0aGUg
aXNzdWU6DQpbLi4uXQ0KDQpSaWdodCwgSSBkaWRuJ3QgcmFpc2UgYW4gb2JqZWN0aW9uIChiZWNh
dXNlIG9mIHRoZSByZWFsaXR5IGNpdGVkIGJ5IEhhbm5lcyBhbmQgT0NGKSwNCkkganVzdCBzdWdn
ZXN0ZWQgYW4gYXBwbGljYWJpbGl0eSBwYXJhZ3JhcGggZXhwbGFpbmluZyB0aGUgcmVsYXRpb25z
aGlwIGFuZCB0cmFkZW9mZnMuDQoNCkRhdmUNCg==


From nobody Mon May 29 05:31:29 2017
Return-Path: 
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3264A129408; Mon, 29 May 2017 05:31:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool 
To: 
Cc: jaime.jimenez@ericsson.com, core-chairs@ietf.org, core@ietf.org, aamelnikov@fastmail.fm
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149606108811.25116.909901514290582180.idtracker@ietfa.amsl.com>
Date: Mon, 29 May 2017 05:31:28 -0700
Archived-At: 
Subject: [core] core - New Meeting Session Request for IETF 99
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 May 2017 12:31:28 -0000

A new meeting session request has just been submitted by Jaime Jimenez, a Chair of the core working group.


---------------------------------------------------------
Working Group Name: Constrained RESTful Environments
Area Name: Applications and Real-Time Area
Session Requester: Jaime Jimenez

Number of Sessions: 2
Length of Session(s):  2 Hours, 2 Hours
Number of Attendees: 60
Conflicts to Avoid: 
 First Priority: cbor httpbis artarea t2trg ace lpwan 6lo roll teep
 Second Priority: dnssd saag irtfopen 6tisch netconf netmod sacm
 Third Priority: lwig detnet quic v6ops opsarea cfrg icnrg


People who must be present:
  Carsten Bormann
  Alexey Melnikov
  Jaime Jimenez

Resources Requested:

Special Requests:
  Please also avoid any IoT related BOFs that might come up.
*Preferred* pairing: Tue/Thu or other space between; Friday is also no problem.
---------------------------------------------------------


From nobody Tue May 30 13:04:44 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16DA129436 for ; Tue, 30 May 2017 13:04:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 MyVSwzbxoaB2 for ; Tue, 30 May 2017 13:04:41 -0700 (PDT)
Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72D0124B0A for ; Tue, 30 May 2017 13:04:41 -0700 (PDT)
Received: from mfilter12-d.gandi.net (mfilter12-d.gandi.net [217.70.178.129]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 938A3FB8C1; Tue, 30 May 2017 22:04:40 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter12-d.gandi.net
Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by mfilter12-d.gandi.net (mfilter12-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ynHHsMzGjNU2; Tue, 30 May 2017 22:04:38 +0200 (CEST)
X-Originating-IP: 109.8.208.86
Received: from [192.168.0.11] (86.208.8.109.rev.sfr.net [109.8.208.86]) (Authenticated sender: alex@ackl.io) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 4D769FB877; Tue, 30 May 2017 22:04:37 +0200 (CEST)
From: Alexander Pelov 
Content-Type: multipart/alternative; boundary="Apple-Mail=_D6EC8842-3F57-46B3-8207-80903A57733D"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: 
Date: Tue, 30 May 2017 22:04:38 +0200
To: Core 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: [core] CoAP compression is now ready to review
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 May 2017 20:04:44 -0000

--Apple-Mail=_D6EC8842-3F57-46B3-8207-80903A57733D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Dear CORE,

The Static Context Header Compression (SCHC) for CoAP, a WG item at the =
LPWAN WG, is now ready to receive your reviews. The draft is available =
here: =
https://tools.ietf.org/html/draft-ietf-lpwan-coap-static-context-hc-01 =


We have done some great progress on the whole SCHC framework (the =
founding document is on IP/UDP) and we have seen that the CoAP SCHC is =
pretty stable compared to these changes. There are people that are =
starting to implement.. so things are moving in the right direction.

Now is the time to look at the draft and provide your feedback - =
especially if you spot any potential compatibility issues or =
possibilities for improvement. Things can (still) be modified following =
your input.

Also, we will soon start to ask more touchy subjects, such as adjusting =
timer behavior, which *COULD* adapt RFC 7252 to LPWAN characteristics.=20=


The next Interim meeting will be in a little bit more than a week (June =
7th, 7-8am US Pacific, 4pm CEST) and we=E2=80=99ll continue our =
discussions on the topic.=20

Best,
The chairs of LPWAN WG


--Apple-Mail=_D6EC8842-3F57-46B3-8207-80903A57733D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Dear CORE,

The Static Context =
Header Compression (SCHC) for CoAP, a WG item at the LPWAN WG, is now =
ready to receive your reviews. The draft is available here: https://tools.ietf.org/html/draft-ietf-lpwan-coap-static-contex=
t-hc-01

We have done some great =
progress on the whole SCHC framework (the founding document is on =
IP/UDP) and we have seen that the CoAP SCHC is pretty stable compared to =
these changes. There are people that are starting to implement.. so =
things are moving in the right direction.

Now=
 is the time to look at the draft and provide your feedback - especially =
if you spot any potential compatibility issues or possibilities for =
improvement. Things can (still) be modified following your input.

Also, we will soon start to ask more touchy =
subjects, such as adjusting timer behavior, which *COULD* adapt RFC 7252 =
to LPWAN characteristics. 

The next Interim meeting will be in a little bit more than a =
week (June 7th, 7-8am US Pacific, 4pm CEST) and we=E2=80=99ll continue our =
discussions on the topic. 

Best,
The chairs of LPWAN WG

=

--Apple-Mail=_D6EC8842-3F57-46B3-8207-80903A57733D--


From nobody Wed May 31 10:05:07 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B9F126B6D; Wed, 31 May 2017 10:05:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level: 
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  RCVD_IN_DNSWL_LOW=-0.7] 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 3Zzdg5YnDgD2; Wed, 31 May 2017 10:05:03 -0700 (PDT)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6EA4127241; Wed, 31 May 2017 10:05:02 -0700 (PDT)
Received: from [IPv6:2001:660:7301:3728:f822:284f:bdb5:9996] (unknown [IPv6:2001:660:7301:3728:f822:284f:bdb5:9996]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id CDA6BA80D7; Wed, 31 May 2017 19:05:00 +0200 (CEST)
From: Alexander Pelov 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <58E6D5AA-1F9D-4455-9D64-C59CCFF5E7B3@ackl.io>
Date: Wed, 31 May 2017 19:04:59 +0200
Cc: Core 
To: lp-wan 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: [core] Agenda for LPWAN interim meeting next Wednesday, June 7th
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 17:05:06 -0000

Dear all,

You=E2=80=99ll find the updated agenda at the following address: =
https://datatracker.ietf.org/doc/agenda-interim-2017-lpwan-04-lpwan-01/

We=E2=80=99re nearing the finalization of the LPWAN Overview and the =
IP/UDP SCHC document.

The CoAP SCHC document is also on track to be completed in the following =
month. (thus CCing CORE)

Best,
The Chairs of LPWAN=20


From nobody Wed May 31 16:33:16 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDF7129471; Wed, 31 May 2017 16:33:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level: 
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 aQiforp7MfmW; Wed, 31 May 2017 16:33:13 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0126.outbound.protection.outlook.com [104.47.38.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFFA2129468; Wed, 31 May 2017 16:33:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TNjpHudbsVOsbUbLTZfuMwVFLhSFAYdNS6GePAbfkyA=; b=F7JUiGz99ST29oKXdw5Mq+wPHotzwyx+MPiVk79pdTZcdV1loBtoYhdw2LeX3vu4ERqsEq4eK3mxAv7YfpvEo3BNmt1532mxBIrh+5axSCZJOC+4puQxWm8dbmWV6BZYj2OzNJRWad9KZwTvT5krE3+QDiTpAS8UlQXx5LtEkVU=
Received: from BY2PR21MB0084.namprd21.prod.outlook.com (10.162.78.141) by BY2PR21MB0004.namprd21.prod.outlook.com (10.162.77.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.1; Wed, 31 May 2017 23:33:07 +0000
Received: from BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) by BY2PR21MB0084.namprd21.prod.outlook.com ([10.162.78.141]) with mapi id 15.01.1157.003; Wed, 31 May 2017 23:33:06 +0000
From: Brian Raymor 
To: Dave Thaler , Hannes Tschofenig , Carsten Bormann , Eric Rescorla 
CC: "core-chairs@ietf.org" , The IESG , "core@ietf.org" , "draft-ietf-core-coap-tcp-tls@ietf.org" 
Thread-Topic: [core] Eric Rescorla's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
Thread-Index: AQHSyVSAMpIwzIhBiUGz2Gs5B08R+qHtXEWAgBVTRFCABEhYgIAIPGHQ
Date: Wed, 31 May 2017 23:33:05 +0000
Message-ID: 
References: <149411155754.23175.15150224037348429928.idtracker@ietfa.amsl.com>  <28837957-421a-eeff-8304-cfafb80ca234@gmx.net>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: microsoft.com; dkim=none (message not signed) header.d=none;microsoft.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [71.231.205.101]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR21MB0004; 7:LYJ5t2U9IQGgjII2OKjXlF8BMEAWiRL/90WwIvoOut1BTtJ7Qe6jh+AXPNP5p64zTtIjNm0Tb5QPIuZnccEBN7UlPbIvRvdkP9VlGCPs2TelGH1Dkao3mT1YnmtshGVjqSO1UWDZi1FEt9igr5O4PbCgGwFnjM7XONkY1eendUL7wckWp5vLTa4jGkvKVXx7qJDZWbw5h1dOr5r1fALgW+OqWztoOPOSvXrGqgWm+i7EhTkY9bGsAOIeckdmoYYZd+X4sIs/mc/qdNhIO+bCXByLwwkDSexNPFUdTDPvprSqSq9SmpkZPb04W8cOD31NWm7Z32lTB/M5J3lVqu73HNkYbCOEYYLA4hgoWPFKXqU=
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39850400002)(39860400002)(39450400003)(39840400002)(13464003)(24454002)(377454003)(966005)(53936002)(7696004)(2950100002)(38730400002)(6306002)(9686003)(6246003)(99286003)(2900100001)(7736002)(86362001)(54906002)(55016002)(189998001)(6116002)(3846002)(93886004)(122556002)(229853002)(2561002)(230783001)(77096006)(478600001)(6436002)(72206003)(6506006)(102836003)(50986999)(54356999)(2421001)(2906002)(33656002)(10290500003)(3280700002)(305945005)(14454004)(76176999)(4326008)(66066001)(3660700001)(25786009)(53546009)(5660300001)(10090500001)(74316002)(5005710100001)(81166006)(8676002)(8936002)(8990500004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR21MB0004; H:BY2PR21MB0084.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-ms-traffictypediagnostic: BY2PR21MB0004:
x-ms-office365-filtering-correlation-id: 8bb49235-5d9c-487c-59ca-08d4a87d6391
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);  SRVR:BY2PR21MB0004; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(166708455590820)(248736688235697)(100405760836317); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700073)(100105000095)(100000701073)(100105300095)(100000702073)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703073)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123560025)(6072148)(100000704073)(100105200095)(100000705073)(100105500095); SRVR:BY2PR21MB0004; BCL:0; PCL:0; RULEID:(100000800073)(100110000095)(100000801073)(100110300095)(100000802073)(100110100095)(100000803073)(100110400095)(100000804073)(100110200095)(100000805073)(100110500095); SRVR:BY2PR21MB0004; 
x-forefront-prvs: 0324C2C0E2
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2017 23:33:05.8587 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR21MB0004
Archived-At: 
Subject: Re: [core] Eric Rescorla's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 23:33:16 -0000

DQpFa3IsDQoNCldpdGggcmVnYXJkIHRvIHRoZSBvcmlnaW5hbCBESVNDVVNTIC0gIkFmdGVyIHJl
YWRpbmcgTWFyayBOb3R0aW5naGFtJ3MgcmV2aWV3LCBJJ20gcGVyc3VhZGVkIHdlIHNob3VsZCBh
dCBsZWFzdCBkaXNjdXNzIHRoZSByZWxhdGlvbnNoaXAgb2YgdGhpcyB3b3JrIHRvIHRoZSBwYXJh
bGxlbCB3b3JrIGluIEhUVFAiIC0gYXJlIHRoZXJlIGZ1cnRoZXIgcXVlc3Rpb25zIHRoYXQgbmVl
ZCB0byBiZSBhZGRyZXNzZWQgb24gdGhpcyB0aHJlYWQ/ICANCg0KVGhhbmtzLA0KLi4uQnJpYW4N
Cg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEYXZlIFRoYWxlciANClNl
bnQ6IEZyaWRheSwgTWF5IDI2LCAyMDE3IDEwOjI3IEFNDQpUbzogQnJpYW4gUmF5bW9yIDxCcmlh
bi5SYXltb3JAbWljcm9zb2Z0LmNvbT47IEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9m
ZW5pZ0BnbXgubmV0PjsgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+OyBFcmljIFJlc2Nv
cmxhIDxla3JAcnRmbS5jb20+DQpDYzogY29yZS1jaGFpcnNAaWV0Zi5vcmc7IFRoZSBJRVNHIDxp
ZXNnQGlldGYub3JnPjsgY29yZUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRs
c0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtjb3JlXSBFcmljIFJlc2NvcmxhJ3MgRGlzY3VzcyBv
biBkcmFmdC1pZXRmLWNvcmUtY29hcC10Y3AtdGxzLTA4OiAod2l0aCBESVNDVVNTIGFuZCBDT01N
RU5UKQ0KDQpCcmlhbiBSYXltb3Igd3JvdGU6DQo+IFNhbXN1bmcgdG9vLiBBbmQgcGVyaGFwcyBv
bmUgb2Ygb3VyIE9DRitJRVRGIHBhcnRpY2lwYW50cyBjb3VsZCBzcGVhayANCj4gdG8gdGhlIGN1
cnJlbnQgT0NGIGFuZC9vciBJb1Rpdml0eSBzdGF0dXMuDQoNCkkgYmVsaWV2ZSBPQ0YganVzdCBz
ZW50IGEgbGlhaXNvbiBzdGF0ZW1lbnQgb24gdGhpcyB0b3BpYywgYmFzZWQgb24gT0NGIGNvbnNl
bnN1cyBhdCBhIG1lZXRpbmcgZWFybGllciB0aGlzIHdlZWssIHdoaWNoIHNob3VsZCBhbnN3ZXIg
dGhhdCBxdWVzdGlvbiAoaW4gc2hvcnQ6IGl0J3MgaW1wbGVtZW50ZWQgaW4gaW90aXZpdHksIG5v
cm1hdGl2ZWx5IHJlZmVyZW5jZWQgaW4gT0NGIHNwZWNzIHRoYXQgYXJlIGluIHRoZSBwcm9jZXNz
IG9mIGJlaW5nIHB1Ymxpc2hlZC4uLiBzb3J0IG9mIGxpa2Ugc2l0dGluZyBpbiB0aGUgUkZDIGVk
aXRvcnMgcXVldWUsIGFuZCBleHBlY3RlZCB0byBiZSBpbiBsb3RzIG9mIHByb2R1Y3RzIHNoaXBw
aW5nICJzb29uIikuDQoNCk15IHVuZGVyc3RhbmRpbmcgKGl0IHdhcyBiZWZvcmUgbXkgdGltZSkg
aXMgdGhhdCB0aGUgY2hvaWNlIG9mIHVzaW5nIENPQVAgKG92ZXIgVURQKSB3YXMgbWFkZSBsb25n
IGJlZm9yZSBIVFRQLzIgd2FzIGEgdGhpbmcgYW5kIHNvIHVzaW5nIENPQVAgb3ZlciBvdGhlciB1
bmRlcmx5aW5nIGxheWVycyB3YXMgYSBuYXR1cmFsIGV4dGVuc2lvbi4gICBPbGRlciBPSUMgc3Bl
Y3MgZGlkIGhhdmUgYSBwYXJ0aWFsIHNwZWNpZmljYXRpb24gb2YgT0NGIG92ZXIgSFRUUChTKSwg
YnV0IGFzIGl0IHdhcyBuZXZlciBmdWxseSBmbGVzaGVkIG91dCBpdCB3YXMgcmVtb3ZlZCBmcm9t
IGxhdGVyIHNwZWNzIGFuZCBjdXJyZW50IElvdGl2aXR5IGNvZGUgaW1wbGVtZW50aW5nIE9DRiBw
cm90b2NvbHMganVzdCB1c2VzIGNvYXAuDQoNCj4gRW5jb3VyYWdlZCBieSBEYXZlIFRoYWxlciwg
dGhlcmUgd2FzIGEgY2FuZGlkIGRpc2N1c3Npb24gb2YgcmF0aW9uYWxlIA0KPiBpbiBodHRwczov
L2dpdGh1Yi5jb20vY29yZS13Zy9jb2FwLXRjcC10bHMvaXNzdWVzLzUwLiBBcyBIYW5uZXMgd3Jv
dGUgaW4gdGhlIGlzc3VlOg0KWy4uLl0NCg0KUmlnaHQsIEkgZGlkbid0IHJhaXNlIGFuIG9iamVj
dGlvbiAoYmVjYXVzZSBvZiB0aGUgcmVhbGl0eSBjaXRlZCBieSBIYW5uZXMgYW5kIE9DRiksIEkg
anVzdCBzdWdnZXN0ZWQgYW4gYXBwbGljYWJpbGl0eSBwYXJhZ3JhcGggZXhwbGFpbmluZyB0aGUg
cmVsYXRpb25zaGlwIGFuZCB0cmFkZW9mZnMuDQoNCkRhdmUNCg==


From nobody Wed May 31 18:54:34 2017
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA28129B10 for ; Wed, 31 May 2017 18:54:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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 S7LkWjmHybE7 for ; Wed, 31 May 2017 18:54:31 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 6FF77129B07 for ; Wed, 31 May 2017 18:54:31 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id a136so3977131lfa.0 for ; Wed, 31 May 2017 18:54:31 -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:content-transfer-encoding; bh=qi7/r0cRRfaCZxW8Ii7nS5GAx4ty5W8QwyEJoT8AkIA=; b=YTohsCqpYauSG9JUqjwOgHGsIOPtg0Wb+kdgsJ1P2e/Aefoh+8k+nKkFJhJiMq/8/G 0/lt52MwXnUwcxcLpvhSi022k2cEU9qqWCz7QbGSBhl2X/w3FgR5aGZM6Y9vtZFKKAAB ehml6uEKyCuZkHDI5Ns09YRWwlTPduhyXLn+rFb4rMoF/uvY50DOa0bTL0g2U7JoqfwK lqCaNgyfKMx/ZM06iYO/vO8i8zgQ7vWsFghuejF43OEyWnaVDou9W+BQdugW6ceBREAl GsAvqBcLIoHBWGbVTjPXGZ7/xpaHiJuWnHCiSXvI2iQ/wVqn0atyjzjwYfWXuxg75SJD qQCA==
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:content-transfer-encoding; bh=qi7/r0cRRfaCZxW8Ii7nS5GAx4ty5W8QwyEJoT8AkIA=; b=BgQq3l1/d78NXyJu4/MxJxMKdyQE0lcy3aL10zpwIE59ACqwwWgPt5SCiprYEKQseK XZmSt1QD/KIRWH+cWCkE2/yOHXyN2gbLbfB9V3jvYjtRQmbjbWY7z/QtKg74IKWifNrf rOJbwKyVIE5yXYxylWOElkjHkz8JTpc2Q17nmBn1WZ1vKL6PcfOcRVTr4W6W/pXdVo5s z72SziEXj4D4uw3+fSueCAo0kfwffGd2UY+wSS96ZlPlFPv0qwm7re2p8wVmxGgvQs6P 9CImUeF4bF/pF/PsgjR0IfQrhTVEC+Q3mum/mN3vWohvoc6WzusIdDGWHv/hgTnl83+t J2rQ==
X-Gm-Message-State: AODbwcCXfYGduvoJNwWGWF1pOigiRqy1LHYw3Fb0C2GeSS4QaodrPWgl Oaty4toVyuIEWJXNjA0w3S3mCxhfjJ63
X-Received: by 10.46.7.10 with SMTP id 10mr9083833ljh.113.1496282069712; Wed, 31 May 2017 18:54:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.8.66 with HTTP; Wed, 31 May 2017 18:54:28 -0700 (PDT)
In-Reply-To: 
References: 
From: Martin Thomson 
Date: Thu, 1 Jun 2017 11:54:28 +1000
Message-ID: 
To: Alexander Pelov 
Cc: Core 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [core] CoAP compression is now ready to review
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Jun 2017 01:54:33 -0000

This document doesn't include a Security Considerations section.

I'd expect something on the interaction between compression and
traffic analysis.  Though I see that there might be an assumption that
encryption is not in use.

On 31 May 2017 at 06:04, Alexander Pelov  wrote:
> Dear CORE,
>
> The Static Context Header Compression (SCHC) for CoAP, a WG item at the
> LPWAN WG, is now ready to receive your reviews. The draft is available he=
re:
> https://tools.ietf.org/html/draft-ietf-lpwan-coap-static-context-hc-01
>
> We have done some great progress on the whole SCHC framework (the foundin=
g
> document is on IP/UDP) and we have seen that the CoAP SCHC is pretty stab=
le
> compared to these changes. There are people that are starting to implemen=
t..
> so things are moving in the right direction.
>
> Now is the time to look at the draft and provide your feedback - especial=
ly
> if you spot any potential compatibility issues or possibilities for
> improvement. Things can (still) be modified following your input.
>
> Also, we will soon start to ask more touchy subjects, such as adjusting
> timer behavior, which *COULD* adapt RFC 7252 to LPWAN characteristics.
>
> The next Interim meeting will be in a little bit more than a week (June 7=
th,
> 7-8am US Pacific, 4pm CEST) and we=E2=80=99ll continue our discussions on=
 the topic.
>
> Best,
> The chairs of LPWAN WG
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>