From nobody Sun Oct 2 04:23:27 2016 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 C216F12B037; Sun, 2 Oct 2016 04:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 kY-KGBlzRDHi; Sun, 2 Oct 2016 04:23:24 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 3B92D12B015; Sun, 2 Oct 2016 04:23:24 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id E3ED3B3112F66; Sun, 2 Oct 2016 11:23:19 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u92BNLuC009967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 2 Oct 2016 11:23:21 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u92BNKlt011098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 2 Oct 2016 13:23:21 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.21]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Sun, 2 Oct 2016 13:23:20 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Alexey Melnikov , "Fossati, Thomas (Nokia - GB)" Thread-Topic: [core] Spencer Dawkins' Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and COMMENT) Thread-Index: AQHSGQ6m8SAo/UHADkCUO8OCqQpJJ6CRFfwAgAEcSQCAAsmVAA== Date: Sun, 2 Oct 2016 11:23:19 +0000 Message-ID: References: <147501537986.11800.1149988617235818479.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.8.160830 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <9A3150EAC0EB7449979D308D6394E4E3@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-core-http-mapping@ietf.org" , "core-chairs@ietf.org" , Spencer Dawkins , "core@ietf.org" , The IESG Subject: Re: [core] Spencer Dawkins' Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 02 Oct 2016 11:23:26 -0000 Hi Alexey, On 30/09/2016 18:49, "Alexey Melnikov" wrote: >On 30 Sep 2016, at 02:51, Fossati, Thomas (Nokia - GB) > wrote: >>>Can the HTTP client tell whether the result used coaps://? >>=20 >> No, if it's using the simple form and there is no OOB agreement. So, I >> guess the question is: do you think it'd be better to spell this out >> explicitly? If so, we could say that a Target CoAP URI without the >>scheme >> is not allowed unless there is an OOB agreement between client and HC >> proxy (client MUST NOT emit / proxy MUST return 4xx on receipt). Or do >> you have something different in mind? > >An alternative is to always require coaps in this case. Might not work >for your type of document though. Yep. But, in this case, I think it's better to fail early and hard (with a 4xx on the HTTP side of the proxy), because we can safely assume that the Target URI is syntactically incorrect. This way we also avoid injecting a (possibly useless) request in to the constrained network -- and returning a slightly confusing 504 in case the endpoint doesn't reply back if it's not listening for coaps requests. Cheers, t From nobody Sun Oct 2 23:06:03 2016 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 B8E1712B13A; Sun, 2 Oct 2016 23:06:01 -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 (1024-bit key) header.d=fastmail.fm header.b=gPezzF+Q; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=ea3KO/eQ 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 r4ksmh_J8s8z; Sun, 2 Oct 2016 23:06:00 -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 5354F12B01E; Sun, 2 Oct 2016 23:06:00 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5C3EB2080E; Mon, 3 Oct 2016 02:05:59 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Mon, 03 Oct 2016 02:05:59 -0400 DKIM-Signature: v=1; a=rsa-sha1; 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-sasl-enc :x-sasl-enc; s=mesmtp; bh=Hn9BeiVO34hjcISQtyVKTbKYQ48=; b=gPezzF +QI+3460SkGquZF3SirBvDowziN5mhhy9/rMy46ENLtTqOaRt5AFxxbgJ4GvViCY uQriz0cNvt2ryd7SjpyoblD+FBNLSiww+NQF/N1ujRSDLZUEp+CamXK6dzS1B6Mt 9mw7ttD0VUFcpEMC20rKHxe3br2Pbq70NAdes= DKIM-Signature: v=1; a=rsa-sha1; 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-sasl-enc:x-sasl-enc; s=smtpout; bh=Hn9BeiVO34hjcIS QtyVKTbKYQ48=; b=ea3KO/eQBW/vklIDV2LSrZT0PaUuPmTpgwILhDNYey2m+V2 wM2HPqiwzQBHa078fSNgk/nA5Nr8QVHC/uwJzkd0Ot4N5D/7hcqmKmwIRCYW2EVd sPooDvyr7FtLp0X5NpbkU5NF6QwbAT2NdzlaY0I1UMmtCNQIygE6Gq7YrByo= X-Sasl-enc: av1B1OZ7zaopAt2zej9TrKCn8KRMSVX6e0yqWWiRjrpf 1475474758 Received: from [192.168.145.20] (foin-mou-peer.customers.otenet.gr [212.205.242.54]) by mail.messagingengine.com (Postfix) with ESMTPA id EDCEDF29CF; Mon, 3 Oct 2016 02:05:58 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (13G36) In-Reply-To: Date: Mon, 3 Oct 2016 09:19:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147501537986.11800.1149988617235818479.idtracker@ietfa.amsl.com> To: "Fossati, Thomas (Nokia - GB)" Archived-At: Cc: "draft-ietf-core-http-mapping@ietf.org" , "core-chairs@ietf.org" , Spencer Dawkins , "core@ietf.org" , The IESG Subject: Re: [core] Spencer Dawkins' Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 03 Oct 2016 06:06:02 -0000 Hi Thomas, > On 2 Oct 2016, at 14:23, Fossati, Thomas (Nokia - GB) wrote: >=20 > Hi Alexey, >=20 >> On 30/09/2016 18:49, "Alexey Melnikov" wrote: >> On 30 Sep 2016, at 02:51, Fossati, Thomas (Nokia - GB) >> wrote: >>>> Can the HTTP client tell whether the result used coaps://? >>>=20 >>> No, if it's using the simple form and there is no OOB agreement. So, I >>> guess the question is: do you think it'd be better to spell this out >>> explicitly? If so, we could say that a Target CoAP URI without the >>> scheme >>> is not allowed unless there is an OOB agreement between client and HC >>> proxy (client MUST NOT emit / proxy MUST return 4xx on receipt). Or do >>> you have something different in mind? >>=20 >> An alternative is to always require coaps in this case. Might not work >> for your type of document though. >=20 > Yep. But, in this case, I think it's better to fail early and hard (with > a 4xx on the HTTP side of the proxy), because we can safely assume that > the Target URI is syntactically incorrect. This way we also avoid > injecting a (possibly useless) request in to the constrained network -- > and returning a slightly confusing 504 in case the endpoint doesn't reply > back if it's not listening for coaps requests. Fair enough. From nobody Mon Oct 3 11:04:03 2016 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 8FD0812945A; Mon, 3 Oct 2016 11:03:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147551783458.29696.12686473737762298084.idtracker@ietfa.amsl.com> Date: Mon, 03 Oct 2016 11:03:54 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-http-mapping-15.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 18:03:55 -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 : Guidelines for HTTP-to-CoAP Mapping Implementations Authors : Angelo P. Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk Filename : draft-ietf-core-http-mapping-15.txt Pages : 38 Date : 2016-10-03 Abstract: This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to CoAP (Constrained Application Protocol). This will enable a HTTP client to access resources on a CoAP server through the proxy. This document describes how a HTTP request is mapped to a CoAP request, and then how a CoAP response is mapped back to a HTTP response. This includes guidelines for URI mapping, media type mapping and additional proxy implementation issues. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-http-mapping-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-http-mapping-15 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 Mon Oct 3 11:15:43 2016 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 CBE3612943B; Mon, 3 Oct 2016 11:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 3nvv84CNxsh7; Mon, 3 Oct 2016 11:15:39 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 B2A57126D74; Mon, 3 Oct 2016 11:15:38 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id B652163F91435; Mon, 3 Oct 2016 18:15:31 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u93IFY8B028728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Oct 2016 18:15:35 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u93IFY3D027830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Oct 2016 20:15:34 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.21]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Mon, 3 Oct 2016 20:15:34 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Alexey Melnikov , "Fossati, Thomas (Nokia - GB)" Thread-Topic: [core] Spencer Dawkins' Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and COMMENT) Thread-Index: AQHSGQ6m8SAo/UHADkCUO8OCqQpJJ6CRFfwAgAEcSQCAAsmVAIABLLQAgADYywA= Date: Mon, 3 Oct 2016 18:15:33 +0000 Message-ID: References: <147501537986.11800.1149988617235818479.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.8.160830 x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_D4185C9671F5Ethomasfossatialcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-core-http-mapping@ietf.org" , "core-chairs@ietf.org" , Spencer Dawkins , "core@ietf.org" , The IESG Subject: Re: [core] Spencer Dawkins' Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 03 Oct 2016 18:15:41 -0000 --_000_D4185C9671F5Ethomasfossatialcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, We have just posted -15 which should clear most of the comments and discuss= points. In particular, we addressed: - Kathleen's DISCUSS and COMMENTs; - Stephen's COMMENTs; - Suresh's DISCUSS; and - Spencer's DISCUSS and COMMENTs. The diff is at https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-http-map= ping-14&url2=3Ddraft-ietf-core-http-mapping-15 =97 please check if I forgot= anything. This should leave Stephen's DISCUSS as the only remaining item, which we pl= an to address in the next few days. Thanks very much to everyone involved in the discussion so far. Much appre= ciated. Cheers, t. On 03/10/2016 07:19, "Alexey Melnikov" > wrote: Hi Thomas, On 2 Oct 2016, at 14:23, Fossati, Thomas (Nokia - GB) > wrote: Hi Alexey, On 30/09/2016 18:49, "Alexey Melnikov" > wrote: On 30 Sep 2016, at 02:51, Fossati, Thomas (Nokia - GB) > wrote: Can the HTTP client tell whether the result used coaps://? No, if it's using the simple form and there is no OOB agreement. So, I guess the question is: do you think it'd be better to spell this out explicitly? If so, we could say that a Target CoAP URI without the scheme is not allowed unless there is an OOB agreement between client and HC proxy (client MUST NOT emit / proxy MUST return 4xx on receipt). Or do you have something different in mind? An alternative is to always require coaps in this case. Might not work for your type of document though. Yep. But, in this case, I think it's better to fail early and hard (with a 4xx on the HTTP side of the proxy), because we can safely assume that the Target URI is syntactically incorrect. This way we also avoid injecting a (possibly useless) request in to the constrained network -- and returning a slightly confusing 504 in case the endpoint doesn't reply back if it's not listening for coaps requests. Fair enough. --_000_D4185C9671F5Ethomasfossatialcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <53D2388353D10F448172B9ABECBD61FF@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
Hi,

We have just posted -15 which should clear most of the comments and di= scuss points.

In particular, we addressed:
- Kathleen's DISCUSS and COMMENTs;
- Stephen's COMMENTs;
- Suresh's DISCUSS; and 
- Spencer's DISCUSS and COMMENTs.


This should leave Stephen's DISCUSS as the only remaining item, which = we plan to address in the next few days.

Thanks very much to everyone involved in the discussion so far.  = Much appreciated.

Cheers, t.

On 03/10/= 2016 07:19, "Alexey Melnikov" <aamelnikov@fastmail.fm> wrote:
Hi Thomas,

On 2 Oct 2016, at 14:23, Fossati, Thomas (Nokia - GB) <thomas.fossati@nokia.com> wrote:
Hi Alexey,
On 30/09/2016 18:49, "Alexey Melnikov" <aamelnikov@fastmail.fm> wrote:
On 30 Sep 2016, at 02:51, Fossati, Thomas (Nokia - GB)
Can the HTTP client tell whether the result used coaps://?
No, if it's using the simple form and there is no OOB agreement. =  So, I
guess the question is: do you think it'd be better to spell this out
explicitly?  If so, we could say that a Target CoAP URI with= out the
scheme
is not allowed unless there is an OOB agreement between client and HC<= /div>
proxy (client MUST NOT emit / proxy MUST return 4xx on receipt). =  Or do
you have something different in mind?
An alternative is to always require coaps in this case. Might not work=
for your type of document though.
Yep.  But, in this case, I think it's better to fail early a= nd hard (with
a 4xx on the HTTP side of the proxy), because we can safely assume tha= t
the Target URI is syntactically incorrect.  This way we also= avoid
injecting a (possibly useless) request in to the constrained network -= -
and returning a slightly confusing 504 in case the endpoint doesn't re= ply
back if it's not listening for coaps requests.

Fair enough.
--_000_D4185C9671F5Ethomasfossatialcatellucentcom_-- From nobody Mon Oct 3 20:41:15 2016 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 55B4A1295BC; Mon, 3 Oct 2016 20:41:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147555247434.29720.3386166667856475615.idtracker@ietfa.amsl.com> Date: Mon, 03 Oct 2016 20:41:14 -0700 Archived-At: Cc: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-http-mapping@ietf.org Subject: [core] Spencer Dawkins' Yes on draft-ietf-core-http-mapping-15: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 03:41:14 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-core-http-mapping-15: Yes 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-http-mapping/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my Discuss and comments. For what it's worth, I also like the changes you made to address other feedback, too. From nobody Tue Oct 4 13:54:50 2016 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 82AC71294D2 for ; Tue, 4 Oct 2016 13:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 Rob8kfhqCQAy for ; Tue, 4 Oct 2016 13:54:46 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0109.outbound.protection.outlook.com [104.47.40.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAE211294C4 for ; Tue, 4 Oct 2016 13:54: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=hF3qYIAWTvedsh+8NCUYxqqCezxj8L9XSBaMPhcd5rM=; b=mJ2uGw9Q05IQARmUc9CG8zoYcvBxjinE/C77VVMvM50v/60pKmVhQCB461NoAsRSdlwWoNOKe8TZb6yeT8B78ltCDMhCIi9xLsljeiTWNcwiZgZp/afIg41oht55dSwrg2Yn68nImkNzkd5P9KPAG/5EccAOuy2M3w8XTAkEPdY= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by MWHPR03MB2447.namprd03.prod.outlook.com (10.169.200.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Tue, 4 Oct 2016 20:54:45 +0000 Received: from CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) by CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) with mapi id 15.01.0639.015; Tue, 4 Oct 2016 20:54:45 +0000 From: Brian Raymor To: weigengyu , "core@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt Thread-Index: AQHR/kux0vvo8uYlLUa/o5fnHPLus6BYnTxwgBQ95TCAChwvAIAMJygg Date: Tue, 4 Oct 2016 20:54:44 +0000 Message-ID: References: <147207291891.26600.11584792951825869042.idtracker@ietfa.amsl.com> <114995FB6D604B92854BDA82FEC26123@WeiGengyuPC> In-Reply-To: <114995FB6D604B92854BDA82FEC26123@WeiGengyuPC> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [131.107.160.153] x-ms-office365-filtering-correlation-id: a932c11e-09c8-4a1f-81a4-08d3ec98abda x-microsoft-exchange-diagnostics: 1; MWHPR03MB2447; 7:Y9GGw4Jn2krS8WOpQusoSO3Slq5Ejy734rr8e1NYWwJxQ6e3O0YOGnbnlDL6OsqNqDw6XXwdUImY4lqtyw9RNn1u/LxTsy96KDmnJOcBVkRQNlm5x0wBNoEXpVde8p7u8y0mfPT4bKb/rv2sqe/ieWQr1r9t4H6DDBMWJap8T7zX8TshrBU9a7kwOQ6NnYdLRYUn0W91fp2jB0nJQLkcSsHs/8LK5CF3tRtCpUwiZ8t8fp3DIiYgKoBSSt4vfB1NuWfLRKkuXfbkIaABVTyZGqJSj2r1qRUNGQQ2VPIRX2K/qrQH7NLMwPs12abk0W59Pa0PD3CjE+0UoK5DQS8uRw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR03MB2447; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-o365eop-header: O365_EOP: Allow for Unauthenticated Relay x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:MWHPR03MB2447; BCL:0; PCL:0; RULEID:; SRVR:MWHPR03MB2447; x-forefront-prvs: 00851CA28B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(199003)(377454003)(189002)(97736004)(5001770100001)(81166006)(81156014)(106356001)(9686002)(101416001)(8936002)(8990500004)(11100500001)(99286002)(8676002)(106116001)(189998001)(86362001)(2501003)(86612001)(19580395003)(10290500002)(66066001)(5002640100001)(54356999)(50986999)(76176999)(3280700002)(3660700001)(2906002)(105586002)(230783001)(122556002)(74316002)(68736007)(4326007)(2171001)(10090500001)(5005710100001)(93886004)(3846002)(77096005)(5660300001)(102836003)(305945005)(87936001)(92566002)(7736002)(7696004)(7846002)(586003)(2950100002)(76576001)(33656002)(15975445007)(2900100001)(6116002)(10400500002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR03MB2447; H:CY1PR03MB2380.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) 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: 04 Oct 2016 20:54:44.9998 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR03MB2447 Archived-At: Cc: Hannes Tschofenig , Juan Perez Subject: Re: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 04 Oct 2016 20:54:48 -0000 DQpBcG9sb2dpZXMgZm9yIHRoZSBkZWxheS4gSSd2ZSBiZWVuIHdhaXRpbmcgZm9yIGFkZGl0aW9u YWwgY29tbWVudHMgcHJpb3IgdG8gcmVzcG9uZGluZy4gDQoNClRoZXJlIGlzIHNvbWUgc3VwcG9y dCBmb3IgdGhpcyBmZWF0dXJlIGV4cHJlc3NlZCBieSB3b3JraW5nIGdyb3VwIG1lbWJlcnMgd2l0 aCBlYXJseQ0KQ29BUCtUQ1AgaW1wbGVtZW50YXRpb25zIC0gc2VlIGh0dHBzOi8vZ2l0aHViLmNv bS9jb3JlLXdnL2NvYXAtdGNwLXRscy9pc3N1ZXMvNTgNCg0KT24gTW9uZGF5LCBTZXB0ZW1iZXIg MTIsIDIwMTYgOTo0OCBQTSwgR2VuZ3l1IFdFSSB3cm90ZToNCg0KPiBUaGUgQ29BUCBzZXJ2ZXIg bWF5IGJlIGVmZmVjdGVkIGlmIGNsaWVudCBpbW1lZGlhdGVseSBzZW5kcyBtZXNzYWdlcyBhZnRl ciANCj4gc2VuZGluZyBpdHMgQ1NNIHdpdGhvdXQgd2FpdGluZyBmb3IgdGhlIHNlcnZlciBDU00u DQoNCkFic29sdXRlbHkgdHJ1ZS4gVGhlIHNlcnZlciBtYXkgbmVlZCB0byByZWplY3QvaWdub3Jl IG1lc3NhZ2VzIHRoYXQgYXJlIHRvbyBsYXJnZS4gIFRoZXJlIGlzIG5vDQpyZXF1aXJlbWVudCBm b3IgdGhlIGNsaWVudCB0byBpbW1lZGlhdGVseSBzZW5kIG1lc3NhZ2VzLiBJdCBtYXkgb25seSBi ZSBwcmVmZXJhYmxlIGluIGNhc2VzIHdoZXJlDQp0aGUgY2xpZW50IGFuZCBzZXJ2ZXIgaGF2ZSBh ICJrbm93biIgY29uZmlndXJhdGlvbi4gDQoNCj4gSXMgdGhlIHByb2JhYmlsaXR5IG9mIGJhdHRl cnkgbG9zcyBjYXVzZWQgYnkgaW5jb25zaXN0ZW5jeSBvZiBDU00gYmlnIG9yIHNtYWxsPw0KDQpJ dCBkZXBlbmRzIG9uIHdoZXRoZXIgYSBjb25zdHJhaW5lZCBjbGllbnQgbmVlZHMgdG8gcmUtc2Vu ZCBkYXRhLiANCg0KPiBJcyBpdCBhIHBvdGVudGlhbCBtZWFucyBmb3IgYSBjbGllbnQgdG8gYXR0 YWNrIHRoZSBDb0FQIHNlcnZlciBieSBjb25zdW1pbmcgaXRzIHBvd2VyPw0KDQpEbyB5b3UgaGF2 ZSBhbiBpbXBsZW1lbnRhdGlvbi9kZXBsb3ltZW50IHdpdGggYSBjb25zdHJhaW5lZCBzZXJ2ZXI/ IEFzIEp1YW4gUGVyZXoNCm5vdGVzIGluIGhpcyBjb21tZW50Og0KDQogICAgRnJvbSB0aGUgcGVy c3BlY3RpdmUgb2YgYSBjbG91ZCBhbmQgZ2F0ZXdheSBzb2Z0d2FyZSBwcm92aWRlciwNCiAgICB0 aGUgQ29BUCAodXNpbmcgVENQL1RMUykgc2VydmVyIHdpbGwgdXN1YWxseSBiZSBpbiB0aGUgY2xv dWQgb3INCiAgICBnYXRld2F5IGFuZCB0aGVyZWZvcmUgdXN1YWxseSBub3QgcG93ZXIgY29uc3Ry YWluZWQuIEkgbWF5IGJlDQogICAgbWlzc2luZyBvdGhlciBzY2VuYXJpb3Mgd2hlcmUgYSBiYXR0 ZXJ5IHBvd2VyZWQgZGV2aWNlIGlzIGFjdGluZw0KICAgIGFzIGEgQ29BUC9UQ1Agc2VydmVyLiBE b2VzIGFueW9uZSBoYXZlIHBsYW5zIGZvciBhbnkgb2YgdGhvc2UNCiAgICBzY2VuYXJpb3M/DQoN Cg== From nobody Tue Oct 4 22:33:01 2016 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 C1EE5129501 for ; Tue, 4 Oct 2016 22:32:59 -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 5jY2qC8-3fLR for ; Tue, 4 Oct 2016 22:32:58 -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 1755A1294C7 for ; Tue, 4 Oct 2016 22:32:57 -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 u955WjP7026320; Wed, 5 Oct 2016 07:32:46 +0200 (CEST) Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3spkvK5CKkz1jM6; Wed, 5 Oct 2016 07:32:45 +0200 (CEST) Message-ID: <57F4908E.6040905@tzi.org> Date: Wed, 05 Oct 2016 07:33:02 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Brian Raymor References: <147207291891.26600.11584792951825869042.idtracker@ietfa.amsl.com> <114995FB6D604B92854BDA82FEC26123@WeiGengyuPC> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Hannes Tschofenig , "core@ietf.org" , Juan Perez Subject: Re: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 05 Oct 2016 05:32:59 -0000 > Absolutely true. The server may need to reject/ignore messages that are too large. I don't understand how this could happen. Until it receives an indication for an increased message size capability from the other side, the limitations of Section 4.6 of RFC 7252 continue to apply to messages sent by any one side. (Now, the message receiver might want to go *below* Section 4.6. If that is a use case we want to support, the argument does apply. Is it?) > Do you have an implementation/deployment with a constrained server? As Juan Perez > notes in his comment: > > From the perspective of a cloud and gateway software provider, > the CoAP (using TCP/TLS) server will usually be in the cloud or > gateway and therefore usually not power constrained. I may be > missing other scenarios where a battery powered device is acting > as a CoAP/TCP server. Does anyone have plans for any of those > scenarios? I think we have to be more careful about separating the concept of initiator/listener for the TCP connection from the concept of CoAP client/server; these are not linked. Indeed, the TCP initiator will typically be the constrained device (and thus the CoAP server) in the NAT traversal use case. Grüße, Carsten From nobody Wed Oct 5 13:10:45 2016 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 77115128B37 for ; Wed, 5 Oct 2016 13:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni-luebeck.de 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 kmvGCv1rIDZb for ; Wed, 5 Oct 2016 13:10:40 -0700 (PDT) Received: from ip1.rz.uni-luebeck.de (ip1.rz.uni-luebeck.de [141.83.100.71]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A20129417 for ; Wed, 5 Oct 2016 13:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni-luebeck.de; s=uzl; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=1Dkg705dvw9IA+um8Bp0aWOu32H1U9qRYn+Nx/fx++4=; b=ezpH40QwHG5mjaLVTlLd/ClNFGealCaMcpLOKhFasHKFOHPZBf9aG3sq lhpdb6/cMRDF78tUy2+idvDhZdgeIRynHwtB76yoQxFa0abvPoqU/uDOi mc3cdX+Ev9cnjEnlsXE60n1NVFg/pASFTCzY94Ry7HcLPs/NyhswxB+/g zAH1J95y4HiJx15YC8mUg8RmduFwTqJfTAlltsZUVosXwy+4tbdrQexGP seyghFUz2RbFj4pKHQo4uflotITeNG/tYvi0HNKTJOBf79XDw2xCX7yX5 LX8ZgN1V0y0m8uQkfPt5dYf4E03rtMb7zTBBk01C5qtkyBfPZrUZU9peP g==; IronPort-PHdr: =?us-ascii?q?9a23=3AYC5roBKylYzSHygWhNmcpTZWNBhigK39O0sv0rFi?= =?us-ascii?q?tYgUKfjxwZ3uMQTl6Ol3ixeRBMOAuqgC0LKd6vy6EUU7or+5+EgYd5JNUxJXwe?= =?us-ascii?q?43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6anHS+4HYoFwnlMkIt?= =?us-ascii?q?f6KuS9SU1Jz8jrzos7ToICxwzAKnZr1zKBjk5S7wjeIxxbVYF6Aq1xHSqWFJce?= =?us-ascii?q?kFjUlhJFaUggqurpzopM0roGxsvKcq8NRNeaT3Y6p+SqZXXxo8NGVgw8nqqxTZ?= =?us-ascii?q?BSiL63oaXy1CkR5FAg7IxBDmW9HstCq/svdw0iSRPov6QOZnCnyZ8653RUqw22?= =?us-ascii?q?88PDkj/TSPhw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ALBwD2XfVX/2REU41dHAEBBAEBCgEBG?= =?us-ascii?q?AEFAQsBgxIBAQEBAXUqUo0yln+UKYIJGwuCNINGAoItFAEBAQEBAQEBAQEBXSe?= =?us-ascii?q?CMhiCGAEBBAEBAWsbC0YCJTATBgIBAYhOCrwQDBcKBYg5CIJQhDEthUcFmXqDQ?= =?us-ascii?q?YF2cIs+hGaDEASGC4cMhWeDfh42PwUHgmscgVRwAYg1AQEB?= X-IPAS-Result: =?us-ascii?q?A2ALBwD2XfVX/2REU41dHAEBBAEBCgEBGAEFAQsBgxIBAQE?= =?us-ascii?q?BAXUqUo0yln+UKYIJGwuCNINGAoItFAEBAQEBAQEBAQEBXSeCMhiCGAEBBAEBA?= =?us-ascii?q?WsbC0YCJTATBgIBAYhOCrwQDBcKBYg5CIJQhDEthUcFmXqDQYF2cIs+hGaDEAS?= =?us-ascii?q?GC4cMhWeDfh42PwUHgmscgVRwAYg1AQEB?= Received: from itm01.itm.uni-luebeck.de (HELO mail.itm.uni-luebeck.de) ([141.83.68.100]) by ip1.rz.uni-luebeck.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Oct 2016 22:10:04 +0200 Received: from [192.168.2.106] (p5DE985FA.dip0.t-ipconnect.de [93.233.133.250]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.itm.uni-luebeck.de (Postfix) with ESMTPSA id 0D71A83F8E4 for ; Wed, 5 Oct 2016 22:10:04 +0200 (CEST) To: core@ietf.org References: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> From: Oliver Kleine Message-ID: <3febad96-3793-69a6-b78f-1994c0f9708d@itm.uni-luebeck.de> Date: Wed, 5 Oct 2016 22:10:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000309070201050606080707" Archived-At: Subject: Re: [core] Implications of IP address / port changes for CoAP & Co X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 05 Oct 2016 20:10:43 -0000 This is a cryptographically signed message in MIME format. --------------ms000309070201050606080707 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Hannes, if I got you right this is exactly the problem I was talking about at IETF 91 almost two years ago. Back then, I briefly presented an extension draft with a rather simple approach to solve that issue. If you don't mind, please have a look at [1]. Are you talking about the same thing? Best regards, Oliver [1] https://tools.ietf.org/html/draft-kleine-core-coap-endpoint-id-01 Am 31.08.2016 um 12:36 schrieb Hannes Tschofenig: > Hi all, >=20 > in the OMA device management group we have been discussing the > implications of IP address and/or port number changes of devices > (particularly with devices that sleep for an extended period of time). >=20 > The challenge from a protocol point of view is to use an identifier tha= t > does not depend on the IP address and port. Of course, when a IP packet= > has to be sent to a specific node then IP address and port information > has to be used from somewhere but my expectation is that at least the > protocol machinery shouldn't break when an IP address changes (or there= > should be a story for how to recover). >=20 > In CoAP the 'endpoint' appears to be an important identifier. In an > attempt to define what an endpoint is the CoAP specification is a bit > confusing: >=20 > Section 1.2 says: >=20 > " > Endpoint > An entity participating in the CoAP protocol. Colloquially, an > endpoint lives on a "Node", although "Host" would be more > consistent with Internet standards usage, and is further > identified by transport-layer multiplexing information that can > include a UDP port number and a security association > (Section 4.1). > " =20 >=20 > Section 4.1 of RFC 7252 says: > =20 > " > A CoAP endpoint is the source or destination of a CoAP message. The= > specific definition of an endpoint depends on the transport being > used for CoAP. For the transports defined in this specification, th= e > endpoint is identified depending on the security mode used (see > Section 9): With no security, the endpoint is solely identified by a= n > IP address and a UDP port number. With other security modes, the > endpoint is identified as defined by the security mode. > " >=20 > The two definitions do not appear to be in sync, particularly when usin= g > DTLS to secure CoAP since the DTLS record layer adds nothing with > respect to additional multiplexing. I also did not find text that > describes what the different endpoint definition is when DTLS is used. >=20 > In any case, when DTLS is used an IP address / port change at the clien= t > will prevent the CoAP server from finding the right security context an= d > a new (hopefully abbreviated) handshake has to be run. >=20 > Luckily the implications of an IP address/port change are quite minimal= > for CoAP itself since the only impact (as far as I can tell) is with > regards to the use of request/response exchange, as described in Sectio= n > 5.3.2 "Request/Response Matching Rules". The likelihood that a client > changes IP address in the middle of a request/response interaction are > IMHO minimal. >=20 > The story is more interesting when we look at extensions to CoAP, like > CoAP Observe. Section 4.1 of https://tools.ietf.org/html/rfc7641 says: >=20 > " > The entry in the list of observers is keyed by the client endpoint > and the token specified by the client in the request. If an entry > with a matching endpoint/token pair is already present in the list > (which, for example, happens when the client wishes to reinforce its= > interest in a resource), the server MUST NOT add a new entry but MUS= T > replace or update the existing one. > " >=20 > With Observe a token is used for demultiplexing (in addition to the > endpoint info). I assume that the spec uses the same definition of > endpoint as in CoAP. >=20 > While the spec does not say what is actually being updated or replaced > one can assume that a client sending a request with a new IP address an= d > port (which corresponds to the endpoint definition in CoAP) gets at > least that information updated. >=20 > The spec is IMHO unclear what should happen in case of an IP > address/port change. I suspect that an implementation would send a new > register message and the server would update state. Of course, when the= > IP address / port of the client is not in sync with what is being store= d > at the server then the notifications sent by the server will not reach > the client. >=20 > The story for RD appears to be different again. First, there appears to= > be a different definition of endpoint being used (which I prefer more).= > For multiplexing it does not use IP address & port information. Of > course, RD will still have to maintain this information but at least on= e > can be sure that packets are not dropped after the IP address and/or > port at the client change. >=20 > Section 11.1 of draft-ietf-core-resource-directory-08 says: >=20 > " > An Endpoint is determined to be unique by an RD by the Endpoint > identifier parameter included during Registration, and any associate= d > TLS or DTLS security bindings. An Endpoint MUST NOT be identified b= y > its protocol, port or IP address as these may change over the > lifetime of an Endpoint. > " >=20 > It appears that the way how state is indexed is different throughout th= e > specifications developed in the CORE working group and I am curious > whether someone else has been looking at the implications of IP address= > and/or port changes on the protocol operation. I would certainly > appreciate your thoughts on this topic. >=20 > Ciao > Hannes >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Dr.-Ing. Oliver Kleine UNIVERSIT=C4T ZU L=DCBECK INSTITUT F=DCR TELEMATIK Ratzeburger Allee 160 23538 L=FCbeck Tel +49 451 3101-6406 (NEU) Fax +49 451 3101-6404 (NEU) kleine@itm.uni-luebeck.de https://www.itm.uni-luebeck.de/people/kleine --------------ms000309070201050606080707 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC D+cwggTVMIIDvaADAgECAghQTsb1PRG0ZDANBgkqhkiG9w0BAQsFADBxMQswCQYDVQQGEwJE RTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMTQw NzIyMTIwODI2WhcNMTkwNzA5MjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZO LVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xv YmFsIC0gRzAxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTD llA1PWLpbkztlNcAW5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1 OXstkEXQ7aAAeny/Sg4bAMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8B r3QPwQmi9mvOvdPNFDBP9eXjpMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9 bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSa cXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7wxLyvQIDAQABo4IBhjCCAYIwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAWgBQxw3kbuvVT 1xfgiXotF2wKsyudMzASBgNVHRMBAf8ECDAGAQH/AgECMGIGA1UdIARbMFkwEQYPKwYBBAGB rSGCLAEBBAICMBEGDysGAQQBga0hgiwBAQQDADARBg8rBgEEAYGtIYIsAQEEAwEwDwYNKwYB BAGBrSGCLAEBBDANBgsrBgEEAYGtIYIsHjA+BgNVHR8ENzA1MDOgMaAvhi1odHRwOi8vcGtp MDMzNi50ZWxlc2VjLmRlL3JsL0RUX1JPT1RfQ0FfMi5jcmwweAYIKwYBBQUHAQEEbDBqMCwG CCsGAQUFBzABhiBodHRwOi8vb2NzcDAzMzYudGVsZXNlYy5kZS9vY3NwcjA6BggrBgEFBQcw AoYuaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9jcnQvRFRfUk9PVF9DQV8yLmNlcjANBgkq hkiG9w0BAQsFAAOCAQEAYyAo/ZwhhnK+OUZZOTIlvKkBmw3Myn1BnIZtCm4ssxNZdbEzkhth Jxb/w7LVNYL7hCoBSb1mu2YvssIGXW4/buMBWlvKQ2NclbbhMacf1QdfTeZlgk4y+cN8ekvN TVx07iHydQLsUj7SyWrTkCNuSWc1vn9NVqTszC/Pt6GXqHI+ybxA1lqkCD3WvILDt7cyjrEs jmpttzUCGc/1OURYY6ckABCwu/xOr24vOLulV0k/2G5QbyyXltwdRpplic+uzPLl2Z9Tsz6h L5Kp2AvGhB8Exuse6J99tXulAvEkxSRjETTMWpMgKnmIOiVCkKllO3yG0xIVIyn8LNrMOVtU FzCCBVcwggQ/oAMCAQICBxev9uxcqeowDQYJKoZIhvcNAQELBQAwWjELMAkGA1UEBhMCREUx EzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1W ZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0xNDA2MDUxNDA2MjFaFw0xOTA3MDkyMzU5MDBa MHsxCzAJBgNVBAYTAkRFMSAwHgYDVQQKExdVbml2ZXJzaXRhZXQgenUgTHVlYmVjazEnMCUG A1UEAxMeQ0EgZGVyIFVuaXZlcnNpdGFldCB6dSBMdWViZWNrMSEwHwYJKoZIhvcNAQkBFhJw a2lAdW5pLWx1ZWJlY2suZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCWZS7m r7XjjwizbKXx3HQYxk369Bw40r31jGlnN0lJl2e+VCzKa2KOSGndQ2dfPEFfGTS16BEhpf8S PPYDPEsMz8WR/FnZdFGK4qpV0b7+pzN7L4xgnKoG2LXWaJR2hygCb6fG2EiPWT7eovN4PK/s NXj/5ekPfXdyKrD9fbMPhll+mTTR9DsCypH5oDGOFAsNAn3h0iE4dYPTl67T3LGhYl7Wd7Z9 zSZRfD6a+lOmJ86jguBL1rfq5wvefwIvsGZYYwOTf+uZyMosFYZlGMJCY0m9JO/ZNoRGdDGd v1iFVSxeL0im28gZzoREaPbc7qFaTKw0w2kCoROEYhXmrqFDAgMBAAGjggH/MIIB+zASBgNV HRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjARBgNVHSAECjAIMAYGBFUdIAAwHQYD VR0OBBYEFLcrb8DHGBAxNhdSEHWh0EDDOTQfMB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn3 8QpwPt5kMB0GA1UdEQQWMBSBEnBraUB1bmktbHVlYmVjay5kZTCBiAYDVR0fBIGAMH4wPaA7 oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNy bC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHVi L2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHKMIHHMDMGCCsGAQUFBzABhidodHRwOi8v b2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1AwRwYIKwYBBQUHMAKGO2h0dHA6Ly9j ZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcG CCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEAdYeYj/1b9DL3QJ4OXOWkGJsv yq1Y5rUXkBp9gfrWv4hwHrojJAgzgSf6D9f4emRAl85q59g/MbcEa6ykxFaVqwDnf72vP8+y E7lRTf7fX5RwtX4OWdqSvdwL/yERRcXkC1OSZoLNgWbV3LgVx1qorSlRFf1g7GFGpRz6+We5 UpxrbRNLpCctu8nI3j+/Yf0gHemPd47+UsqJyqJSGR2PRwes2145sN3SKNIGwNuGD9yT31ME IGbQYs5+tvVwy4dPL563krryekiACiMIdlmAuq07gEY3cJcQpxRfQT7TGLE6A2BBHEOCI/bm qvxf3sleblFjqbX/4Q9fvBBV5Ri2iTCCBa8wggSXoAMCAQICBxjfNvsLscMwDQYJKoZIhvcN AQELBQAwezELMAkGA1UEBhMCREUxIDAeBgNVBAoTF1VuaXZlcnNpdGFldCB6dSBMdWViZWNr MScwJQYDVQQDEx5DQSBkZXIgVW5pdmVyc2l0YWV0IHp1IEx1ZWJlY2sxITAfBgkqhkiG9w0B CQEWEnBraUB1bmktbHVlYmVjay5kZTAeFw0xNTAxMjExNDM2MjdaFw0xODAxMjAxNDM2Mjda MGkxCzAJBgNVBAYTAkRFMSAwHgYDVQQKExdVbml2ZXJzaXRhZXQgenUgTHVlYmVjazEgMB4G A1UECxMXSW5zdGl0dXQgZnVlciBUZWxlbWF0aWsxFjAUBgNVBAMTDU9saXZlciBLbGVpbmUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDA68ufre0edWEVwZPx2Ur3Haw0Jujt GnNI0fhuh9DVxEHmHENt3jr7KeczK5+eS/kxHx3OoiLuJSNPxuoJ2M14aWIrJPU5ZS6hfbxl CosqCJlvPyNb85lE18BaR7fSmCKpn6766WK/3/K13vF7lMlm+if+mNv1Fo45JIsBGSNkKCrM HOVESfmUVrdkkKXaKL24H7kouED9gPAyTqG23XvFxd3JWHLpq4aGA/NWnDpcyqOpovb3bIae CpObD16FlfcE7yL9BxNlRPxVQ6s+uhXjp9T5/5KC/yXITO4wmn8Mm1Ayrf586sESr98S5A+D bwGTaotKo08NZeuPsrhncELnAgMBAAGjggJIMIICRDBABgNVHSAEOTA3MBEGDysGAQQBga0h giwBAQQDAzARBg8rBgEEAYGtIYIsAgEEAwEwDwYNKwYBBAGBrSGCLAEBBDAJBgNVHRMEAjAA MAsGA1UdDwQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYE FDi+RAwHFnUHTn3ye1QbirMevhyIMB8GA1UdIwQYMBaAFLcrb8DHGBAxNhdSEHWh0EDDOTQf MCQGA1UdEQQdMBuBGWtsZWluZUBpdG0udW5pLWx1ZWJlY2suZGUwgYgGA1UdHwSBgDB+MD2g O6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1sdWViZWNrLWNhL3B1Yi9jcmwvY2Fj cmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL3VuaS1sdWViZWNrLWNhL3B1 Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAzBggrBgEFBQcwAYYnaHR0cDov L29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsGAQUFBzAChjtodHRwOi8v Y2RwMS5wY2EuZGZuLmRlL3VuaS1sdWViZWNrLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBH BggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS91bmktbHVlYmVjay1jYS9wdWIv Y2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAH7rO2CNs9yHSBVdXZfH0FK4 W1Dsj5viQezzAaauKehV1SN1B/BSsTwgNfGR5VwFgeVxMEr3syTWPzSqLe2X938kLogfI87K 4fsgvNIN8kDXed2HjJZp5QKS/HL1OHKBIbYHVLB3aVvnUtf9RYXPeEV9GYxCZxIjmer6gvsV kSuPE66ZN84V4rt7kCfCMdsB+p2KTL33bTmBBbrTL9/JbG+gmFXV36YYAUGfEHKhNeSO2Kpx Pm0+0CyE+49yJ47kjOpMW+e1xCad+3r2SU3sGkZKcJ0CVsZnzDBQT/M4ZqtpQmzKLFht3Tgm O6+FEsLWh45Q53asSbX4Kiyv9IfF28kxggPDMIIDvwIBATCBhjB7MQswCQYDVQQGEwJERTEg MB4GA1UEChMXVW5pdmVyc2l0YWV0IHp1IEx1ZWJlY2sxJzAlBgNVBAMTHkNBIGRlciBVbml2 ZXJzaXRhZXQgenUgTHVlYmVjazEhMB8GCSqGSIb3DQEJARYScGtpQHVuaS1sdWViZWNrLmRl AgcY3zb7C7HDMA0GCWCGSAFlAwQCAQUAoIICDTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNjEwMDUyMDEwMDNaMC8GCSqGSIb3DQEJBDEiBCCet7tKZDHS +y4tiHqQFix0Ghau1DUCJhP28v/QoNlgxDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGXBgkrBgEEAYI3EAQxgYkwgYYwezELMAkG A1UEBhMCREUxIDAeBgNVBAoTF1VuaXZlcnNpdGFldCB6dSBMdWViZWNrMScwJQYDVQQDEx5D QSBkZXIgVW5pdmVyc2l0YWV0IHp1IEx1ZWJlY2sxITAfBgkqhkiG9w0BCQEWEnBraUB1bmkt bHVlYmVjay5kZQIHGN82+wuxwzCBmQYLKoZIhvcNAQkQAgsxgYmggYYwezELMAkGA1UEBhMC REUxIDAeBgNVBAoTF1VuaXZlcnNpdGFldCB6dSBMdWViZWNrMScwJQYDVQQDEx5DQSBkZXIg VW5pdmVyc2l0YWV0IHp1IEx1ZWJlY2sxITAfBgkqhkiG9w0BCQEWEnBraUB1bmktbHVlYmVj ay5kZQIHGN82+wuxwzANBgkqhkiG9w0BAQEFAASCAQCcam6vWxHBa/LxTSA0P7fvPxZSN7if LeFPKZ+lYAUblejE+ldOUfIzJI0KafBwlcxhWCmbLq6hXXV5FN2LbKe/XlfW7GAgurUR/Dt/ m67NTAgFW/A4C3Ae69I6bz4JtvhPqIqeVXMMXbQ7FyycB6L6EHRXC2qXVVKkgnvHqK9lKM5+ TJ4za7oaA0INhvfdmOwHqthh8b8ZtfmPGiYwPrqKMN2kx8Mi/0bfHSooufBkBgB50AWho+2b OGQCXiFH0NuMejsPcLqol0btIDKDyeKCfk0lnl7hY/3nSEJuDRksdpR8YLwLRfBmoxX+4Gdq 6t8qJOl/oZzVDYltR4Xe2gnnAAAAAAAA --------------ms000309070201050606080707-- From nobody Wed Oct 5 15:22:49 2016 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 BA43E1294B6 for ; Wed, 5 Oct 2016 15:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.022 X-Spam-Level: X-Spam-Status: No, score=-102.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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 Og_aYsFUMAyC for ; Wed, 5 Oct 2016 15:22:43 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0128.outbound.protection.outlook.com [104.47.42.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C5651294CA for ; Wed, 5 Oct 2016 15:22:43 -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=bV4gpmhviR2CFsuR0qRSSHLV5WhFQQ36sv8HRVHCxxs=; b=Iarw8Mb/lqTwyw/Og80i2SDAEne9QQJVQQzlX3226diEe5o5b37w7ZKjRejCFmTfK01xI2YvT8tNiTIKtDjGJYyStS4xXJirYktQ3yF2G+oTIcDacuUEqYaYHAdKuUrOmQWAZPwFO1ETujf518KR2a1LJMiuLEwPTDPLxpCCveU= 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_256_CBC_SHA384_P384) id 15.1.649.16; Wed, 5 Oct 2016 22:22:42 +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.0649.022; Wed, 5 Oct 2016 22:22:42 +0000 From: Dave Thaler To: Oliver Kleine , "core@ietf.org" Thread-Topic: [core] Implications of IP address / port changes for CoAP & Co Thread-Index: AQHSH0SReAmLSj/UDEOms6uHQyQN/6CabhYg Date: Wed, 5 Oct 2016 22:22:41 +0000 Message-ID: References: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> <3febad96-3793-69a6-b78f-1994c0f9708d@itm.uni-luebeck.de> In-Reply-To: <3febad96-3793-69a6-b78f-1994c0f9708d@itm.uni-luebeck.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-originating-ip: [2001:4898:80e8:8::348] x-ms-office365-filtering-correlation-id: 61625540-489d-4c78-17c7-08d3ed6e1f8e x-microsoft-exchange-diagnostics: 1; CY1PR03MB2268; 7:QTjbYsbBvGu7s3vujkb6SQW1mhzZm8SBOQQUzxNoX+3o3eIhkZsG4rZSvh3EtOyuUIEVcN3akoYSjwvv5WJpmFhz1kKulGN6Wx+r+xVV/ApTeDullBf1FEwjcPv5g6CDGgCJGTSBfY1Wa/UHgOtVx34KraTC5iHwc0wQHx9EqHVeiYQ0Urd+/mKRaiiQqmCY0daJToW/zy2Mj4kCN3T+fqdEK8+0gj1ISTthUV8A33Azy+655N4oFkm7MQeGe3A5Bu6VNCpNKbVdVVGWQvGDHxVG1nNKrdcg2FRo40GYrrmBk6wad5vpHUmFImIetWoZ2F4+jto8oSL7EV9O59Z10A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2268; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(192374486261705)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2268; BCL:0; PCL:0; RULEID:(304825118); SRVR:CY1PR03MB2268; x-forefront-prvs: 008663486A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(13464003)(377454003)(85644002)(53754006)(189002)(7696004)(2900100001)(2501003)(5001770100001)(97736004)(77096005)(8676002)(107886002)(81166006)(10090500001)(15975445007)(68736007)(6116002)(102836003)(3280700002)(86612001)(5002640100001)(87936001)(11100500001)(81156014)(5660300001)(8990500004)(92566002)(189998001)(86362001)(586003)(2906002)(3660700001)(50986999)(7736002)(5005710100001)(76176999)(2950100002)(101416001)(54356999)(305945005)(7846002)(10290500002)(99286002)(10400500002)(106116001)(9686002)(19580405001)(8936002)(105586002)(33656002)(106356001)(19580395003)(76576001)(122556002)(74316002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2268; H:CY1PR03MB2265.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2016 22:22:41.6909 (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: Re: [core] Implications of IP address / port changes for CoAP & Co X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 05 Oct 2016 22:22:48 -0000 It is important that every device have a unique UUID that is endpoint-addre= ss-agnostic and protocol-agnostic. Other ecosystems of devices , including WSD, UPnP, = OCF (which uses COAP), AllJoyn, etc., all have a way of passing the same device UUID in various pr= otocols.=20 If CoRE wants to move it down into the COAP protocol itself that would be f= ine (some other ecosystems do so), but it's important that it be a UUID, and that it be pro= tocol-agnostic and not COAP-specific. Besides address/port changes, the other use case is that when the same devi= ce is discovered via multiple paths or protocols, the UI can know to only show it once to th= e user and hide the multiple paths/protocols from the end user. This is often called "dedupli= cation" in the cross-protocol discovery process. Dave -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Oliver Kleine Sent: Wednesday, October 5, 2016 1:10 PM To: core@ietf.org Subject: Re: [core] Implications of IP address / port changes for CoAP & Co Hi Hannes, if I got you right this is exactly the problem I was talking about at IETF = 91 almost two years ago. Back then, I briefly presented an extension draft = with a rather simple approach to solve that issue. If you don't mind, please have a look at [1]. Are you talking about the sam= e thing? Best regards, Oliver [1] https://tools.ietf.org/html/draft-kleine-core-coap-endpoint-id-01 Am 31.08.2016 um 12:36 schrieb Hannes Tschofenig: > Hi all, >=20 > in the OMA device management group we have been discussing the=20 > implications of IP address and/or port number changes of devices=20 > (particularly with devices that sleep for an extended period of time). >=20 > The challenge from a protocol point of view is to use an identifier=20 > that does not depend on the IP address and port. Of course, when a IP=20 > packet has to be sent to a specific node then IP address and port=20 > information has to be used from somewhere but my expectation is that=20 > at least the protocol machinery shouldn't break when an IP address=20 > changes (or there should be a story for how to recover). >=20 > In CoAP the 'endpoint' appears to be an important identifier. In an=20 > attempt to define what an endpoint is the CoAP specification is a bit > confusing: >=20 > Section 1.2 says: >=20 > " > Endpoint > An entity participating in the CoAP protocol. Colloquially, an > endpoint lives on a "Node", although "Host" would be more > consistent with Internet standards usage, and is further > identified by transport-layer multiplexing information that can > include a UDP port number and a security association > (Section 4.1). > " =20 >=20 > Section 4.1 of RFC 7252 says: > =20 > " > A CoAP endpoint is the source or destination of a CoAP message. The > specific definition of an endpoint depends on the transport being > used for CoAP. For the transports defined in this specification, the > endpoint is identified depending on the security mode used (see > Section 9): With no security, the endpoint is solely identified by an > IP address and a UDP port number. With other security modes, the > endpoint is identified as defined by the security mode. > " >=20 > The two definitions do not appear to be in sync, particularly when=20 > using DTLS to secure CoAP since the DTLS record layer adds nothing=20 > with respect to additional multiplexing. I also did not find text that=20 > describes what the different endpoint definition is when DTLS is used. >=20 > In any case, when DTLS is used an IP address / port change at the=20 > client will prevent the CoAP server from finding the right security=20 > context and a new (hopefully abbreviated) handshake has to be run. >=20 > Luckily the implications of an IP address/port change are quite=20 > minimal for CoAP itself since the only impact (as far as I can tell)=20 > is with regards to the use of request/response exchange, as described=20 > in Section > 5.3.2 "Request/Response Matching Rules". The likelihood that a client=20 > changes IP address in the middle of a request/response interaction are=20 > IMHO minimal. >=20 > The story is more interesting when we look at extensions to CoAP, like=20 > CoAP Observe. Section 4.1 of https://tools.ietf.org/html/rfc7641 says: >=20 > " > The entry in the list of observers is keyed by the client endpoint > and the token specified by the client in the request. If an entry > with a matching endpoint/token pair is already present in the list > (which, for example, happens when the client wishes to reinforce its > interest in a resource), the server MUST NOT add a new entry but MUST > replace or update the existing one. > " >=20 > With Observe a token is used for demultiplexing (in addition to the=20 > endpoint info). I assume that the spec uses the same definition of=20 > endpoint as in CoAP. >=20 > While the spec does not say what is actually being updated or replaced=20 > one can assume that a client sending a request with a new IP address=20 > and port (which corresponds to the endpoint definition in CoAP) gets=20 > at least that information updated. >=20 > The spec is IMHO unclear what should happen in case of an IP=20 > address/port change. I suspect that an implementation would send a new=20 > register message and the server would update state. Of course, when=20 > the IP address / port of the client is not in sync with what is being=20 > stored at the server then the notifications sent by the server will=20 > not reach the client. >=20 > The story for RD appears to be different again. First, there appears=20 > to be a different definition of endpoint being used (which I prefer more)= . > For multiplexing it does not use IP address & port information. Of=20 > course, RD will still have to maintain this information but at least=20 > one can be sure that packets are not dropped after the IP address=20 > and/or port at the client change. >=20 > Section 11.1 of draft-ietf-core-resource-directory-08 says: >=20 > " > An Endpoint is determined to be unique by an RD by the Endpoint > identifier parameter included during Registration, and any associated > TLS or DTLS security bindings. An Endpoint MUST NOT be identified by > its protocol, port or IP address as these may change over the > lifetime of an Endpoint. > " >=20 > It appears that the way how state is indexed is different throughout=20 > the specifications developed in the CORE working group and I am=20 > curious whether someone else has been looking at the implications of=20 > IP address and/or port changes on the protocol operation. I would=20 > certainly appreciate your thoughts on this topic. >=20 > Ciao > Hannes >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Dr.-Ing. Oliver Kleine UNIVERSIT=C4T ZU L=DCBECK INSTITUT F=DCR TELEMATIK Ratzeburger Allee 160 23538 L=FCbeck Tel +49 451 3101-6406 (NEU) Fax +49 451 3101-6404 (NEU) kleine@itm.uni-luebeck.de https://www.itm.uni-luebeck.de/people/kleine From nobody Wed Oct 5 15:28:48 2016 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 B4E401294B6 for ; Wed, 5 Oct 2016 15:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.297 X-Spam-Level: X-Spam-Status: No, score=-7.297 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_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 7kmsMdIq3dtD for ; Wed, 5 Oct 2016 15:28:45 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD5321294A9 for ; Wed, 5 Oct 2016 15:28:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0EF48BE53; Wed, 5 Oct 2016 23:28:43 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWJEtvUTW98X; Wed, 5 Oct 2016 23:28:41 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C14B4BE4D; Wed, 5 Oct 2016 23:28:40 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1475706521; bh=3XrSxYX7odFstX3koyn/6nS0K/N1iI+xHucVrrg/GJU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=VV9IF43E/lxv0bgKGqBxSNh94H3fEO4cFvFzFDfjeoDnRMwGwyAMt4yTwoKYbV3Rl iZCchlsbNGNGmalRg4RbEsm8mHn915pB7T6j8uDP5nd8G1qlStROJa5BvEGsJMTZuX V/tdKJI5jOsMZz3t5acOwwcxG+2bPfl5gUVgTsdA= To: Dave Thaler , Oliver Kleine , "core@ietf.org" References: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> <3febad96-3793-69a6-b78f-1994c0f9708d@itm.uni-luebeck.de> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <7392d335-d0e7-cf83-24a7-61d40f37c57c@cs.tcd.ie> Date: Wed, 5 Oct 2016 23:28:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020600010703000907090005" Archived-At: Subject: Re: [core] Implications of IP address / port changes for CoAP & Co X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 05 Oct 2016 22:28:47 -0000 This is a cryptographically signed message in MIME format. --------------ms020600010703000907090005 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Dave, On 05/10/16 23:22, Dave Thaler wrote: > It is important that every device have a unique UUID that is > endpoint-address-agnostic and protocol-agnostic. Considering the privacy implications I'm not at all sure I'd accept that argument. In fact I'd argue we ought encourage that devices not have globally unique long-term identifiers at all unless there is a real need for those, and unless we understand how to control their (ab)use. Cheers, S. --------------ms020600010703000907090005 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMDUy MjI4NDFaMC8GCSqGSIb3DQEJBDEiBCD/A9v9Kh5+JGcKXug1CaChc0bYO4hBarhMWmidgHIl 7zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAJHnSN5e98Rh8liJs+30rW7pjHIx7tIL0jidJTjp/OSm7WoocNOU/i G/RUmNkxEiqjGqFVsTeGUeuxnDrT7Qyx/k6ni0ykBtuf3yzg2X3ms7JWCGLTbZKGE5cXIyoA P48bKeJYRNskTe3V3rlWcrlPkHSNpJkomiKW/3bxotOmSXJzIEdHcmWHDwx1pWd2i/FE52Zs VG8RN0w9wpHBooTjNofTNK0kgJmyT3cTZSXm/q4n1ylQNeXYG6Mq9hs0vmOkojUwIgNkFp8O sTp1hK+7vGodhWEvPDKlf+JF8PDmqEapycYDxCECXeY9Fqo68kWNvYevapS/aJkWJdooaU2f AAAAAAAA --------------ms020600010703000907090005-- From nobody Wed Oct 5 15:47:25 2016 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 AD8811294CD for ; Wed, 5 Oct 2016 15:47:24 -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 IFJ2slm-eh_i for ; Wed, 5 Oct 2016 15:47:23 -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 A1CEE1294C5 for ; Wed, 5 Oct 2016 15:47:20 -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 u95MlGes009542; Thu, 6 Oct 2016 00:47:16 +0200 (CEST) Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3sq9s04JQLz1jtP; Thu, 6 Oct 2016 00:47:16 +0200 (CEST) Message-ID: <57F5830A.9030307@tzi.org> Date: Thu, 06 Oct 2016 00:47:38 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Stephen Farrell References: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> <3febad96-3793-69a6-b78f-1994c0f9708d@itm.uni-luebeck.de> <7392d335-d0e7-cf83-24a7-61d40f37c57c@cs.tcd.ie> In-Reply-To: <7392d335-d0e7-cf83-24a7-61d40f37c57c@cs.tcd.ie> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Implications of IP address / port changes for CoAP & Co X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 05 Oct 2016 22:47:24 -0000 The magic word seems to be "directed identity". It seems best to keep long-term identifiers confined to usage within a long-term security association. We don't have good mechanisms to manage those. An example for what we could use is a mechanism that allows a CoAP node to say to another node "here is my new transport address. I'm not telling you right away who I am, but if as I believe we are sharing a security association, here is some information that allows *only you* to find out which", e.g. in order to resume a DTLS connection. (draft-barrett-mobile-dtls doesn't cut it here.) We will discuss this specific issue next at T2TRG in Ludwigsburg, 2016-10-27. Submissions to this meeting would be very welcome. Grüße, Carsten Stephen Farrell wrote: > Hi Dave, > > On 05/10/16 23:22, Dave Thaler wrote: >> It is important that every device have a unique UUID that is >> endpoint-address-agnostic and protocol-agnostic. > > Considering the privacy implications I'm not at all sure I'd > accept that argument. In fact I'd argue we ought encourage > that devices not have globally unique long-term identifiers at > all unless there is a real need for those, and unless we > understand how to control their (ab)use. > > Cheers, > S. > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Oct 5 15:54:22 2016 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 481581294D1 for ; Wed, 5 Oct 2016 15:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.297 X-Spam-Level: X-Spam-Status: No, score=-7.297 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_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 KsC2h54yIP7r for ; Wed, 5 Oct 2016 15:54:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32711294D0 for ; Wed, 5 Oct 2016 15:54:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6A216BE6F; Wed, 5 Oct 2016 23:54:17 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_qfiB6EgK2J; Wed, 5 Oct 2016 23:54:16 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6F09ABE53; Wed, 5 Oct 2016 23:54:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1475708055; bh=7KTv8vmX2MKrrSPxVcvZ80+2TcGpqARbaYTodgBumH4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=nmlTKwR/dc8UDgiffqcK49zHM0l1Rn9Eqc6IhXhoP9PCOzUyhD2ekKFj4JN4M42tL Erl54OQCtY+dLLCF3O/BywxrzOrC8Z/SgKT6KTi7CZIJ5gl3VXhTla+W6LQE/dSx8Y DKYbrU1677g1XC+usbl/dzG+QBvYmT7gRRncIw/U= To: Carsten Bormann References: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> <3febad96-3793-69a6-b78f-1994c0f9708d@itm.uni-luebeck.de> <7392d335-d0e7-cf83-24a7-61d40f37c57c@cs.tcd.ie> <57F5830A.9030307@tzi.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <38eb148a-d2d9-477a-0e96-82c2c86b76ec@cs.tcd.ie> Date: Wed, 5 Oct 2016 23:54:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <57F5830A.9030307@tzi.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030108080409010506010905" Archived-At: Cc: "core@ietf.org" Subject: Re: [core] Implications of IP address / port changes for CoAP & Co X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 05 Oct 2016 22:54:21 -0000 This is a cryptographically signed message in MIME format. --------------ms030108080409010506010905 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/10/16 23:47, Carsten Bormann wrote: > The magic word seems to be "directed identity". >=20 > It seems best to keep long-term identifiers confined to usage within a > long-term security association. >=20 > We don't have good mechanisms to manage those. >=20 > An example for what we could use is a mechanism that allows a CoAP node= > to say to another node "here is my new transport address. I'm not > telling you right away who I am, but if as I believe we are sharing a > security association, here is some information that allows *only you* t= o > find out which", e.g. in order to resume a DTLS connection. > (draft-barrett-mobile-dtls doesn't cut it here.) Discussing such semantics and how to make them practical seems like a fine thing to me. While solving the problem for CoAP is a good thing, I'd hope that solutions (if they exist) could be generalised too. (Esp. since the discussion will be in an RG and not the core WG.) >=20 > We will discuss this specific issue next at T2TRG in Ludwigsburg, > 2016-10-27. Submissions to this meeting would be very welcome. Submission: please solve the above, if you can:-) Sorry I can't make that. If t2trg meet in Seoul and there's a report out on the topic, I'd go though. Cheers, S. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >=20 >=20 > Stephen Farrell wrote: >> Hi Dave, >> >> On 05/10/16 23:22, Dave Thaler wrote: >>> It is important that every device have a unique UUID that is >>> endpoint-address-agnostic and protocol-agnostic. >> >> Considering the privacy implications I'm not at all sure I'd >> accept that argument. In fact I'd argue we ought encourage >> that devices not have globally unique long-term identifiers at >> all unless there is a real need for those, and unless we >> understand how to control their (ab)use. >> >> Cheers, >> S. >> >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 --------------ms030108080409010506010905 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMDUy MjU0MTVaMC8GCSqGSIb3DQEJBDEiBCDIcPAbLEyCIDqRyX7VjSIbpqDcVQMSFYGD1j8dRvc6 PjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBFblxf81VdiXAElkmr4Dcqlj2SKlgkrVXCVyRoknp0CKrgSO6qDyBk ++Cg9LvD2Xp47Ylw3v9aaNLnHlcNGbg3C5014Qz1rXaQ5B5kIklu9gZIz56fy+lKjrSIFXHD XS3Oz7JA/1wk2EnctRiTGwZSZCzatZ6SArmoQJ9YUC6Aazf3lM8cTcsaYdVMOu8watKY5YU0 0QKOZ1TURW1TgJigHptUuefXChCXEnOUSikOdbE8R+YrU0SNBjtmcwsua8GXMybZki2D7SuI Wmd1T0oufSrIAe6Tgk8XvIsCKmaOZphsoGQxtjhiszHbt/9V1advjtsH1plkEhwSA3LvuDAG AAAAAAAA --------------ms030108080409010506010905-- From nobody Wed Oct 5 16:01:10 2016 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 9F69E1294D0 for ; Wed, 5 Oct 2016 16:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.003 X-Spam-Level: X-Spam-Status: No, score=-102.003 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_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 YPRb9iLvMi3M for ; Wed, 5 Oct 2016 16:01:03 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0102.outbound.protection.outlook.com [104.47.32.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4919F1294D5 for ; Wed, 5 Oct 2016 16:01:03 -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=YMd6AQXEcFBRSPVHQSiPkwvUPsQmFklkicuCm6X5fNg=; b=IqCYICRu4hJhOf6JU58VHdH+cFS5zcvCMZJBWd1YH+1+XquAPTPm+kr6+1FIW6wTNZNDkuW6kZ4KnnTOn+hsRrbWVK7JsjYJ3CXpHsmzUjlEoprbrUyhPMHOQL5G13YzUM6lNDdyosOdv7Y8td5wecJFk3PQp/DYfAEmPzzOewo= 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_256_CBC_SHA384_P384) id 15.1.649.16; Wed, 5 Oct 2016 23:00:56 +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.0649.022; Wed, 5 Oct 2016 23:00:56 +0000 From: Dave Thaler To: Stephen Farrell , Oliver Kleine , "core@ietf.org" Thread-Topic: [core] Implications of IP address / port changes for CoAP & Co Thread-Index: AQHSH0SReAmLSj/UDEOms6uHQyQN/6CabhYggAADBoCAAAh6kA== Date: Wed, 5 Oct 2016 23:00:55 +0000 Message-ID: References: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> <3febad96-3793-69a6-b78f-1994c0f9708d@itm.uni-luebeck.de> <7392d335-d0e7-cf83-24a7-61d40f37c57c@cs.tcd.ie> In-Reply-To: <7392d335-d0e7-cf83-24a7-61d40f37c57c@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-originating-ip: [2001:4898:80e8:8::348] x-ms-office365-filtering-correlation-id: 2cccce10-be59-4280-fc80-08d3ed7376eb x-microsoft-exchange-diagnostics: 1; CY1PR03MB2268; 7:nVDLLijeUar5Sw5GKg1UZUuScVoBUFWSZi+RupbXXvpwweg+dGlXNY1ZxUbmvZfwBqVwP/Hm2HedVofiS5ZosvOa7J5/ieRddvmSfYdap27c95yGo52/CsprzVD8wfZqgbQfnoGFkSCjXgdwoKB8vHJRm3VPByoBrydSYclRs3Fr1kUFWh5o7HoIg48RMD00T6FJihHBm/xkxkO+X+NMYu5tjLBCKjKhWhiAWmglG1s/NNPg2PXWihudOI4u9Q73ujCg7MEoApH2WGEVzFAScTkreoQ2U8LdyHKHDEA+KsMwxVPseCjIaFXg+tvVmeorQ7OK3Eoy984dUQ7+8I7mMg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2268; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2268; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2268; x-forefront-prvs: 008663486A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(13464003)(199003)(24454002)(54356999)(305945005)(101416001)(2950100002)(10400500002)(99286002)(7846002)(10290500002)(7736002)(76176999)(5005710100001)(50986999)(74316002)(76576001)(122556002)(8936002)(106116001)(9686002)(19580405001)(19580395003)(106356001)(105586002)(33656002)(107886002)(8676002)(81166006)(77096005)(68736007)(10090500001)(2900100001)(2501003)(7696004)(5001770100001)(97736004)(189998001)(92566002)(3660700001)(86362001)(586003)(2906002)(86612001)(11100500001)(5002640100001)(87936001)(93886004)(102836003)(3280700002)(6116002)(8990500004)(81156014)(5660300001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2268; H:CY1PR03MB2265.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) 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: 05 Oct 2016 23:00:55.9879 (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: Re: [core] Implications of IP address / port changes for CoAP & Co X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 05 Oct 2016 23:01:08 -0000 Rm9yIHByaXZhY3ksIGl0IGlzIGFsc28gaW1wb3J0YW50IHRoYXQgdGhlIFVVSUQgbm90IGJlIGRp c2Nsb3NlZCB0byB1bnRydXN0ZWQgcGFydGllcywgYnV0IHRoYXQgaXQgYmUgZGlzY2xvc2VkIG9u bHkgdG8gdHJ1c3RlZCBwYXJ0aWVzLg0KUHJpdmFjeSBkb2VzIG5vdCBkaWN0YXRlIHRoYXQgdGhl cmUgc2hvdWxkbid0IGJlIG9uZSwgaXQganVzdCBkaWN0YXRlcyB3aG8gbm90IHRvIGxldCBzZWUg aXQuDQoNCihUaGlzIGlzIGEgc2lnbmlmaWNhbnQgcGllY2Ugb2YgdGhlIGlzc3VlIHRoYXQgbGVk IHRvIG15IHJlZGlyZWN0cyBkcmFmdC4pDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBTdGVwaGVuIEZhcnJlbGwgW21haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllXSAN ClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciA1LCAyMDE2IDM6MjkgUE0NClRvOiBEYXZlIFRoYWxl ciA8ZHRoYWxlckBtaWNyb3NvZnQuY29tPjsgT2xpdmVyIEtsZWluZSA8a2xlaW5lQGl0bS51bmkt bHVlYmVjay5kZT47IGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbY29yZV0gSW1wbGljYXRp b25zIG9mIElQIGFkZHJlc3MgLyBwb3J0IGNoYW5nZXMgZm9yIENvQVAgJiBDbw0KDQoNCkhpIERh dmUsDQoNCk9uIDA1LzEwLzE2IDIzOjIyLCBEYXZlIFRoYWxlciB3cm90ZToNCj4gSXQgaXMgaW1w b3J0YW50IHRoYXQgZXZlcnkgZGV2aWNlIGhhdmUgYSB1bmlxdWUgVVVJRCB0aGF0IGlzDQo+IGVu ZHBvaW50LWFkZHJlc3MtYWdub3N0aWMgYW5kIHByb3RvY29sLWFnbm9zdGljLg0KDQpDb25zaWRl cmluZyB0aGUgcHJpdmFjeSBpbXBsaWNhdGlvbnMgSSdtIG5vdCBhdCBhbGwgc3VyZSBJJ2QNCmFj Y2VwdCB0aGF0IGFyZ3VtZW50LiBJbiBmYWN0IEknZCBhcmd1ZSB3ZSBvdWdodCBlbmNvdXJhZ2UN CnRoYXQgZGV2aWNlcyBub3QgaGF2ZSBnbG9iYWxseSB1bmlxdWUgbG9uZy10ZXJtIGlkZW50aWZp ZXJzIGF0DQphbGwgdW5sZXNzIHRoZXJlIGlzIGEgcmVhbCBuZWVkIGZvciB0aG9zZSwgYW5kIHVu bGVzcyB3ZQ0KdW5kZXJzdGFuZCBob3cgdG8gY29udHJvbCB0aGVpciAoYWIpdXNlLg0KDQpDaGVl cnMsDQpTLg0KDQoNCg== From nobody Wed Oct 5 16:03:54 2016 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 A262E1294D0 for ; Wed, 5 Oct 2016 16:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=filament-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 IRt6LepmIZjg for ; Wed, 5 Oct 2016 16:03:52 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 D9E66129439 for ; Wed, 5 Oct 2016 16:03:51 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id i202so2182059ioi.2 for ; Wed, 05 Oct 2016 16:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=4BbgOzXkwsWo8x7Jfne/gMhEhhEVk5b71FiMxOC/Cuw=; b=OGkqyB+NniN4+FAMOkLVuZmaXoqif8kdjvtcLScoFf9ya/p+0/43+eV4Rkhv3toL5K /6KhQxWVbphw1Jb9R+YlOZ3jqpa9Do8cFywD6wkeuv1HrDmBL/Qy+i6X9DRE0FPuquFZ bQm0GcI9sJOujVIvAO1/qqEiul/F4i4SmiBXnzDWFXkLgJaBnTkPD+JOFA/7xdd3crM4 aeRi8GQtTutGIvPGL7Ke7eGp+s28TbBplf1/UxOQWjcLUSJwzw4XPt+vvzRBpT/YQJFB OF/7pgZXVWBcot9HFwhpQWHyPCVDykLoLaTuRK9lBULzwLeOTGcwnRU2yIfh+hcX15Zl 2rvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=4BbgOzXkwsWo8x7Jfne/gMhEhhEVk5b71FiMxOC/Cuw=; b=JqfxOnNtYGi6fZqrfGpg2fD8PlpWepU1fCNtYUMnIwykbOZ7lBZ0LSki8tQ1m38HPU EEbxtaXL5Et5jCAgaakUdjcsKPr9y4otMG6toXMdyatfDQWvnBcGkb0rKtdmmEd110xk glY5JLGKigdcyQJaroAXpDY5ROfz89OMzs4GvGrUZQXXEDYiNVN9BrnBlmZCZe5iradV 6uQeQYRinJUORBpzFiC378v8Wkyy06vG8s5OC1umOVdd6qeUstyTNCoYHcrjqDa36J8t e/OAed5W+L8XgyhpLzxw5UixJuFT0R3Kq4qdXKeup9dl3hA33eMDtIGZcIIfTTZy8YaT XQ6w== X-Gm-Message-State: AA6/9RkycSKIae8vOdcQTjC5inlXTcb0BkU/la+QcoI4Q2qBUtHuoCApx0ywcET6eTjTzg== X-Received: by 10.107.146.4 with SMTP id u4mr11815384iod.34.1475708631221; Wed, 05 Oct 2016 16:03:51 -0700 (PDT) Received: from aither.local ([76.25.4.24]) by smtp.gmail.com with ESMTPSA id b133sm12538136iti.21.2016.10.05.16.03.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Oct 2016 16:03:50 -0700 (PDT) To: Stephen Farrell , Dave Thaler , Oliver Kleine , "core@ietf.org" References: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> <3febad96-3793-69a6-b78f-1994c0f9708d@itm.uni-luebeck.de> <7392d335-d0e7-cf83-24a7-61d40f37c57c@cs.tcd.ie> From: Peter Saint-Andre - Filament Message-ID: Date: Wed, 5 Oct 2016 17:03:50 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <7392d335-d0e7-cf83-24a7-61d40f37c57c@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [core] Implications of IP address / port changes for CoAP & Co X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 05 Oct 2016 23:03:53 -0000 On 10/5/16 4:28 PM, Stephen Farrell wrote: > On 05/10/16 23:22, Dave Thaler wrote: >> It is important that every device have a unique UUID that is >> endpoint-address-agnostic and protocol-agnostic. > > Considering the privacy implications I'm not at all sure I'd > accept that argument. In fact I'd argue we ought encourage > that devices not have globally unique long-term identifiers at > all unless there is a real need for those, and unless we > understand how to control their (ab)use. By "identifier" do we necessarily mean "network identifier"? It seems to me that it is useful to have a unique long-term identifier for every device, based on its public key. Whether you can obtain a network connection to that device based on such information is another story. Peter -- Peter Saint-Andre https://filament.com/ From nobody Wed Oct 5 16:07:33 2016 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 5D6C31294DC for ; Wed, 5 Oct 2016 16:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.297 X-Spam-Level: X-Spam-Status: No, score=-7.297 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_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 Cvizuu0Gv-Kw for ; Wed, 5 Oct 2016 16:07:30 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D28BC1294D6 for ; Wed, 5 Oct 2016 16:07:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 21148BE5C; Thu, 6 Oct 2016 00:07:28 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYurhSJ9YA_i; Thu, 6 Oct 2016 00:07:26 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4BF28BE53; Thu, 6 Oct 2016 00:07:26 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1475708846; bh=MChPoQE67g9FBYZKuQdl6vW/pO8z0Dfr8gSuXtWzIig=; h=Subject:To:References:From:Date:In-Reply-To:From; b=wua1gtsb37KMsSueId4BiV1KG2/m3fy+jqa6bmXyoCpylqp8VWWRJax44ywNwknwx gjd1O1uFchlcdTnGjFlXePhBu5mCScWY4XzI5o3OMbm2mWruP/rMNhXrGJfF4aXZxH ofnEh5gbp7nsPlMAbdVTiaiGBrDquYWrUiVb0rto= To: Dave Thaler , Oliver Kleine , "core@ietf.org" References: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> <3febad96-3793-69a6-b78f-1994c0f9708d@itm.uni-luebeck.de> <7392d335-d0e7-cf83-24a7-61d40f37c57c@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <597b2caa-0c9c-9f8e-bb78-24c9a769086b@cs.tcd.ie> Date: Thu, 6 Oct 2016 00:07:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000209010807050705030101" Archived-At: Subject: Re: [core] Implications of IP address / port changes for CoAP & Co X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 05 Oct 2016 23:07:31 -0000 This is a cryptographically signed message in MIME format. --------------ms000209010807050705030101 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/10/16 00:00, Dave Thaler wrote: > For privacy, it is also important that the UUID not be disclosed to > untrusted parties, but that it be disclosed only to trusted parties.=20 > Privacy does not dictate that there shouldn't be one, it just > dictates who not to let see it. Well, again I'm not sure I agree. (I do agree that we don't "dictate" though:-) I would argue that we ought not assume the existence of any long term stable identifier when we don't need one. That implies justifying each one. And I'd further argue that each re-use of such ought also be similarly justified. The "disclose to trusted parties" thing is just too easy to end up meaning "wave arms and hope all's well (knowing it won't be)" S PS: Note that I am not claiming that there is IETF consensus for the above (but it'd be nice:-), it's just what I happen to think. >=20 > (This is a significant piece of the issue that led to my redirects > draft.) >=20 > -----Original Message----- From: Stephen Farrell > [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, October 5, 2016 > 3:29 PM To: Dave Thaler ; Oliver Kleine > ; core@ietf.org Subject: Re: [core] > Implications of IP address / port changes for CoAP & Co >=20 >=20 > Hi Dave, >=20 > On 05/10/16 23:22, Dave Thaler wrote: >> It is important that every device have a unique UUID that is=20 >> endpoint-address-agnostic and protocol-agnostic. >=20 > Considering the privacy implications I'm not at all sure I'd accept > that argument. In fact I'd argue we ought encourage that devices not > have globally unique long-term identifiers at all unless there is a > real need for those, and unless we understand how to control their > (ab)use. >=20 > Cheers, S. >=20 >=20 --------------ms000209010807050705030101 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMDUy MzA3MjZaMC8GCSqGSIb3DQEJBDEiBCBCbh7bd8ZAZwEMRZwBoP2LBdVgjzg9AGkGS95yQN3M 2DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAWvp/WjLgjSqhPjrg4MkB+8feagv8Nl0LDB3mq1uJjZFk1k3kcwaly DghSrMF/6cBicz+gdxM0SuMArKTHRkepHjXex+VjtcylSQQxJVjynrCXevmojiGyk5F10Gmt oRU18nuisWGBA4lXHtGpDEb0F1HGogkp4DaJWj1+OnkZ32KXx1X/Gy3rt+4142SAeAplj/Gd jHiwIxtH2RT+IDktpE6Yiu23LJctAJR7c6kxfLj27ZQJDB2TmM51F+PrZbQffKGcLZezfR9D UDg5te7jboAQLj1/7TQYSVAJPGZxsS5AN0ty8ek6JAa0mXDCqu682JBQBfC4S7uTXmYQT0oy AAAAAAAA --------------ms000209010807050705030101-- From nobody Wed Oct 5 16:11:14 2016 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 7D4CA1294E2 for ; Wed, 5 Oct 2016 16:11:13 -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 f5L6DEChAScP for ; Wed, 5 Oct 2016 16:11:12 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 AE3761294DD for ; Wed, 5 Oct 2016 16:11:11 -0700 (PDT) X-AuditID: c1b4fb30-f60a598000000cb2-83-57f5888d2eb7 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by (Symantec Mail Security) with SMTP id CF.07.03250.D8885F75; Thu, 6 Oct 2016 01:11:09 +0200 (CEST) Received: from nomadiclab.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.319.2; Thu, 6 Oct 2016 01:10:58 +0200 Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 18E754EE5E; Thu, 6 Oct 2016 02:09:28 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id ED6CB4E8CC; Thu, 6 Oct 2016 02:09:26 +0300 (EEST) To: Dave Thaler , Stephen Farrell , Oliver Kleine , "core@ietf.org" References: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> <3febad96-3793-69a6-b78f-1994c0f9708d@itm.uni-luebeck.de> <7392d335-d0e7-cf83-24a7-61d40f37c57c@cs.tcd.ie> From: Mohit Sethi Message-ID: <4e0bba4a-cee1-a596-0494-5cd84a48d436@ericsson.com> Date: Wed, 5 Oct 2016 19:10:42 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000502050505040401090802" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM+JvjW5vx9dwg8PfLS32vV3PbHFpxRFW iwlXfrBbTN97jd2BxWNt91U2jyVLfjJ5nJ/TxOzRuuMvewBLFJdNSmpOZllqkb5dAlfG0b+v WAsmW1esnHOUrYFxi3kXIyeHhICJxPEFX5m7GLk4hAQ2MEp0v17KBuFsZZTY0LwBylnHKPHi +TuosvmMEq23NrKD9AsLeEv0/L/ICpIQEVjCKLHlygJWiKrzTBK3vyxnAaliE9CT6Dx3nBnE 5hWwl7gyYSIjiM0ioCIx6cZaJhBbVCBC4tbDDhaIGkGJkzOfgNmcArESU5YdYgQZyizQzSjx un0VG8TpahJXz20CGyokoC6xteMA4wRGwVlI+mch6wFJMAvYStyZu5sZwtaWWLbwNZRtLTHj 10GoGkWJKd0P2SFsU4nXRz8yQtjGEsvW/WVbwMixilG0OLU4KTfdyEgvtSgzubg4P08vL7Vk EyMwug5u+W2wg/Hlc8dDjAIcjEo8vAvsv4YLsSaWFVfmHmJUAZrzaMPqC4xSLHn5ealKIryS 7UBp3pTEyqrUovz4otKc1OJDjNIcLErivGYr74cLCaQnlqRmp6YWpBbBZJk4OKUaGEUWPS9d rmdq3GnCKPS/Y1JbRcnzN5qZn/rZb2819+PSl161rfejo1rNLOncZJ3gz60S0tLVJW8KLmRX a/eUzSx+KROufE3nnseB7TF7RPb/1vl2pHPHAZ6pxQXn+h5uKXpew7df5vcuoUNJRm3Cf/+v ba2TWuXolPo/76lnss4blYtar3r5lFiKMxINtZiLihMBeL4cXrYCAAA= Archived-At: Subject: Re: [core] Implications of IP address / port changes for CoAP & Co X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 05 Oct 2016 23:11:13 -0000 --------------ms000502050505040401090802 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable What is trusted today, may not be trusted tomorrow (servers get=20 compromised all the time). But once revealed, there is no way of going=20 back. Thanks /--Mohit On 10/05/2016 07:00 PM, Dave Thaler wrote: > For privacy, it is also important that the UUID not be disclosed to unt= rusted parties, but that it be disclosed only to trusted parties. > Privacy does not dictate that there shouldn't be one, it just dictates = who not to let see it. > > (This is a significant piece of the issue that led to my redirects draf= t.) > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Wednesday, October 5, 2016 3:29 PM > To: Dave Thaler ; Oliver Kleine ; core@ietf.org > Subject: Re: [core] Implications of IP address / port changes for CoAP = & Co > > > Hi Dave, > > On 05/10/16 23:22, Dave Thaler wrote: >> It is important that every device have a unique UUID that is >> endpoint-address-agnostic and protocol-agnostic. > Considering the privacy implications I'm not at all sure I'd > accept that argument. In fact I'd argue we ought encourage > that devices not have globally unique long-term identifiers at > all unless there is a real need for those, and unless we > understand how to control their (ab)use. > > Cheers, > S. > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------ms000502050505040401090802 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKwwggXuMIID1qADAgECAhAQR5JVnNLKtD1FopLU12S6MA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTEwNjA3MzMxNFoXDTE3MTEwNjA3MzMxM1owaDERMA8GA1UECgwIRXJpY3Nzb24x FjAUBgNVBAMMDU1vaGl0IFNldGhpIE0xKTAnBgkqhkiG9w0BCQEWGm1vaGl0Lm0uc2V0aGlA ZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlc2V0bW9oMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvSfTetNQu8RTOPssYplNRFzoIht/yijWoVTkmFBi71zeZer1H0YVv7MdMeeH 7FAPhlJ8tz5l+ovh5Osu8JX+hpJYG4pvr6yI/wMMIiA4XnyD1Bw4N1X20hy23mUTzuDhBl65 HF2iOAcD2hjCQM9ObVY4A6R1Ckn6TdEzmRQ/68vzrGIY41iffIvmlT2GYvqoQIzGwdBHW78b Es3sulc1tC+inyqhqSobXcdh/mtBbg1sHlwFwlOhu7Bpa+W1hqJuZcix5HMV7D4Cg3QJ6WJ/ SOjdtnvnHM88dCFKZWftoSizUcp5MY9CMUReid0YxNi9Q016ECumbzB4rFC/8lgGjQIDAQAB o4IBwDCCAbwwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20v ZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUF BzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8v Y2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIw JQYDVR0RBB4wHIEabW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1Ud DgQWBBTiYWRwmLJKozqivzho0MUE4onqjjAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52 cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBADx5ydquiV9FvleFR/s2 8/QwBlbi6WoY4WZd5oymC2MH3iAyneZkbBlcUAWNG1XlNsYRkAYv4JR8+1TrbpeWH/D/pSwW ArWsUp41nOW9PEfZCA4oRvso9e0UWtc5bhJuEdE3Y42FJfZJcJXsUN8APuX50lcAMoqgZKqm XcAk/RsTjQp0+r63ibD5hU/EeJXpNjIoEo5NRuzHDdWFYdLAL5JjLa6RD6mp3MuuPqDw0q0h BxBrvDdxf9Ev6TPFfKhVdCOgAVVJ6B+4ky7YqVhOylT8n2v2Y2b0WhpHOTXXr1q0aMAYKI+R X1NReXfS0opDMC0Yi/y0G2s3d5zbEBtKuwukbF1nQWZpCJbwFa4So8V+f5se4PdxU/0eLfE3 bKUOpfjwdyjPoVcrs0lsJe+FNNgfPDlj39AZuNEax/DX7Nq/F6YrYrwaF5EgSLMIzfn9lPtY Cd4AmJzLjr8D4XzZGt2f/EWGZwRGR/Yn9q6oWCa+G48tkTEow1FBXD4lPtbKb+GoKK7Ziidi /hMteorcOC/S61DCOGhINSe8r+9sgpOUM5smVEL7U2/0P1uZwqSvPSLpaG+44ZTwbkGfsSMu R4U2aBkEaK9RhcM954VtbWFRT9G7NXmQw3HhoMMyGs1U9D293wwq1GD0jV1ibQH/z74bVW+G GCeXO00w3rFcVl60MIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcN AQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJv b3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJ KoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5I EyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uw ojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiI EeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgA mInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zAN henIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI 4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYA SC+NV8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZ OskPEwtaIHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1 rTqTGIBIe9wjNnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50 cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRy dXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8E CDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0 dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIw QKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFy b290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQE AwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz 9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2 dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A 1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl 6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEA OLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+k XDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpK B0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk 9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAY HZi7RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+ qE/h2DZAJwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF 4PBTVMZtMYIDFDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJp Y3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQEEeSVZzSyrQ9RaKS1NdkujANBglghkgBZQME AgEFAKCCAZcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYx MDA1MjMxMDQyWjAvBgkqhkiG9w0BCQQxIgQgxH39OEUzSeGCKxkhfjCyJeSQFJPJBtPdTi2Z qlyjvTwwXQYJKwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQEEeSVZzSyrQ9RaKS1NdkujBfBgsqhkiG 9w0BCRACCzFQoE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjICEBBHklWc0sq0PUWiktTXZLowbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASC AQC5FNsgRvzfdO2yBhUErKh12/qClsJx0xcDzPif42pYlP4V4fp0LEd00V8Kiik4mKUXpbRd xUbF2ONvQ6cWVtFd06W9sGcvVYKxh2E3dENZnREvfL6vuYRRRrgIHhYxnryoeHvd5qDAjpWD SOqQQ+t30X2hmoOumQg4PviZQ9ErK+8fvRdONbDVdR8PfWRqxxyyi69GXDpia35N9sRKpulZ 3sGc0w0849neBT/XoLYPaF64rTihNpyVFx3/oOROEpZVnCs/zrrcF6aRjkvcpTwuG0nULDnU sq88O+C7GTspCwIBw68W4x+pWq7bGTjqiNobNX/3qJ9ziw+5qMd8OWdMAAAAAAAA --------------ms000502050505040401090802-- From nobody Wed Oct 5 16:11:33 2016 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 A0BB21294E2 for ; Wed, 5 Oct 2016 16:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.297 X-Spam-Level: X-Spam-Status: No, score=-7.297 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_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 e8Z7EK1ApK5u for ; Wed, 5 Oct 2016 16:11:30 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62D181294DC for ; Wed, 5 Oct 2016 16:11:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 72964BE5C; Thu, 6 Oct 2016 00:11:28 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PX2ajaxxpuyT; Thu, 6 Oct 2016 00:11:27 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A71FBBE53; Thu, 6 Oct 2016 00:11:26 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1475709087; bh=enZt0HqkRFyQ0eyrNh5jOfzV08R58YxESBNhaB6fG+4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=kQ+tCltEbQl9x4bEZIVoc0P0Bp4vFW/uKMz+ywbFGZXiksngRCxfEqBDvaWpuRlOt dMhSl6bmsTeUEAuSImEOegDC9Qyo4jdqqkOSjv125e6UEPhL0JwbX4uwbT6PNKnTNC zBtmhQnlNkV5CO6GVioOEV5zwfc7gqhIAmGXEdfk= To: Peter Saint-Andre - Filament , Dave Thaler , Oliver Kleine , "core@ietf.org" References: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> <3febad96-3793-69a6-b78f-1994c0f9708d@itm.uni-luebeck.de> <7392d335-d0e7-cf83-24a7-61d40f37c57c@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> Date: Thu, 6 Oct 2016 00:11:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010108080507060400000103" Archived-At: Subject: Re: [core] Implications of IP address / port changes for CoAP & Co X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 05 Oct 2016 23:11:31 -0000 This is a cryptographically signed message in MIME format. --------------ms010108080507060400000103 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Peter, On 06/10/16 00:03, Peter Saint-Andre - Filament wrote: > On 10/5/16 4:28 PM, Stephen Farrell wrote: >=20 >> On 05/10/16 23:22, Dave Thaler wrote: >>> It is important that every device have a unique UUID that is >>> endpoint-address-agnostic and protocol-agnostic. >> >> Considering the privacy implications I'm not at all sure I'd >> accept that argument. In fact I'd argue we ought encourage >> that devices not have globally unique long-term identifiers at >> all unless there is a real need for those, and unless we >> understand how to control their (ab)use. >=20 > By "identifier" do we necessarily mean "network identifier"? It seems t= o > me that it is useful to have a unique long-term identifier for every > device, based on its public key. Whether you can obtain a network > connection to that device based on such information is another story. It is undoubtedly useful to have long term stable identifiers of various kinds. I'd include key IDs and public keys as such. Turns out that it's also fairly universally privacy unfriendly as people will abuse such identifiers for good and bad reasons. So I think we need to get much better at analysing when such things are really needed and in what scope. My bet is that a lot of the time a locally or probabilistically unique more transient identifier would be just fine. But yeah, I can't prove that. OTOH there is a hint in the term "IMSI catcher" isn't there? Cheers, S. >=20 > Peter >=20 --------------ms010108080507060400000103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMDUy MzExMjZaMC8GCSqGSIb3DQEJBDEiBCD6KlwiumBx6NGTJ9FcD2OtjSKLC4CRWt4JtexSJ+vn qTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBoizY8Gv7wfcyIv30Y0NAUzuZ4XbPuWavRkizG2JckBxbzB2/YAiaN 1vCXaznmYp0PIsoupDlGaUymVRWtSkuP++zV+3yYjfHFG3ERWhtQwf8aDyMjTHaavpgqLqMd rLRS5tGUV/7ronxZdETJDrXsuYoGBYcx9JgvfbOZNvBPIp/OSyGCmTc+r3E16tQWOZunTP6l Erew2D9vxvD5DHXXHI4FccAyrY8oF8Gp6ghU2p+PMfgubjXmRi25OGpS35lMykHXVT7C3Kjk nOpSCVVPGcWJDnAgve0Qce2bSOX93RcLIu8mzO0nOxS3SceFAv9DUixKwDr87hVcHPuto0Ag AAAAAAAA --------------ms010108080507060400000103-- From nobody Wed Oct 5 16:30:06 2016 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 12D701294DB for ; Wed, 5 Oct 2016 16:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=filament-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 UH_aufW9X_Po for ; Wed, 5 Oct 2016 16:30:03 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 7BA6A129454 for ; Wed, 5 Oct 2016 16:30:03 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id q192so2670563iod.0 for ; Wed, 05 Oct 2016 16:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=NT4NigpN/GYFXO652222PKKlJpcFdh6efH3OoONrDhs=; b=fcjx+yH3XjseeNAxkcQdo89DnSb2Szg16NpP8Emp9FLwnbnIZrno6VxOAvwAp71GA5 uoS1zeUidNPmKl+FqPefnZS4Ub46mtW/oc0qg5a4HRtyh+W3l91eX8CeumDSrJTiwnSy pDaR5nk4QYuih7YGNRfrvdmyYvbDwywGNDKumN/v/fEuOi/BLCtIz2cCiAL10yzY9HHv nO4MR2v/cFEaPG8DldCMQW4FXS2M14q8BzJXKSa+RJoa7M+E1D3xveGl6Y05MVooBysL dj4c9fCAfGe4pWdU8b/pLkaiG55egxVdBkALbLgrccVw0lMoVEGXuHsaNxsAi7Mi6HzZ jHow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=NT4NigpN/GYFXO652222PKKlJpcFdh6efH3OoONrDhs=; b=NFdA65p0/nnemiI3hDNZx+S98Osog64wyw+yGE9feFxogkcPU2BHlp9xRNqOsmoKDN hG/4H1zcwBFWzxgasSWappCNIzkpQqidNl6S/K/4A0GtixdxWO7mQSn0oQhgzGWrpmZh TTP6ScIVCxpoy+Tm1+j70STPpLgSg2EHeyY3d7GtPcQ0H66hr8+Kv1jVi2FzqZpqJuns axaPVO+mcvE6wBzNcQ+JE1PyrwfXzFZaJAnH6CY9JQqgBCMx+WDiLkCig6Qdjxyl2f4P fmV5SVZHjwFfEcDRPxVrqDo5LEQK7uQx2apVmBrB9+I5l1xSv5F1d29UaNacCPw6PaLi TlTw== X-Gm-Message-State: AA6/9RmO2ycU2Zs3kTIHgMctiFP2eAfNQPKDVf7Y4gCzrwnws9kyIdymQ0NoUnp6beoPPA== X-Received: by 10.107.36.136 with SMTP id k130mr14022619iok.23.1475710202762; Wed, 05 Oct 2016 16:30:02 -0700 (PDT) Received: from aither.local ([76.25.4.24]) by smtp.gmail.com with ESMTPSA id z125sm15081697itc.0.2016.10.05.16.30.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Oct 2016 16:30:01 -0700 (PDT) To: Stephen Farrell , Dave Thaler , "core@ietf.org" References: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> <3febad96-3793-69a6-b78f-1994c0f9708d@itm.uni-luebeck.de> <7392d335-d0e7-cf83-24a7-61d40f37c57c@cs.tcd.ie> <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> From: Peter Saint-Andre - Filament Message-ID: Date: Wed, 5 Oct 2016 17:30:01 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [core] Implications of IP address / port changes for CoAP & Co X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 05 Oct 2016 23:30:05 -0000 On 10/5/16 5:11 PM, Stephen Farrell wrote: > > Hi Peter, > > On 06/10/16 00:03, Peter Saint-Andre - Filament wrote: >> On 10/5/16 4:28 PM, Stephen Farrell wrote: >> >>> On 05/10/16 23:22, Dave Thaler wrote: >>>> It is important that every device have a unique UUID that is >>>> endpoint-address-agnostic and protocol-agnostic. >>> >>> Considering the privacy implications I'm not at all sure I'd >>> accept that argument. In fact I'd argue we ought encourage >>> that devices not have globally unique long-term identifiers at >>> all unless there is a real need for those, and unless we >>> understand how to control their (ab)use. >> >> By "identifier" do we necessarily mean "network identifier"? It seems to >> me that it is useful to have a unique long-term identifier for every >> device, based on its public key. Whether you can obtain a network >> connection to that device based on such information is another story. > > It is undoubtedly useful to have long term stable identifiers of > various kinds. I'd include key IDs and public keys as such. > > Turns out that it's also fairly universally privacy unfriendly > as people will abuse such identifiers for good and bad reasons. I'd be curious to learn more about the attack surface here. But I realize this is probably not a CORE WG topic; is there a better venue? Peter From nobody Wed Oct 5 16:33:43 2016 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 AD3551294D2 for ; Wed, 5 Oct 2016 16:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.297 X-Spam-Level: X-Spam-Status: No, score=-7.297 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_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 iEuSG0uP0Hjp for ; Wed, 5 Oct 2016 16:33:40 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32556129424 for ; Wed, 5 Oct 2016 16:33:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 740A7BE73; Thu, 6 Oct 2016 00:33:38 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oUePorAsMf5; Thu, 6 Oct 2016 00:33:37 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E23D5BE5C; Thu, 6 Oct 2016 00:33:36 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1475710417; bh=nGc9RxNsq4QCvxzTClLGzKEm7f/A0qwE+nh7HwGYKhs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=sIF6wbNz0JisImjT0UfcLz41mLNxR+Gmv4utHrZtk9WNwuHl3ksIMHpkyP2jYSe51 Oj98J6FA5DJsiMjiOPTOJSFSb1wGcWmwwuVDafxZGV0Dve9qH9r4sczLJ8nPoQQgyl krWy8E6OcVXKF3IgV0mtWPvnBhccspDeMkTl3x6k= To: Peter Saint-Andre - Filament , Dave Thaler , "core@ietf.org" References: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> <3febad96-3793-69a6-b78f-1994c0f9708d@itm.uni-luebeck.de> <7392d335-d0e7-cf83-24a7-61d40f37c57c@cs.tcd.ie> <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <0ffa9ff7-08b5-bc30-61ae-0f41e4bc6d1f@cs.tcd.ie> Date: Thu, 6 Oct 2016 00:33:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020205060802000709010102" Archived-At: Subject: Re: [core] Implications of IP address / port changes for CoAP & Co X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 05 Oct 2016 23:33:42 -0000 This is a cryptographically signed message in MIME format. --------------ms020205060802000709010102 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/10/16 00:30, Peter Saint-Andre - Filament wrote: > I'd be curious to learn more about the attack surface here. But I > realize this is probably not a CORE WG topic; is there a better venue? Two IETF list options I guess: - perpass list if for a general discussion of privacy unfriendliness of identifiers in protocols and we can see where it goes from there - saag list if for a more IETF-process oriented discussion of how to handle (new) identifiers in IETF protocols (I suggest this because we're in the process of revising RFC3552 (the guidelines on what to put in security considerations) so guidance on this topic would be relevant to suggest as part of that Feel free to kick off a thread on either Cheers, S. --------------ms020205060802000709010102 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMDUy MzMzMzdaMC8GCSqGSIb3DQEJBDEiBCBuRFtPe9vsdnD+bH/rMHImnSVvyhady4HA95xeRxf9 gjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAvGG1tfIbxHhB15aVcKaSluiOcB6lyY9teZyEQ3hzoQR0wUq4hSVo6 ww7PGrP+AbOcMAalNC1NxCmq5g8418TE5Uv96duILzk782CSYzYo3D416ciL21sbqCpOS6RZ g7qLzMm1iVQp6r1P1CDChoiTIDhrlkKaBHSH9+vwE1DAUS0VrpLF88Ae7+0+G1aWIJuiVV4Y B43DGcWfNDUVvao18ehHyinaV23WNdolGERxTFQJF1zuI4JUdnVcsj53TGVkEJlQPNIKk3LH W6/26QNU8ASdKpq7cAD4qpUHUB1842uwbAX+33ONQ8dwFmY3c+dqvxZmWLvHUtgm226LGgVe AAAAAAAA --------------ms020205060802000709010102-- From nobody Wed Oct 5 16:37:49 2016 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 81293129442 for ; Wed, 5 Oct 2016 16:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=filament-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 0AW-O6uhuEy2 for ; Wed, 5 Oct 2016 16:37:46 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 28913129424 for ; Wed, 5 Oct 2016 16:37:46 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id j69so10800500itb.0 for ; Wed, 05 Oct 2016 16:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=5FiaMtZd1FRrr1G4392GsMFc2b5gL8Z8Ys0vPQTwH+8=; b=s9SvtkuNmng/k+df3jmft62V+IvmQVwC1s6nuuyP08PwRxvVTJKA5CXCNRzID0mj3g 5xMKp89xgvwijwv1tyWvslgyBu0UCZg7K1uLIyIcFWW3rcfi+JFR5nTLu9YDeBReQV76 woG+VkYukNDF7qlMAzaOgDnFP+ssluJwllnl6WcCYTN6RtXnfnMlvGuydgzLF5Mo5TPI Pt0UGk2uncnzQ69YJkPNncMNjCwbS92ETmjQQk82gaEcgwqpe850+fm9vK6br75f8c2C CieLVBF93zumxrhrtJ17xiIAFSDA0WsHHvJEoFaJTxXuafc7MkdzjSJ8OU1s0WoRZSEl IS+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=5FiaMtZd1FRrr1G4392GsMFc2b5gL8Z8Ys0vPQTwH+8=; b=er5sOA3W8T/2JdLa17iUB4gZ1TY8SbbsEph/TIkEjz+w9UYafo28+20WhKCyRqqfXe w9CP5xyHnKW+sGM8Eh5+8EfoHnWYZYbvrPinJoOltBOTl0S7Niwz921Y1dV3VQOrdMj9 tglG3gJ+MCJffgoMYxcW5fGj0Vlbx2GxgEkhQfG2gIfJIR3OOY+GG22v9B3BjKyDAp1M OL6aKK1YlajMe58U7IhlMacje3D6Y7zViG5uA80qnJ9hMBGLY31tHxqiy3MPv4NU6jov ews9T1fN2iQ+o18SSUcYopHcwPdKMCvKufb73ghBHM/kXJwLU/X2j7z/ZGm1l2kDzcoX 6l8w== X-Gm-Message-State: AA6/9Rl2XzYORWgFQS7hmnvsx57OH7IKk6vj8P+4QDrA+RBCFo1jzYUboARQ7WaXRpnpDg== X-Received: by 10.36.47.76 with SMTP id j73mr12014678itj.27.1475710665586; Wed, 05 Oct 2016 16:37:45 -0700 (PDT) Received: from aither.local ([76.25.4.24]) by smtp.gmail.com with ESMTPSA id n191sm1454941itg.17.2016.10.05.16.37.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Oct 2016 16:37:45 -0700 (PDT) To: Stephen Farrell , Dave Thaler , "core@ietf.org" References: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> <3febad96-3793-69a6-b78f-1994c0f9708d@itm.uni-luebeck.de> <7392d335-d0e7-cf83-24a7-61d40f37c57c@cs.tcd.ie> <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <0ffa9ff7-08b5-bc30-61ae-0f41e4bc6d1f@cs.tcd.ie> From: Peter Saint-Andre - Filament Message-ID: <57565051-2e6f-80d9-a031-2ad494cf3386@filament.com> Date: Wed, 5 Oct 2016 17:37:43 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <0ffa9ff7-08b5-bc30-61ae-0f41e4bc6d1f@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [core] Implications of IP address / port changes for CoAP & Co X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 05 Oct 2016 23:37:47 -0000 On 10/5/16 5:33 PM, Stephen Farrell wrote: > > > On 06/10/16 00:30, Peter Saint-Andre - Filament wrote: >> I'd be curious to learn more about the attack surface here. But I >> realize this is probably not a CORE WG topic; is there a better venue? > > Two IETF list options I guess: > > - perpass list if for a general discussion of privacy unfriendliness > of identifiers in protocols and we can see where it goes from there > > - saag list if for a more IETF-process oriented discussion of how to > handle (new) identifiers in IETF protocols (I suggest this because > we're in the process of revising RFC3552 (the guidelines on what to > put in security considerations) so guidance on this topic would be > relevant to suggest as part of that > > Feel free to kick off a thread on either The perpass list sounds best. See you there! ;-) Peter -- Peter Saint-Andre https://filament.com/ From nobody Wed Oct 5 16:59:07 2016 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 CD6061294F2 for ; Wed, 5 Oct 2016 16:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=filament-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 aMY-C_5hc8gU for ; Wed, 5 Oct 2016 16:59:04 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 3D46D12945D for ; Wed, 5 Oct 2016 16:59:04 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id o19so11275824ito.1 for ; Wed, 05 Oct 2016 16:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=xZPOMq3h/xsM8D26ewDiEXCh4qC0fA3ZILGKoE5DgcY=; b=qurK21TPlsu495f3ZfTOzluqCcsZw2usX9MA0L7g9xT1twAgKPbXHtnnY2CwJZ5wNk q84Nu7kVSSseRgEh2lGIDmQfZqmZzlfdLFTu7oRBfi0MtibC9EHs1MraVL0hYaHct3Q3 6AHrXbncfTWVNdCQrmu+p1fUdXcL3z7FaqC+EX2ppFH/AlexNGEIyMi55NifRd7uKvpZ aLchN0zAH5bP9TTyUmHey1Rd+3PipbsCGvn2rVOdd3gdfXJQ7lP3nsH4dCQT1FFFoSjp /FehfAZbXzlB3odH5UZtG9MqUj9/u7jg6hwBLl52QuqPcOpwPuBCF+rViHGYE7V8k1pG 6K1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=xZPOMq3h/xsM8D26ewDiEXCh4qC0fA3ZILGKoE5DgcY=; b=V32sfX67LGgEcAAebmBxBCdDxZfPMELaZO7DbvYL5EGkFHtHcJCP5aAx+Pe7TkZLm1 0zvjAUidN0PQ9bGZzblZ12F09OL/PdTB8kMn6phbhd73dcT6rvRfNaat6KfHAxxuhFLa 4SbHMxvBB1i3zTWmlvN9QsJrzaJNXbHMITEaj+Qjqzec98VMkFe45T9ENtBqH8iFE/QF eqBUYsUQqG8yvOf5WyvsJIGbeNRZkbFaOfASG/ZJTAKbLqbSECzuZjdLqLXycnKuxEIv /5lUPqxHE0ObsidPkC8fh1rVvb3s2974iCm8u5xnolOMuuSaIBpVhm+P0l2UOMw16Ave +OQQ== X-Gm-Message-State: AA6/9RlAMJ1ToWKCODLWbyRCrUH8BYmKKmeQGXDLwoN42kYjkg4amFImO+6z9fV6kD7U2A== X-Received: by 10.36.39.67 with SMTP id g64mr31431321ita.93.1475711943424; Wed, 05 Oct 2016 16:59:03 -0700 (PDT) Received: from aither.local ([76.25.4.24]) by smtp.gmail.com with ESMTPSA id n6sm4587577ioe.7.2016.10.05.16.59.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Oct 2016 16:59:02 -0700 (PDT) To: Stephen Farrell , Dave Thaler , "core@ietf.org" References: <4a70a2b1-b998-b0c1-c42a-2ceb634b9945@gmx.net> <3febad96-3793-69a6-b78f-1994c0f9708d@itm.uni-luebeck.de> <7392d335-d0e7-cf83-24a7-61d40f37c57c@cs.tcd.ie> <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <0ffa9ff7-08b5-bc30-61ae-0f41e4bc6d1f@cs.tcd.ie> <57565051-2e6f-80d9-a031-2ad494cf3386@filament.com> From: Peter Saint-Andre - Filament Message-ID: <206ca7fb-6688-c943-23c7-e7790dbb9f2f@filament.com> Date: Wed, 5 Oct 2016 17:59:02 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <57565051-2e6f-80d9-a031-2ad494cf3386@filament.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [core] Implications of IP address / port changes for CoAP & Co X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 05 Oct 2016 23:59:06 -0000 On 10/5/16 5:37 PM, Peter Saint-Andre - Filament wrote: > On 10/5/16 5:33 PM, Stephen Farrell wrote: >> >> >> On 06/10/16 00:30, Peter Saint-Andre - Filament wrote: >>> I'd be curious to learn more about the attack surface here. But I >>> realize this is probably not a CORE WG topic; is there a better venue? >> >> Two IETF list options I guess: >> >> - perpass list if for a general discussion of privacy unfriendliness >> of identifiers in protocols and we can see where it goes from there >> >> - saag list if for a more IETF-process oriented discussion of how to >> handle (new) identifiers in IETF protocols (I suggest this because >> we're in the process of revising RFC3552 (the guidelines on what to >> put in security considerations) so guidance on this topic would be >> relevant to suggest as part of that >> >> Feel free to kick off a thread on either > > The perpass list sounds best. See you there! ;-) Posted: https://mailarchive.ietf.org/arch/msg/perpass/i3djUQopTtC35LEHSDOpAtY22Jg Peter -- Peter Saint-Andre https://filament.com/ From nobody Thu Oct 6 14:40:14 2016 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 1F83E129485 for ; Thu, 6 Oct 2016 14:40:12 -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=unavailable 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 UdSxOBNvpbm9 for ; Thu, 6 Oct 2016 14:40:10 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0126.outbound.protection.outlook.com [104.47.33.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 8B1BA1297B4 for ; Thu, 6 Oct 2016 14:34:21 -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=/PIBOPrm8zvyOfsKi4Ac5Zw8YkUP2126ELkG2UQFSw8=; b=mHl9VvubFnuxZJfTZgkW4Ut4AMe076CPVGdzx1fZ6T8quMK7FKNuAVly6lNfmOQCmtLMPiJ+NMVFcFg0IoCbVEFJDHcKDtLFBRunZBHNQ0HaZCzRA5/V4tI82bRXxA7f3CxZIS7dxqdjhyGaXsIVATXJCArDRBaar2HI2VVa37c= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by MWHPR03MB2447.namprd03.prod.outlook.com (10.169.200.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Thu, 6 Oct 2016 21:34:19 +0000 Received: from CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) by CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) with mapi id 15.01.0659.015; Thu, 6 Oct 2016 21:34:19 +0000 From: Brian Raymor To: Carsten Bormann Thread-Topic: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt Thread-Index: AQHR/kux0vvo8uYlLUa/o5fnHPLus6BYnTxwgBQ95TCAChwvAIAMJygggBZ40QCAApds0A== Date: Thu, 6 Oct 2016 21:34:19 +0000 Message-ID: References: <147207291891.26600.11584792951825869042.idtracker@ietfa.amsl.com> <114995FB6D604B92854BDA82FEC26123@WeiGengyuPC> <57F4908E.6040905@tzi.org> In-Reply-To: <57F4908E.6040905@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ms-office365-filtering-correlation-id: 028b3e82-021f-4dfb-9936-08d3ee308801 x-microsoft-exchange-diagnostics: 1; MWHPR03MB2447; 7:7ETPi+6CFqgrpGBkwjuxImEZRKDNa1ydo2TwVzYrZyIAcMqMYApBPMwK0Q6znm83usoyjdFib9fKkXAGPuEgzB+nfP2p6Lmtxef0fVEqMxlV8a3vIx7QUeC28bzrGdd+Vvme3+cv5zO+W+Wly+9+lpsBXb2rZNhnwfGUPLQkkXaiAvJZjSBQzikfX+AfKg0EjUuq4wBZHrDl8QAmtwqZVRCbInGvRjl/kWU+LCIAfESL9qXnqr17opGRrdz5ALPMo4Fsdr6Ylj4lyZfElYdLu4w5tkCfXsySkz3xyH/WubeJsa/GpLgv22c/AAgkUAvvpVTOOgLzv3prlrK3Kq1hPg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR03MB2447; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:MWHPR03MB2447; BCL:0; PCL:0; RULEID:; SRVR:MWHPR03MB2447; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(107886002)(50986999)(54356999)(76176999)(6116002)(102836003)(3846002)(76576001)(3660700001)(3280700002)(189998001)(86612001)(97736004)(230783001)(86362001)(9686002)(10400500002)(5005710100001)(10290500002)(77096005)(99286002)(8936002)(105586002)(10090500001)(2950100002)(6916009)(106116001)(106356001)(2900100001)(101416001)(68736007)(586003)(8990500004)(11100500001)(122556002)(74316002)(66066001)(93886004)(87936001)(305945005)(7736002)(5002640100001)(33656002)(7846002)(110136003)(4001430100002)(81166006)(81156014)(4326007)(92566002)(5660300001)(2906002)(7696004)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR03MB2447; H:CY1PR03MB2380.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) 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: 06 Oct 2016 21:34:19.4426 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR03MB2447 Archived-At: Cc: Hannes Tschofenig , "core@ietf.org" , Juan Perez Subject: Re: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 06 Oct 2016 21:40:12 -0000 DQo+IFVudGlsIGl0IHJlY2VpdmVzIGFuIGluZGljYXRpb24gZm9yIGFuIGluY3JlYXNlZCBtZXNz YWdlIHNpemUgY2FwYWJpbGl0eQ0KPiBmcm9tIHRoZSBvdGhlciBzaWRlLCB0aGUgbGltaXRhdGlv bnMgb2YgU2VjdGlvbiA0LjYgb2YgUkZDIDcyNTIgY29udGludWUNCj4gdG8gYXBwbHkgdG8gbWVz c2FnZXMgc2VudCBieSBhbnkgb25lIHNpZGUuIA0KDQpXZSd2ZSBhZGRyZXNzZWQgdGhpcyBkaXJl Y3RseSBpbiBjb2FwLXRjcC10bHMgW3NlY3Rpb24gNC4zLjJdIHdpdGggdGhlIHVzZQ0Kb2YgYmFz ZSB2YWx1ZSBmb3IgdGhlIE1heC1NZXNzYWdlLVNpemUgQ2FwYWJpbGl0eSBPcHRpb246DQoNCiAg IEFzIHBlciBTZWN0aW9uIDQuNiBvZiBbUkZDNzI1Ml0sIHRoZSBiYXNlIHZhbHVlIChhbmQgdGhl IHZhbHVlIHVzZWQNCiAgIHdoZW4gdGhpcyBvcHRpb24gaXMgbm90IGltcGxlbWVudGVkKSBpcyAx MTUyLg0KDQo+IChOb3csIHRoZSBtZXNzYWdlIHJlY2VpdmVyIG1pZ2h0IHdhbnQgdG8gZ28gKmJl bG93KiBTZWN0aW9uIDQuNi4NCj4gSWYgdGhhdCBpcyBhIHVzZSBjYXNlIHdlIHdhbnQgdG8gc3Vw cG9ydCwgdGhlIGFyZ3VtZW50IGRvZXMgYXBwbHkuICBJcyBpdD8pDQoNClRoaXMgaXMgdGhlIHBv dGVudGlhbCBjYXNlLiBUaGUgc2VuZGVyIGlzIGV4Y2VlZGluZyB0aGUgcmVjZWl2ZXIncyBtYXhp bXVtDQptZXNzYWdlIHNpemUuDQoNCg0KDQo= From nobody Fri Oct 7 11:14:05 2016 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 6BD11128B44; Fri, 7 Oct 2016 11:14:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147586404443.8866.17789548151047641563.idtracker@ietfa.amsl.com> Date: Fri, 07 Oct 2016 11:14:04 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-senml-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 18:14:04 -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 Markup Language (SenML) Authors : Cullen Jennings Zach Shelby Jari Arkko Ari Keranen Carsten Bormann Filename : draft-ietf-core-senml-03.txt Pages : 36 Date : 2016-10-07 Abstract: This specification defines media types for representing simple sensor measurements and device parameters in the Sensor Markup Language (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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-senml-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-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 Fri Oct 7 13:54:01 2016 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 CFD6C12941E for ; Fri, 7 Oct 2016 13:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 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 Gj8KxcLnzDGP for ; Fri, 7 Oct 2016 13:53:58 -0700 (PDT) Received: from smtp157.dfw.emailsrvr.com (smtp157.dfw.emailsrvr.com [67.192.241.157]) (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 675F31293EB for ; Fri, 7 Oct 2016 13:53:58 -0700 (PDT) Received: from smtp20.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp20.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id A4EA6E0364; Fri, 7 Oct 2016 16:53:57 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp20.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 57A72E0404; Fri, 7 Oct 2016 16:53:57 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.90.15] ([UNAVAILABLE]. [128.107.241.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.7); Fri, 07 Oct 2016 16:53:57 -0400 From: Cullen Jennings Content-Type: multipart/alternative; boundary="Apple-Mail=_C2E35033-74AD-4246-9251-7C27724FF2F0" Date: Fri, 7 Oct 2016 13:53:56 -0700 Message-Id: To: media-types@iana.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Core WG mailing list Subject: [core] Request review for application/senml+json and related types X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 07 Oct 2016 20:54:00 -0000 --Apple-Mail=_C2E35033-74AD-4246-9251-7C27724FF2F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I would like to request review for a handful of related mime types = specified in=20 https://tools.ietf.org/html/draft-ietf-core-senml-03 = Thank you, Cullen --Apple-Mail=_C2E35033-74AD-4246-9251-7C27724FF2F0 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

I would like to request review for a handful of related mime types specified in 


Thank you, Cullen


--Apple-Mail=_C2E35033-74AD-4246-9251-7C27724FF2F0-- From nobody Fri Oct 7 18:44:05 2016 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 866F71294C2 for ; Fri, 7 Oct 2016 18:44:03 -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, HTML_MESSAGE=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 8uKhjikKglgo for ; Fri, 7 Oct 2016 18:44:01 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 6B73A129424 for ; Fri, 7 Oct 2016 18:44:00 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id i202so63317502ioi.2 for ; Fri, 07 Oct 2016 18:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fKyo2qFCf6FTTQa+k7O2EacmEwz+KKKgIFvGQ+f3GVU=; b=RKNM4FPA3M9ePCqr0EE8yG2QcOPLY7hU/DGv7mCo/Ztzv+KUY1Bs37haclqtUDiFz0 4RmeAWVpGTjGEvS3bLOF11pST7orMKCjTPjSh+xruw3dP2wiw0iNdpUW2OwOc1gfgB/7 7PFMBn8cCD/U44urbpGAK23YFmr6gawEoOtJPYwndrAoC4I8wtgrQqZNp3UNZ5dtRz22 lnhQCXMp2VFoG4laqW/2zDCkUMdVQcbwCOOYEpvWz/wxDdgBShRsLDAePE7etNjqm49L oDBUPz0SKV2iU+qfR3WFLsktamp9aipe4v0ebsDq9y3Mig+NnbrQcWr595IvmsZ7hXwu ydCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fKyo2qFCf6FTTQa+k7O2EacmEwz+KKKgIFvGQ+f3GVU=; b=G1uuVRcykM9PaSSbLriEj5KJOkMqWLYX5e++PYRaH5JWazOme5NyIh9BkFR1qNIO3W DFHh7CZfMgtOSEPFei5cxzFMJZMW63aMUmGrx2rsH9aaWEEjjyQ3KHyEBElI5mGnRTh3 n2kczx1knbpdN081v7BCBaie9eZxwT6KO1hPRF1YZADDguh8lcGtSBCNxwXHcUPoQiTA DFFIxxYgsT9Old3N7LqXD2jeVLgt3SFGWczHmKDlIX6ZliWRRaWoIuo5tkW68HNQrGk9 RDeiB879TCCDYc9AzrzKjznBQ1a5H2FDWSsCpRRIGtmDz/TycaXBVBIzdk8TDXcSJhzC TB2A== X-Gm-Message-State: AA6/9RnuBVKrWq7RcgXR8IrPUDvQRalU7m0CEHx+EbwKeHKGFZLpoPybv/LC/4EABcaVYUILt8duKtHdSzeSFw== X-Received: by 10.107.39.66 with SMTP id n63mr9291583ion.180.1475891039969; Fri, 07 Oct 2016 18:43:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.147.6 with HTTP; Fri, 7 Oct 2016 18:43:39 -0700 (PDT) In-Reply-To: References: From: Ira McDonald Date: Fri, 7 Oct 2016 21:43:39 -0400 Message-ID: To: Cullen Jennings , Ira McDonald Content-Type: multipart/alternative; boundary=001a114076502a2556053e50a95b Archived-At: Cc: media-types@iana.org, Core WG mailing list Subject: Re: [core] [media-types] Request review for application/senml+json and related types X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Oct 2016 01:44:03 -0000 --001a114076502a2556053e50a95b Content-Type: text/plain; charset=UTF-8 Hi Cullen, Usual response - please send the actual registration templates in plaintext in an email to the Media Types list. Then the edits needed (there always are some) are clearly documented on the mailing list. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Fri, Oct 7, 2016 at 4:53 PM, Cullen Jennings wrote: > > I would like to request review for a handful of related mime types > specified in > > https://tools.ietf.org/html/draft-ietf-core-senml-03 > > Thank you, Cullen > > > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types > > --001a114076502a2556053e50a95b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Cullen,

Usua= l response - please send the actual registration templates
in pla= intext in an email to the Media Types list.=C2=A0 Then the edits
n= eeded (there always are some) are clearly documented on
the mailin= g list.

Cheers,
- Ira


Ira McDonald = (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solution= s WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO = Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protoco= l WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music /= High North Inc
http://sites.google.com/sit= e/blueroofmusic
http://sites.google.com/= site/highnorthinc
mailto: blueroofmusic@gmail.com
Jan-April: 579 Park Place= =C2=A0 Saline, MI=C2=A0 48176=C2=A0 734-944-0094
May-Dec: PO Box 221=C2= =A0 Grand Marais, MI 49839=C2=A0 906-494-2434


On Fri, Oct 7, 2016 at 4:53 PM, Cullen Jenni= ngs <fluffy@iii.ca> wrote:

I would like to reques= t review for a handful of related mime types specified in=C2=A0
<= br>

Thank you, Cullen



_______________________________________________<= br> media-types mailing list
media-types@ietf.org
https://www.ietf.org/mailman/listinfo/media-ty= pes


--001a114076502a2556053e50a95b-- From nobody Sat Oct 8 11:32:54 2016 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 829981295F1 for ; Sat, 8 Oct 2016 11:32:53 -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, RCVD_IN_MSPIKE_H2=-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 hihg_nUJjaKY for ; Sat, 8 Oct 2016 11:32:50 -0700 (PDT) Received: from smtp77.iad3a.emailsrvr.com (smtp77.iad3a.emailsrvr.com [173.203.187.77]) (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 A6351129503 for ; Sat, 8 Oct 2016 11:32:50 -0700 (PDT) Received: from smtp34.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp34.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C7D9924C1B; Sat, 8 Oct 2016 14:32:47 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp34.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 127C924BA1; Sat, 8 Oct 2016 14:32:46 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.57.2] ([UNAVAILABLE]. [128.107.241.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.7); Sat, 08 Oct 2016 14:32:47 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_9D3CE170-2B11-4EB0-8340-C3F94C36981B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Sat, 8 Oct 2016 11:32:45 -0700 Message-Id: <247A9C78-69D5-4725-A670-F556A2223F66@iii.ca> References: To: Ira McDonald X-Mailer: Apple Mail (2.3124) Archived-At: Cc: media-types@iana.org, Core WG mailing list Subject: Re: [core] [media-types] Request review for application/senml+json and related types X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Oct 2016 18:32:53 -0000 --Apple-Mail=_9D3CE170-2B11-4EB0-8340-C3F94C36981B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sure - here it is=20 11.3.1. senml+json Media Type Registration Type name: application Subtype name: senml+json and sensml+json Required parameters: none Optional parameters: none Encoding considerations: Must be encoded as using a subset of the encoding allowed in [RFC7159]. See RFC-AAAA for details. This simplifies implementation of very simple system and does not impose any significant limitations as all this data is meant for machine to machine communications and is not meant to be human readable. Security considerations: Sensor data can contain a wide range of information ranging from information that is very public, such the outside temperature in a given city, to very private information that requires integrity and confidentiality protection, such as patient health information. This format does not provide any security and instead relies on the transport protocol that carries it to provide security. Given applications need to look at the overall context of how this media type will be used to decide if the security is adequate. Interoperability considerations: Applications should ignore any JSON key value pairs that they do not understand. This allows backwards compatibility extensions to this specification. The "bver" field can be used to ensure the receiver supports a minimal level of functionality needed by the creator of the JSON object. Published specification: RFC-AAAA Applications that use this media type: The type is used by systems that report e.g., electrical power usage and environmental information such as temperature and humidity. It can be used for a wide range of sensor reporting systems. Additional information: Magic number(s): none File extension(s): senml and sensml Macintosh file type code(s): none Person & email address to contact for further information: Cullen Jennings Intended usage: COMMON Restrictions on usage: None Author: Cullen Jennings Change controller: IESG 11.3.2. senml+cbor Media Type Registration Type name: application Subtype name: senml+cbor and sensml+cbor Required parameters: none Optional parameters: none Encoding considerations: TBD Security considerations: See Section 11.3.1 Interoperability considerations: TBD Published specification: RFC-AAAA Applications that use this media type: See Section 11.3.1 Additional information: Magic number(s): none File extension(s): senmlc and sensmlc Macintosh file type code(s): none Person & email address to contact for further information: Cullen Jennings Intended usage: COMMON Restrictions on usage: None Author: Cullen Jennings Change controller: IESG 11.3.3. senml+xml Media Type Registration Type name: application Subtype name: senml+xml and sensml+xml Required parameters: none Optional parameters: none Encoding considerations: TBD Security considerations: See Section 11.3.1 Interoperability considerations: TBD Published specification: RFC-AAAA Applications that use this media type: See Section 11.3.1 Additional information: Magic number(s): none File extension(s): senmlx and sensmlx Macintosh file type code(s): none Person & email address to contact for further information: Cullen Jennings Intended usage: COMMON Restrictions on usage: None Author: Cullen Jennings Change controller: IESG 11.3.4. senml+exi Media Type Registration Type name: application Subtype name: senml+exi and sensml+exi Required parameters: none Optional parameters: none Encoding considerations: TBD Security considerations: TBD Interoperability considerations: TBD Published specification: RFC-AAAA Applications that use this media type: See Section 11.3.1 Additional information: Magic number(s): none File extension(s): senmle and sensmle Macintosh file type code(s): none Person & email address to contact for further information: Cullen Jennings Intended usage: COMMON Restrictions on usage: None Author: Cullen Jennings Change controller: IESG > On Oct 7, 2016, at 6:43 PM, Ira McDonald = wrote: >=20 > Hi Cullen, >=20 > Usual response - please send the actual registration templates=20 > in plaintext in an email to the Media Types list. Then the edits > needed (there always are some) are clearly documented on > the mailing list. >=20 > Cheers, > - Ira >=20 >=20 > Ira McDonald (Musician / Software Architect) > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music / High North Inc > http://sites.google.com/site/blueroofmusic = > http://sites.google.com/site/highnorthinc = > mailto: blueroofmusic@gmail.com > Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 > May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434 >=20 >=20 > On Fri, Oct 7, 2016 at 4:53 PM, Cullen Jennings > wrote: >=20 > I would like to request review for a handful of related mime types = specified in=20 >=20 > https://tools.ietf.org/html/draft-ietf-core-senml-03 = >=20 > Thank you, Cullen >=20 >=20 >=20 > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types = >=20 >=20 --Apple-Mail=_9D3CE170-2B11-4EB0-8340-C3F94C36981B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Sure - here it = is 


11.3.1.  senml+json = Media Type Registration

   Type name: application

   Subtype name: senml+json = and sensml+json

   Required parameters: none
   Optional parameters: = none

  =  Encoding considerations: Must be encoded as using a subset of = the
   encoding allowed in [RFC7159]. =  See RFC-AAAA for details.  This
  =  simplifies implementation of very simple system and does not = impose
   any significant limitations as = all this data is meant for machine to
  =  machine communications and is not meant to be human = readable.

 =  Security considerations: Sensor data can contain a wide range = of
   information ranging from = information that is very public, such the
  =  outside temperature in a given city, to very private information = that
   requires integrity and = confidentiality protection, such as patient
  =  health information.  This format does not provide any = security and
   instead relies on the = transport protocol that carries it to provide
  =  security.  Given applications need to look at the overall = context of
   how this media type will be = used to decide if the security is
  =  adequate.

   Interoperability considerations: Applications = should ignore any JSON
   key value pairs = that they do not understand.  This allows backwards
   compatibility extensions to this specification. =  The "bver" field can
   be used to = ensure the receiver supports a minimal level of
   functionality needed by the creator of the JSON = object.

  =  Published specification: RFC-AAAA

   Applications that use this = media type: The type is used by systems
  =  that report e.g., electrical power usage and = environmental
   information such as = temperature and humidity.  It can be used for a
   wide range of sensor reporting = systems.

  =  Additional information:

   Magic number(s): = none

  =  File extension(s): senml and sensml

   Macintosh file type = code(s): none

   Person & email address to contact for = further information: Cullen
   Jennings = <fluffy@iii.ca>

   Intended usage: = COMMON

  =  Restrictions on usage: None

   Author: Cullen Jennings = <fluffy@iii.ca>

   Change controller: = IESG


11.3.2.  senml+cbor Media Type = Registration

   Type name: application

   Subtype name: senml+cbor = and sensml+cbor

   Required parameters: none
   Optional parameters: = none

  =  Encoding considerations: TBD

   Security considerations: = See Section 11.3.1

   Interoperability considerations: TBD

   Published = specification: RFC-AAAA

   Applications that use this media type: See = Section 11.3.1

   Additional information:

   Magic number(s): = none

  =  File extension(s): senmlc and sensmlc

   Macintosh file type = code(s): none

   Person & email address to contact for = further information: Cullen
   Jennings = <fluffy@iii.ca>

   Intended usage: = COMMON

  =  Restrictions on usage: None

   Author: Cullen Jennings = <fluffy@iii.ca>

   Change controller: = IESG

11.3.3. =  senml+xml Media Type Registration

   Type name: = application

   Subtype name: senml+xml and sensml+xml

   Required = parameters: none

   Optional parameters: none
   Encoding considerations: = TBD

  =  Security considerations: See Section 11.3.1
   Interoperability = considerations: TBD

   Published specification: RFC-AAAA

  =  Applications that use this media type: See Section = 11.3.1

  =  Additional information:

   Magic number(s): = none

  =  File extension(s): senmlx and sensmlx

   Macintosh file type = code(s): none

   Person & email address to contact for = further information: Cullen
   Jennings = <fluffy@iii.ca>

   Intended usage: = COMMON

  =  Restrictions on usage: None

   Author: Cullen Jennings = <fluffy@iii.ca>

   Change controller: = IESG

11.3.4. =  senml+exi Media Type Registration

   Type name: = application

   Subtype name: senml+exi and sensml+exi

   Required = parameters: none

   Optional parameters: none
   Encoding considerations: = TBD

  =  Security considerations: TBD

   Interoperability = considerations: TBD

   Published specification: RFC-AAAA

  =  Applications that use this media type: See Section = 11.3.1

  =  Additional information:

   Magic number(s): = none

  =  File extension(s): senmle and sensmle

   Macintosh file type = code(s): none

   Person & email address to contact for = further information: Cullen
   Jennings = <fluffy@iii.ca>

   Intended usage: = COMMON

  =  Restrictions on usage: None

   Author: Cullen Jennings = <fluffy@iii.ca>

   Change controller: = IESG




On Oct 7, 2016, at 6:43 PM, Ira McDonald <blueroofmusic@gmail.com> wrote:

Hi Cullen,

Usual response - please send the actual registration = templates
in plaintext in an email to the Media = Types list.  Then the edits
needed (there = always are some) are clearly documented on
the = mailing list.

Cheers,
- Ira


Ira = McDonald (Musician / Software Architect)
Co-Chair - TCG = Trusted Mobility Solutions WG
Chair - Linux Foundation = Open Printing WG
Secretary - IEEE-ISTO Printer Working = Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol = WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Jan-April: 579 Park Place  Saline, MI  48176  = 734-944-0094
May-Dec: PO Box 221  Grand Marais, MI = 49839  906-494-2434


On Fri, Oct 7, 2016 at 4:53 = PM, Cullen Jennings <fluffy@iii.ca> wrote:

I would = like to request review for a handful of related mime types specified = in 

https://tools.ietf.org/html/draft-ietf-core-senml-03

Thank you, Cullen



_______________________________________________
media-types mailing list
media-types@ietf.org
https://www.ietf.org/mailman/listinfo/media-types



= --Apple-Mail=_9D3CE170-2B11-4EB0-8340-C3F94C36981B-- From nobody Sat Oct 8 14:15:22 2016 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 E21131293F0 for ; Sat, 8 Oct 2016 14:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.997 X-Spam-Level: X-Spam-Status: No, score=-4.997 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=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 e-3kj2HN0kC9 for ; Sat, 8 Oct 2016 14:15:18 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id BFF061293EE for ; Sat, 8 Oct 2016 14:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1475961317; d=isode.com; s=june2016; i=@isode.com; bh=4DXB634cx5GfhPEifBTxajzwskzeHMEfjq6YR9gXNLs=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=lIuOok+ZucxfE1TPGrKR9PFwtgydh+QEnX4wHztJFB7zLDlsUCmnln/Rv6jtp9vDpha0GN 3Z7mEVKXvXdmyT94cmE0bhkjespNpb1ApstYfeWos0iyJXRMADOQsbeMNxTb7kUMwqJ69M h40882E2PfEgaNAxF8ehsvd3Fm0NGK0=; Received: from [10.8.219.244] ((unknown) [148.252.128.246]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 8 Oct 2016 22:15:17 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: <247A9C78-69D5-4725-A670-F556A2223F66@iii.ca> Date: Sat, 8 Oct 2016 22:18:54 +0100 Message-Id: <796B1579-635A-4D08-83BE-77B771D6D803@isode.com> References: <247A9C78-69D5-4725-A670-F556A2223F66@iii.ca> To: Cullen Jennings MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: Ira McDonald , media-types@iana.org, Core WG mailing list Subject: Re: [core] [media-types] Request review for application/senml+json and related types X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 08 Oct 2016 21:15:20 -0000 Hi Cullen, There are several TBD in your registrations that need to be fixed first. From nobody Sun Oct 9 05:23:28 2016 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 AB94E129449; Sun, 9 Oct 2016 05:23:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147601580669.30500.836188804039906291.idtracker@ietfa.amsl.com> Date: Sun, 09 Oct 2016 05:23:26 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-etch-03.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 12:23:27 -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 : Patch and Fetch Methods for Constrained Application Protocol (CoAP) Authors : Peter van der Stok Carsten Bormann Anuj Sehgal Filename : draft-ietf-core-etch-03.txt Pages : 18 Date : 2016-10-09 Abstract: The methods defined in RFC 7252 for the Constrained Application Protocol (CoAP) only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where a resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP will need to perform partial resource accesses. This specification defines the new CoAP methods, FETCH, PATCH and iPATCH, which are used to access and update parts of a resource. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-etch/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-etch-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-etch-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 Mon Oct 10 03:57:41 2016 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 B1A1F129501 for ; Mon, 10 Oct 2016 03:57:40 -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 6XKuCp_Vug1T for ; Mon, 10 Oct 2016 03:57:39 -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 CCF511293F4 for ; Mon, 10 Oct 2016 03:57: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 [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u9AAvZ5P022444 for ; Mon, 10 Oct 2016 12:57:35 +0200 (CEST) Received: from eduroam-pool6-0351.wlan.uni-bremen.de (eduroam-pool6-0351.wlan.uni-bremen.de [134.102.25.95]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3ssxsq5BwBz2jqs; Mon, 10 Oct 2016 12:57:35 +0200 (CEST) Message-ID: <57FB7451.6010401@tzi.org> Date: Mon, 10 Oct 2016 12:58:25 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "core@ietf.org WG" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [core] FETCH errors X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 10 Oct 2016 10:57:40 -0000 Prompted by Alexey's AD review, I wrote more detailed text for the errors that can be encountered by FETCH requests, analogous to the existing text for PATCH/iPATCH*). As the FETCH/PATCH document is on the agenda for Thursday's IESG meeting, some quick feedback on the list would be appreciated. Convenient links for reviewing: https://core-wg.github.io/etch/#rfc.section.2.2 and (for a complete diff) https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-etch&url2=https://raw.githubusercontent.com/core-wg/etch/gh-pages/draft-ietf-core-etch-latest.txt Grüße, Carsten *) Normally, I'd have factored out common text between the two sections. But let's talk about the new section's content first, which is easiest without the indirection. From nobody Mon Oct 10 07:33:27 2016 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 4CB591296E8 for ; Mon, 10 Oct 2016 07:33:25 -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 wDPP53ZZSu6a for ; Mon, 10 Oct 2016 07:33:22 -0700 (PDT) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 461EC129517 for ; Mon, 10 Oct 2016 07:33:22 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.205]) by smtp-cloud2.xs4all.net with ESMTP id tqZK1t00F4RV18J01qZKPw; Mon, 10 Oct 2016 16:33:19 +0200 Received: from AMontpellier-654-1-80-46.w90-0.abo.wanadoo.fr ([90.0.175.46]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 10 Oct 2016 16:33:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 10 Oct 2016 16:33:19 +0200 From: peter van der Stok To: Carsten Bormann Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <57FB7451.6010401@tzi.org> References: <57FB7451.6010401@tzi.org> Message-ID: <35c4111b40e7906e6311cfb725274733@xs4all.nl> X-Sender: stokcons@xs4all.nl (No91GAg5K+icBwCeG6aCJnj55c2fMyCW) User-Agent: XS4ALL Webmail Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] FETCH errors X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 14:33:26 -0000 Hi Carsten, The following conditions also apply to FETCH in my opinion. Resource not found: requesting (parts of) resources that do not exist. Failed precondition: idem to PATCH the other errors are more resource writing specific,seems to me. Proposal: Generate a section 4, all other sections x become x+1 for x>3 In the section 4.1: FETCH, PATCH, IPATCH errors. 4.2 : PATCH iPATCH errors. (as above) Greetings, Peter Carsten Bormann schreef op 2016-10-10 12:58: > Prompted by Alexey's AD review, I wrote more detailed text for the > errors that can be encountered by FETCH requests, analogous to the > existing text for PATCH/iPATCH*). As the FETCH/PATCH document is on > the > agenda for Thursday's IESG meeting, some quick feedback on the list > would be appreciated. > > Convenient links for reviewing: > > https://core-wg.github.io/etch/#rfc.section.2.2 > > and (for a complete diff) > > https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-etch&url2=https://raw.githubusercontent.com/core-wg/etch/gh-pages/draft-ietf-core-etch-latest.txt > > Grüße, Carsten > > *) Normally, I'd have factored out common text between the two > sections. > But let's talk about the new section's content first, which is easiest > without the indirection. > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Oct 10 09:22:07 2016 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 AAB9212956B for ; Mon, 10 Oct 2016 09:21:58 -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 XwfY-towCf3p for ; Mon, 10 Oct 2016 09:21: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 D15A0129559 for ; Mon, 10 Oct 2016 09:21: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 [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u9AGLq9h028301; Mon, 10 Oct 2016 18:21:52 +0200 (CEST) Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3st53z6rrPz2k2C; Mon, 10 Oct 2016 18:21:51 +0200 (CEST) Message-ID: <57FBC051.6070707@tzi.org> Date: Mon, 10 Oct 2016 18:22:41 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: consultancy@vanderstok.org References: <57FB7451.6010401@tzi.org> <35c4111b40e7906e6311cfb725274733@xs4all.nl> In-Reply-To: <35c4111b40e7906e6311cfb725274733@xs4all.nl> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] FETCH errors X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 10 Oct 2016 16:21:59 -0000 Hi Peter, I didn't list those error conditions because the text focuses on new errors that don't apply to GET ("Beyond the conditions already defined in [RFC7252] for GET, noteworthy ones are:..."). (On the editorial point: I don't think we want to actually factor out the error conditions into a separate section; it is probably more useful to just incrementally list the new ones for PATCH. But, again, let's focus on the content, first.) Grüße, Carsten peter van der Stok wrote: > Hi Carsten, > > The following conditions also apply to FETCH in my opinion. > > Resource not found: requesting (parts of) resources that do not exist. > Failed precondition: idem to PATCH > > the other errors are more resource writing specific,seems to me. > > Proposal: > Generate a section 4, all other sections x become x+1 for x>3 > In the section > 4.1: FETCH, PATCH, IPATCH errors. > 4.2 : PATCH iPATCH errors. (as above) > > Greetings, > > Peter > > Carsten Bormann schreef op 2016-10-10 12:58: >> Prompted by Alexey's AD review, I wrote more detailed text for the >> errors that can be encountered by FETCH requests, analogous to the >> existing text for PATCH/iPATCH*). As the FETCH/PATCH document is on the >> agenda for Thursday's IESG meeting, some quick feedback on the list >> would be appreciated. >> >> Convenient links for reviewing: >> >> https://core-wg.github.io/etch/#rfc.section.2.2 >> >> and (for a complete diff) >> >> https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-etch&url2=https://raw.githubusercontent.com/core-wg/etch/gh-pages/draft-ietf-core-etch-latest.txt >> >> >> Grüße, Carsten >> >> *) Normally, I'd have factored out common text between the two sections. >> But let's talk about the new section's content first, which is easiest >> without the indirection. >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > From nobody Mon Oct 10 12:44:52 2016 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 25D2C129435; Mon, 10 Oct 2016 12:44:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147612868715.31457.7459381389963542114.idtracker@ietfa.amsl.com> Date: Mon, 10 Oct 2016 12:44:47 -0700 Archived-At: Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, core@ietf.org Subject: [core] Alissa Cooper's Discuss on draft-ietf-core-etch-03: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 19:44:47 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-core-etch-03: 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-etch/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I agree with the comment made by the ops-dir reviewer, and I don't think the parenthetical in 2.2.1 addresses the problem. It seems that FETCH is not a useful operation unless the server is capable of understanding what it is supposed to fetch. So it's not true that "any" media type can be used, but rather only those media types for which a definition exists for what the fetch parameters indicate and which part of the resource they are intended to delineate. Shouldn't the use of FETCH be constrained to such media types? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 2 = "(However, while processing a search request, a server can be expected to allocate computing and memory resources or even create additional server resources through which the response to the search can be retrieved.)" s/search/fetch/ would be clearer I think = Section 3 = "If the Request-URI does not point to an existing resource, the server MAY create a new resource with that URI, depending on the patch document type (whether it can logically modify a null resource) and permissions, etc." I know this is the same text as in RFC 5789, but it's vague. What else might create the basis for the server's decision besides the document type and permissions? = Section 5 = It seems that FETCH does introduce a new security consideration, in that any observer of FETCH requests can potentially glean information about the specific portions of a resource of interest to the requester. This might factor into decisions about whether to use DTLS to secure a particular request so may be worth mentioning. From nobody Mon Oct 10 15:26:08 2016 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 2AE17127735 for ; Mon, 10 Oct 2016 15:26:07 -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_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=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 X0DrReENlpgC for ; Mon, 10 Oct 2016 15:26:05 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0091.outbound.protection.outlook.com [104.47.40.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21CD3127071 for ; Mon, 10 Oct 2016 15:26:05 -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=wjDkSOvdWjF26BhsUj5KJhQCLeojLt0Zm5iMnxT1OmY=; b=LKZ8BNqbU9dAFY0rEut1noiCJAiC2c9O8XzLTl9Ukfu/lf7+YK8JdECVvS4fubgNnklMayIFqKLpSIP+10+j2EwxEmbf5iH/JVapUTBMoaUMfNSNt17s+DCbU/kosjxVC4hqKmjoqG7faEFTB1fbPgaSldr+igSJt0P5iPfG77Q= Received: from CY1PR03MB2380.namprd03.prod.outlook.com (10.167.8.6) by MWHPR03MB2448.namprd03.prod.outlook.com (10.169.200.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Mon, 10 Oct 2016 22:26:03 +0000 Received: from CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) by CY1PR03MB2380.namprd03.prod.outlook.com ([10.167.8.6]) with mapi id 15.01.0659.020; Mon, 10 Oct 2016 22:26:03 +0000 From: Brian Raymor To: Carsten Bormann Thread-Topic: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt Thread-Index: AQHR/kux0vvo8uYlLUa/o5fnHPLus6BYnTxwgBQ95TCAChwvAIAMJygggBZ40QCAApds0IAGXqzA Date: Mon, 10 Oct 2016 22:26:03 +0000 Message-ID: References: <147207291891.26600.11584792951825869042.idtracker@ietfa.amsl.com> <114995FB6D604B92854BDA82FEC26123@WeiGengyuPC> <57F4908E.6040905@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brian.Raymor@microsoft.com; x-originating-ip: [174.61.159.182] x-ms-office365-filtering-correlation-id: bd330e20-6efb-4f9f-4fb8-08d3f15c6bb1 x-microsoft-exchange-diagnostics: 1; MWHPR03MB2448; 7:z/xTIYyBnGydFXALjgEW+rfkGr8KUhiutSa/GjoL1jmXfGHdiKDBmd7+y+He6TJ0e+5Q186a9f77K3i9qM629jj3/sH7qk388J1ikTPmFfpCgCXr0RZ0/2NayAop8M85KdnekZSopSqDyrqHQRsgX1N5uF8Xt/3waDxGwufbmH5zf7CvjfJcxKatMiPUtj0EBvokKhJPhscNEYbSDeKqc92/qhj0w/y0BQv0BW7fQgqoxFUNDxwCXUcaSUgCnq2gka+Y+OcW4JKnONsMu9APGD2NOTd38kltc1yFmywDN/05mPtP7MVVijcbdm70e98lUoioXnnSCoJTZCnGWD4fwnKNwole+3EVAQkrVO9v+eFAtWCTwD+e2NwcZgxMt+TM x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR03MB2448; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:MWHPR03MB2448; BCL:0; PCL:0; RULEID:; SRVR:MWHPR03MB2448; x-forefront-prvs: 0091C8F1EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(189002)(377454003)(199003)(101416001)(19580395003)(110136003)(7696004)(5660300001)(10090500001)(33656002)(102836003)(3846002)(6116002)(230783001)(5002640100001)(54356999)(586003)(50986999)(106116001)(76176999)(8936002)(189998001)(2900100001)(106356001)(105586002)(3660700001)(92566002)(11100500001)(3280700002)(66066001)(97736004)(4001430100002)(15975445007)(8990500004)(107886002)(99286002)(10400500002)(5005710100001)(10290500002)(77096005)(86612001)(93886004)(81166006)(81156014)(4326007)(2906002)(305945005)(76576001)(86362001)(68736007)(7846002)(7736002)(8676002)(74316002)(2950100002)(87936001)(6916009)(19580405001)(9686002)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR03MB2448; H:CY1PR03MB2380.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2016 22:26:03.3668 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR03MB2448 Archived-At: Cc: Hannes Tschofenig , "core@ietf.org" , Juan Perez Subject: Re: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 10 Oct 2016 22:26:07 -0000 If there are no further comments on the related pull request - https://gith= ub.com/core-wg/coap-tcp-tls/pull/64 - I will merge tomorrow and publish coa= p-tcp-tls-05. ...Brian -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Brian Raymor Sent: Thursday, October 6, 2016 2:34 PM To: Carsten Bormann Cc: Hannes Tschofenig ; core@ietf.org; Juan Pere= z Subject: Re: [core] I-D Action: draft-ietf-core-coap-tcp-tls-04.txt > Until it receives an indication for an increased message size capability > from the other side, the limitations of Section 4.6 of RFC 7252 continue > to apply to messages sent by any one side.=20 We've addressed this directly in coap-tcp-tls [section 4.3.2] with the use of base value for the Max-Message-Size Capability Option: As per Section 4.6 of [RFC7252], the base value (and the value used when this option is not implemented) is 1152. > (Now, the message receiver might want to go *below* Section 4.6. > If that is a use case we want to support, the argument does apply. Is it= ?) This is the potential case. The sender is exceeding the receiver's maximum message size. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Tue Oct 11 01:40:32 2016 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 778791295BB for ; Tue, 11 Oct 2016 01:40:30 -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 jPuBJTaZbldc for ; Tue, 11 Oct 2016 01:40:28 -0700 (PDT) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0AB012948E for ; Tue, 11 Oct 2016 01:40:27 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.213]) by smtp-cloud2.xs4all.net with ESMTP id u8gR1t00g4bqPqS018gRNX; Tue, 11 Oct 2016 10:40:25 +0200 Received: from AMontpellier-654-1-168-251.w92-145.abo.wanadoo.fr ([92.145.35.251]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 11 Oct 2016 10:40:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 11 Oct 2016 10:40:25 +0200 From: peter van der Stok To: Carsten Bormann Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <57FBC051.6070707@tzi.org> References: <57FB7451.6010401@tzi.org> <35c4111b40e7906e6311cfb725274733@xs4all.nl> <57FBC051.6070707@tzi.org> Message-ID: X-Sender: stokcons@xs4all.nl (2uxlWqI4rfuK20l6kaU1xgiwM6hwiu60) User-Agent: XS4ALL Webmail Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] FETCH errors X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 08:40:30 -0000 Hi Carsten, s /noteworthy ones are/ conditions associated with the FETCH request payload are/ might be clearer. Peter Carsten Bormann schreef op 2016-10-10 18:22: > Hi Peter, > > I didn't list those error conditions because the text focuses on new > errors that don't apply to GET ("Beyond the conditions already defined > in [RFC7252] for GET, noteworthy ones are:..."). > > (On the editorial point: I don't think we want to actually factor out > the error conditions into a separate section; it is probably more > useful > to just incrementally list the new ones for PATCH. But, again, let's > focus on the content, first.) > > Grüße, Carsten > > > peter van der Stok wrote: >> Hi Carsten, >> >> The following conditions also apply to FETCH in my opinion. >> >> Resource not found: requesting (parts of) resources that do not exist. >> Failed precondition: idem to PATCH >> >> the other errors are more resource writing specific,seems to me. >> >> Proposal: >> Generate a section 4, all other sections x become x+1 for x>3 >> In the section >> 4.1: FETCH, PATCH, IPATCH errors. >> 4.2 : PATCH iPATCH errors. (as above) >> >> Greetings, >> >> Peter >> >> Carsten Bormann schreef op 2016-10-10 12:58: >>> Prompted by Alexey's AD review, I wrote more detailed text for the >>> errors that can be encountered by FETCH requests, analogous to the >>> existing text for PATCH/iPATCH*). As the FETCH/PATCH document is on >>> the >>> agenda for Thursday's IESG meeting, some quick feedback on the list >>> would be appreciated. >>> >>> Convenient links for reviewing: >>> >>> https://core-wg.github.io/etch/#rfc.section.2.2 >>> >>> and (for a complete diff) >>> >>> https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-etch&url2=https://raw.githubusercontent.com/core-wg/etch/gh-pages/draft-ietf-core-etch-latest.txt >>> >>> >>> Grüße, Carsten >>> >>> *) Normally, I'd have factored out common text between the two >>> sections. >>> But let's talk about the new section's content first, which is >>> easiest >>> without the indirection. >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >> From nobody Tue Oct 11 05:34:37 2016 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 9369E129542; Tue, 11 Oct 2016 05:34:35 -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 QinRa-M0Tgnl; Tue, 11 Oct 2016 05:34:33 -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 A1362129548; Tue, 11 Oct 2016 05:34:25 -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 u9BCYIbr029682; Tue, 11 Oct 2016 14:34:18 +0200 (CEST) Received: from eduroam-pool6-0351.wlan.uni-bremen.de (eduroam-pool6-0351.wlan.uni-bremen.de [134.102.25.95]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3stbyy2hcsz2j7f; Tue, 11 Oct 2016 14:34:18 +0200 (CEST) Message-ID: <57FCDC80.3000004@tzi.org> Date: Tue, 11 Oct 2016 14:35:12 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Alissa Cooper References: <147612868715.31457.7459381389963542114.idtracker@ietfa.amsl.com> In-Reply-To: <147612868715.31457.7459381389963542114.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org Subject: Re: [core] Alissa Cooper's Discuss on draft-ietf-core-etch-03: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 11 Oct 2016 12:34:35 -0000 Hi Alissa, thank you for these comments. Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-core-etch-03: 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-etch/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I agree with the comment made by the ops-dir reviewer, and I don't think > the parenthetical in 2.2.1 addresses the problem. It seems that FETCH is > not a useful operation unless the server is capable of understanding what > it is supposed to fetch. So it's not true that "any" media type can be > used, but rather only those media types for which a definition exists for > what the fetch parameters indicate and which part of the resource they > are intended to delineate. Shouldn't the use of FETCH be constrained to > such media types? This seems to chime in with a comment that Alexey made, which prompted us to write a new section 2.2: https://core-wg.github.io/etch/#rfc.section.2.2 In particular, we talk about unsupported payloads: Unsupported FETCH payload: In case a client sends payload that is inappropriate for the resource identified by the Request-URI, the server can return a 4.15 (Unsupported Content-Format) CoAP error. The server can determine if the payload is supported by checking the CoAP Content-Format specified with the request. Even the existing text already talks about "admissible media types". We could expand this treatment a bit. For now, I have added a qualification to the "of any media type" sentence such that it reads: With the FETCH method, implementations may submit a request body of any media type that is defined with the semantics of selecting information from a resource in such a FETCH request; it is outside the scope of this document how information about media types admissible for the specific resource is obtained by the client (I'm not entirely happy yet, as it may be the resource that is the one that defines how the media type is to be interpreted as a selector; say, there may be resources that allow searching by text/plain -- maybe this is hard to read from the previous sentence.) > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > = Section 2 = > > "(However, while processing a search request, a server can be expected > to allocate computing and memory resources or even create additional > server resources through which the response to the search can be > retrieved.)" > > s/search/fetch/ would be clearer I think Done in editor's draft. > = Section 3 = > > "If the Request-URI does not point to an existing > resource, the server MAY create a new resource with that URI, > depending on the patch document type (whether it can logically modify > a null resource) and permissions, etc." > > I know this is the same text as in RFC 5789, but it's vague. What else > might create the basis for the server's decision besides the document > type and permissions? The server can run into all kinds of errors, e.g., creating a resource in this way might cause a 4.09 Conflict. This is already discussed in Section 3.4, which we can link to. Replaced "etc.", "as well as other conditions (see also Section 3.4)". > = Section 5 = > > It seems that FETCH does introduce a new security consideration, in that > any observer of FETCH requests can potentially glean information about > the specific portions of a resource of interest to the requester. This > might factor into decisions about whether to use DTLS to secure a > particular request so may be worth mentioning. Good point. Added: The FETCH method is subject to the same general security considerations as all CoAP methods as described in {{-coap}}. The payload of a FETCH request may reveal more detailed information about the specific portions of a resource of interest to the requester than a GET request for the entire resource would; this may mean that confidentiality protection of the request by DTLS or other means is needed for FETCH where it wouldn't be needed for GET. Grüße, Carsten From nobody Tue Oct 11 10:18:18 2016 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 3FF00129510; Tue, 11 Oct 2016 10:18:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147620629325.32029.14852617265019329059.idtracker@ietfa.amsl.com> Date: Tue, 11 Oct 2016 10:18:13 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-tcp-tls-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 17:18: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-05.txt Pages : 43 Date : 2016-10-11 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-05 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 Oct 12 00:03:59 2016 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 1756B1296D5 for ; Wed, 12 Oct 2016 00:03:54 -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=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 qlyRZouVGal7 for ; Wed, 12 Oct 2016 00:03:49 -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 998511295E8 for ; Wed, 12 Oct 2016 00:03:46 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.206]) by smtp-cloud2.xs4all.net with ESMTP id uX3j1t00M4SmhUa01X3jWW; Wed, 12 Oct 2016 09:03:44 +0200 Received: from AMontpellier-654-1-168-251.w92-145.abo.wanadoo.fr ([92.145.35.251]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 12 Oct 2016 09:03:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 12 Oct 2016 09:03:43 +0200 From: peter van der Stok To: Carsten Bormann Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <57FCDC80.3000004@tzi.org> References: <147612868715.31457.7459381389963542114.idtracker@ietfa.amsl.com> <57FCDC80.3000004@tzi.org> Message-ID: <5d5e9889831645c996529004bcf78088@xs4all.nl> X-Sender: stokcons@xs4all.nl (x+VcrFCiWh7IgEPylA2uoRexKEpQYidp) User-Agent: XS4ALL Webmail Archived-At: Cc: core-chairs@ietf.org, draft-ietf-core-etch@ietf.org, Alissa Cooper , The IESG , core@ietf.org Subject: Re: [core] Alissa Cooper's Discuss on draft-ietf-core-etch-03: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 07:03:54 -0000 > > Unsupported FETCH payload: > In case a client sends payload that is inappropriate for the resource > identified by the Request-URI, the server can return a 4.15 > (Unsupported > Content-Format) CoAP error. The server can determine if the payload is > supported by checking the CoAP Content-Format specified with the > request. > > Even the existing text already talks about "admissible media types". > We could expand this treatment a bit. > > For now, I have added a qualification to the "of any media type" > sentence such that it reads: > > With the > FETCH method, implementations may submit a request body of any media > type that is > defined with the semantics of selecting information from > a resource in such a FETCH request; it is outside the scope of this > document how > information about media types admissible for the specific resource is > obtained by the client > (Over?)Simplified: With the FETCH method, implementations may submit a request body of any media type that indicates to the target resource the semantics of the request payload such that the server can decide on accepting the request; > it is outside the scope of this > document how > information about media types admissible for the specific resource is > obtained by the client > From nobody Wed Oct 12 01:12:19 2016 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 A910D1296F9 for ; Wed, 12 Oct 2016 01:12:15 -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, HTML_MESSAGE=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=sics.se 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 0HXxqj5Z82AT for ; Wed, 12 Oct 2016 01:12:04 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 4523A1296F4 for ; Wed, 12 Oct 2016 01:12:04 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id b81so64875434lfe.1 for ; Wed, 12 Oct 2016 01:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics.se; s=google; h=mime-version:from:date:message-id:subject:to; bh=rwte14AeHecS+6MORirmYpvs5IB5AkY3EV38+abFrD8=; b=QG1WbMB56Wc9rCsoMmG+doQbz+KpEGbSG+tdXsCSlkhBsm9nSe++bFrtpoPULBzrvE +72ZC37pLQFyyJKgTNL9GlFcAyS8mlTKt0hmJAjMADs0mun5fCoYZ9/abIS7UR1zm6mX wolcdslJ+PYjePo8X+CrDC0C7Q0TkTxMUipG9FtMAYruqCy9Hf7LappyDOPmlFUKKRmQ Q98AMnGP/MRRomIVVjOL+lXNkG06xwVZP85z5bs31eTfthtUtjDp9kCQlSxeFFyo42qf R0pxQyI4u3Qx/D1kIDsssovevXnoM0/ShRvEhnXdGn2P8hfR+Vu7DRi+oYlc6lPFBaCu iYAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rwte14AeHecS+6MORirmYpvs5IB5AkY3EV38+abFrD8=; b=EIUcKsOqE0Rv12mRI+6aqirk+t45pXTAKGI7fDWJXNLWyqLTtOlOJmwa62F4LrWhQQ MU2AsaMOiiEY/LrPsN7AtJFiPJJdUB+W4eaobIWVvgvtE1t05YKjXv4PfF9Fw5LEyqrg uB7JFkaQPDutlRk9F7m90+QHbm6HXkseTmJE+JgGsGmNczofGc5GIfJ/PkXzm0mylioQ yujGko647rCTVtGYCUQBk8VOT5DfQl81Dq7NJOvBVSHH7baNCKmRCI6tp3u37cBhlv6Y WBXM/0fzPPK1aJyeume/qiInpMmnk+69ILcRnZyn5mA2VrbtdtI834AGZ/Y7S0hFuk31 LPPA== X-Gm-Message-State: AA6/9RlxJY4MQHwv6G5DWZllcSTNKJ69zFvOhQRFLXkfQYuYdKJByBRAR9oGB300Uj4rG3G/xOZMMMHOab/FttdM X-Received: by 10.25.139.195 with SMTP id n186mr6103529lfd.97.1476259922123; Wed, 12 Oct 2016 01:12:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.134.213 with HTTP; Wed, 12 Oct 2016 01:12:01 -0700 (PDT) From: Marco Tiloca Date: Wed, 12 Oct 2016 10:12:01 +0200 Message-ID: To: core@ietf.org, Ace@ietf.org Content-Type: multipart/alternative; boundary=001a113ebaa6413c47053ea68ced Archived-At: Subject: [core] Fwd: New Version Notification for draft-tiloca-core-multicast-oscoap-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Oct 2016 08:12:17 -0000 --001a113ebaa6413c47053ea68ced Content-Type: text/plain; charset=UTF-8 Dear CoRE/ACE, We have submitted a draft on secure group communication for CoAP addressing security for the setting of a multicast CoAP request with unicast responses as described in RFC7390. This draft builds on the recently updated version of OSCOAP, extended with mandatory Sender ID and multiple Recipient Contexts. It also enables source authentication with asymmetric signatures implemented as counter signatures included with the COSE objects defined by OSCOAP. We hope that by submitting now we could get some first discussion to allow updates before the cutoff. This draft provides the missing link between https://tools.ietf.org/html/draft-somaraju-ace-multicast and OSCOAP. Best regards, Marco ---------- Forwarded message ---------- From: Date: Wed, Oct 12, 2016 at 9:27 AM Subject: New Version Notification for draft-tiloca-core-multicast-oscoap-00.txt To: Marco Tiloca , Goeran Selander < goran.selander@ericsson.com>, Francesca Palombini < francesca.palombini@ericsson.com> A new version of I-D, draft-tiloca-core-multicast-oscoap-00.txt has been successfully submitted by Francesca Palombini and posted to the IETF repository. Name: draft-tiloca-core-multicast-oscoap Revision: 00 Title: Secure group communication for CoAP Document date: 2016-10-12 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-tiloca-core- multicast-oscoap-00.txt Status: https://datatracker.ietf.org/doc/draft-tiloca-core- multicast-oscoap/ Htmlized: https://tools.ietf.org/html/draft-tiloca-core-multicast- oscoap-00 Abstract: This document describes a method for application layer protection of messages exchanged with the Constrained Application Protocol (CoAP) in a group communication context. The proposed approach relies on Object Security of CoAP (OSCOAP) and the CBOR Object Signing and Encryption (COSE) format. All security requirements fulfilled by OSCOAP are maintained for multicast CoAP request messages and related unicast CoAP response messages. Source authentication of all messages exchanged within the group is ensured, by means of digital signatures produced through asymmetric private keys of sender devices and embedded in the protected CoAP messages. 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. The IETF Secretariat --001a113ebaa6413c47053ea68ced Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear CoRE/ACE,

We have submitted a draft on secure group communication for CoAP=20 addressing security for the setting of a multicast CoAP request with=20 unicast responses as described in RFC7390.

This draft builds on the recently updated version of OSCOAP, extended=20 with mandatory Sender ID and multiple Recipient Contexts. It also=20 enables source authentication with asymmetric signatures implemented as=20 counter signatures included with the COSE objects defined by OSCOAP.

We hope that by submitting now we could get some first discussion to allow = updates before the cutoff.

This draft provides the missing link between https://tools.ietf.org/html/draft-so= maraju-ace-multicast and OSCOAP.

Best regards,
Marco


---------- Forwarded message --= --------
From: <= internet-drafts@ietf.org>= ;
Date: Wed, Oct 12, 2016 at 9:27 AM
Subject: New Version Noti= fication for draft-tiloca-core-multicast-oscoap-00.txt
To: Marco Tiloca = <marco@sics.se>, Goeran Selander= <goran.selander@ericsson= .com>, Francesca Palombini <francesca.palombini@ericsson.com>



A new version of I-D, draft-tiloca-core-multicast-oscoap-00.txt
has been successfully submitted by Francesca Palombini and posted to the IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-tiloca-core-multicast-<= wbr>oscoap
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Secure group communication for CoA= P
Document date:=C2=A0 2016-10-12
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-til= oca-core-multicast-oscoap-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-tiloca-core-multi= cast-oscoap/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-0= 0


Abstract:
=C2=A0 =C2=A0This document describes a method for application layer protect= ion of
=C2=A0 =C2=A0messages exchanged with the Constrained Application Protocol (= CoAP)
=C2=A0 =C2=A0in a group communication context.=C2=A0 The proposed approach = relies on
=C2=A0 =C2=A0Object Security of CoAP (OSCOAP) and the CBOR Object Signing a= nd
=C2=A0 =C2=A0Encryption (COSE) format.=C2=A0 All security requirements fulf= illed by
=C2=A0 =C2=A0OSCOAP are maintained for multicast CoAP request messages and = related
=C2=A0 =C2=A0unicast CoAP response messages.=C2=A0 Source authentication of= all
=C2=A0 =C2=A0messages exchanged within the group is ensured, by means of di= gital
=C2=A0 =C2=A0signatures produced through asymmetric private keys of sender = devices
=C2=A0 =C2=A0and embedded in the protected CoAP messages.




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

The IETF Secretariat


--001a113ebaa6413c47053ea68ced-- From nobody Wed Oct 12 09:00:26 2016 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 9F9141200DF; Wed, 12 Oct 2016 09:00:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147628802464.6377.2774521252462284021.idtracker@ietfa.amsl.com> Date: Wed, 12 Oct 2016 09:00:24 -0700 Archived-At: Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, core@ietf.org Subject: [core] Spencer Dawkins' Discuss on draft-ietf-core-etch-03: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 16:00:24 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-core-etch-03: 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-etch/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm following most of your reasoning behind having the twin methods PATCH and iPATCH, but I'm struggling a bit that there's nothing that I saw that prevents a problem when the client implements only PATCH and the server implements only iPATCH. The only text I saw that provides guidance about which method to implement is A client can mark a request as idempotent by using the iPATCH method instead of the PATCH method. This is the only difference between the two. The indication of idempotence may enable the server to keep less state about the interaction; some constrained servers may only implement the iPATCH variant for this reason. Maybe I missed something? If not, I saw There is no guarantee that a resource can be modified with PATCH or iPATCH. so, maybe that mismatch isn't going to be a problem in practice, but it seems sad that you might have a patchable resource, that can't be patched because of that mismatch. I'm not asking for "clients MUST implement iPATCH if you implement PATCH" (which would accommodate servers that only implement iPATCH), but I wonder if the working group talked about a way to avoid this mismatch? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I was a bit uneasy with the "nearly" in The security considerations for PATCH or iPATCH are nearly identical to the security considerations for PUT ([RFC7252]). with no explanation of any differences, but I'll leave that for the SEC ADs to pick up on if it matters. From nobody Wed Oct 12 09:28:02 2016 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 14C2E1295DB; Wed, 12 Oct 2016 09:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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=cooperw.in header.b=pSvZmLL9; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=e61i9nav 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 ycM7lPmmDtGn; Wed, 12 Oct 2016 09:27:53 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17D151295CC; Wed, 12 Oct 2016 09:27:53 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 818F92070B; Wed, 12 Oct 2016 12:27:52 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 12 Oct 2016 12:27:52 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=gbr1a3GlUuRdBY6SM+qDb0CKc7A=; b=pSvZmL L99iYNVrOqtzENNwUU76eTrxucLxow7sWVQCD3sSxnpoPDbNQsSwUy2u5BuvWpBc zSFJDoAkHDH+H7bQPWrkEdRxz1CZPiRgoiTGyme11nA3CHT79ciiDlDFLjaGwuAF 8Iy0tv403GHAIn5ixfAF/+2sBJs+PX52Ibo4s= DKIM-Signature: v=1; a=rsa-sha1; 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-sasl-enc:x-sasl-enc; s=smtpout; bh=gbr1a3GlUuRdBY6 SM+qDb0CKc7A=; b=e61i9nav3jWkUjgvi7ql4+ZTYg8QqsvLp4uXGSeanP+ByDW 4anAqft/gEauE4r4BLc8b6JnJsBdTEhqdo2F8jhJggIOvL+9zN3Ji3JagBGEev1K 94/uxh9LeUTEQvZaVDUK4RhMFVW3Oz8GddbOT4kXenfv5N6EIDeUBZ6fzH4E= X-Sasl-enc: AA2Trztm0wBVQ297Pk1CYabhcIU9h5q2xK9+L1ysgEdd 1476289671 Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.179]) by mail.messagingengine.com (Postfix) with ESMTPA id 18B27F2985; Wed, 12 Oct 2016 12:27:50 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <57FCDC80.3000004@tzi.org> Date: Wed, 12 Oct 2016 12:27:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2DCF36F2-0821-4B02-A97F-2B8D238B3C67@cooperw.in> References: <147612868715.31457.7459381389963542114.idtracker@ietfa.amsl.com> <57FCDC80.3000004@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, IESG , core@ietf.org Subject: Re: [core] Alissa Cooper's Discuss on draft-ietf-core-etch-03: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 12 Oct 2016 16:27:56 -0000 Carsten, Thanks for your response. Inline ... > On Oct 11, 2016, at 8:35 AM, Carsten Bormann wrote: >=20 > Hi Alissa, >=20 > thank you for these comments. >=20 > Alissa Cooper wrote: >> Alissa Cooper has entered the following ballot position for >> draft-ietf-core-etch-03: Discuss >>=20 >> 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.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-core-etch/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> I agree with the comment made by the ops-dir reviewer, and I don't = think >> the parenthetical in 2.2.1 addresses the problem. It seems that FETCH = is >> not a useful operation unless the server is capable of understanding = what >> it is supposed to fetch. So it's not true that "any" media type can = be >> used, but rather only those media types for which a definition exists = for >> what the fetch parameters indicate and which part of the resource = they >> are intended to delineate. Shouldn't the use of FETCH be constrained = to >> such media types? >=20 > This seems to chime in with a comment that Alexey made, which prompted > us to write a new section 2.2: >=20 > https://core-wg.github.io/etch/#rfc.section.2.2 >=20 > In particular, we talk about unsupported payloads: >=20 > Unsupported FETCH payload: > In case a client sends payload that is inappropriate for the resource > identified by the Request-URI, the server can return a 4.15 = (Unsupported > Content-Format) CoAP error. The server can determine if the payload is > supported by checking the CoAP Content-Format specified with the = request. >=20 > Even the existing text already talks about "admissible media types". > We could expand this treatment a bit. Yes, I think characterization of this just needs to be consistent = throughout the document. >=20 > For now, I have added a qualification to the "of any media type" > sentence such that it reads: >=20 > With the > FETCH method, implementations may submit a request body of any media > type that is > defined with the semantics of selecting information from > a resource in such a FETCH request; it is outside the scope of this > document how > information about media types admissible for the specific resource is > obtained by the client >=20 > (I'm not entirely happy yet, as it may be the resource that is the one > that defines how the media type is to be interpreted as a selector; = say, > there may be resources that allow searching by text/plain -- maybe = this > is hard to read from the previous sentence.) I agree that the sentence does not convey your last point above. = Peter=E2=80=99s suggestion is more clear but also does not capture this = point I don=E2=80=99t think. Thanks, Alissa >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> =3D Section 2 =3D >>=20 >> "(However, while processing a search request, a server can be = expected >> to allocate computing and memory resources or even create = additional >> server resources through which the response to the search can be >> retrieved.)" >>=20 >> s/search/fetch/ would be clearer I think >=20 > Done in editor's draft. >=20 >> =3D Section 3 =3D >>=20 >> "If the Request-URI does not point to an existing >> resource, the server MAY create a new resource with that URI, >> depending on the patch document type (whether it can logically = modify >> a null resource) and permissions, etc." >>=20 >> I know this is the same text as in RFC 5789, but it's vague. What = else >> might create the basis for the server's decision besides the document >> type and permissions? >=20 > The server can run into all kinds of errors, e.g., creating a resource > in this way might cause a 4.09 Conflict. This is already discussed in > Section 3.4, which we can link to. >=20 > Replaced "etc.", "as well as other conditions (see also Section 3.4)". >=20 >> =3D Section 5 =3D >>=20 >> It seems that FETCH does introduce a new security consideration, in = that >> any observer of FETCH requests can potentially glean information = about >> the specific portions of a resource of interest to the requester. = This >> might factor into decisions about whether to use DTLS to secure a >> particular request so may be worth mentioning. >=20 > Good point. Added: >=20 > The FETCH method is subject to the same general security > considerations as all CoAP methods as described in {{-coap}}. > The payload of a FETCH request may reveal more detailed information > about the specific portions of a resource of interest to the > requester than a GET request for the entire resource would; this may > mean that confidentiality protection of the request by DTLS or other > means is needed for FETCH where it wouldn't be needed for GET. >=20 > Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Oct 12 10:33:44 2016 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 CC65312962A; Wed, 12 Oct 2016 10:33:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147629362183.6297.18321888937912730256.idtracker@ietfa.amsl.com> Date: Wed, 12 Oct 2016 10:33:41 -0700 Archived-At: Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, core@ietf.org Subject: [core] Kathleen Moriarty's Discuss on draft-ietf-core-etch-03: (with DISCUSS) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 17:33:42 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-core-etch-03: 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-etch/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'd like to see more of the actual requirements for this draft in the security considerations as the pointers include all of the configuration options for DTLS, including the "nosec" option. I would think this operation would require authentication to prevent unauthorized access by devices that are clones. This is a real problem in the non-IoT space for firmware updates and will be a problem in this space if it isn't already - knock off hardware that installs the firmware of a popular product. In In section 5 of RFC5789, I see this: These include authorizing requests (possibly through access control and/or authentication) and ensuring that data is not corrupted through transport errors or through accidental overwrites. And would like to see something similar in this section to at least list some of the requirements and reasoning. For patch and fetch, I think the reason outlined above needs to be included as well so it is top of mind for implementers and they are aware of this very real threat. It is important they understand why they need authentication and encryption to prevent attacks against their brand. If someone buys knock-off hardware that is faulty and uses their firmware, they have multiple problems to deal with, not just the loss of sales. From nobody Wed Oct 12 13:06:47 2016 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 11B82129442; Wed, 12 Oct 2016 13:06:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147630280706.6301.3762240229089528335.idtracker@ietfa.amsl.com> Date: Wed, 12 Oct 2016 13:06:47 -0700 Archived-At: Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, core@ietf.org Subject: [core] Ben Campbell's No Objection on draft-ietf-core-etch-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 20:06:47 -0000 Ben Campbell has entered the following ballot position for draft-ietf-core-etch-03: 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-etch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share the concerns from Alissa's DISCUSS point and comment about section 5. From nobody Wed Oct 12 14:56:38 2016 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 0B44312961D; Wed, 12 Oct 2016 14:56:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147630939503.6297.3761094841358119665.idtracker@ietfa.amsl.com> Date: Wed, 12 Oct 2016 14:56:35 -0700 Archived-At: Cc: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-http-mapping@ietf.org Subject: [core] Ben Campbell's Discuss on draft-ietf-core-http-mapping-15: (with DISCUSS) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 21:56:35 -0000 Ben Campbell has entered the following ballot position for draft-ietf-core-http-mapping-15: 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-http-mapping/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a generally well written document, but it seems to be defining protocol, or at least required practices for interoperability. Why is it informational? If it really does make sense for it to be informational, I think a paragraph explaining why would be helpful. The 2nd paragraph in section 1 seems to attempt that, but the explanation leads me again to think that informational is not the right status. "Guidelines that...should adhere to" to increase interoperability doesn't sound informational. From nobody Wed Oct 12 17:54:19 2016 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 2BBF51295F0; Wed, 12 Oct 2016 17:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] 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 6N9wlEAvHaO3; Wed, 12 Oct 2016 17:54:14 -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 6A58912965A; Wed, 12 Oct 2016 17:54:14 -0700 (PDT) Received: from [10.0.1.21] (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 u9D0s9sI075208 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 12 Oct 2016 19:54:10 -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.21] From: "Ben Campbell" To: "The IESG" Date: Wed, 12 Oct 2016 19:54:09 -0500 Message-ID: In-Reply-To: <147630939503.6297.3761094841358119665.idtracker@ietfa.amsl.com> References: <147630939503.6297.3761094841358119665.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.5r5263) Archived-At: Cc: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-http-mapping@ietf.org Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-http-mapping-15: (with DISCUSS) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 00:54:18 -0000 On 12 Oct 2016, at 16:56, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-core-http-mapping-15: 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-http-mapping/ > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is a generally well written document, but it seems to be defining > protocol, or at least required practices for interoperability. Why is it > informational? If it really does make sense for it to be informational, > I think a paragraph explaining why would be helpful. > > The 2nd paragraph in section 1 seems to attempt that, but the explanation > leads me again to think that informational is not the right status. > "Guidelines that...should adhere to" to increase interoperability doesn't > sound informational. Oops, somehow I managed to edit out the following: "Would experimental be more appropriate?" From donn@zhaw.ch Mon Oct 10 02:49:11 2016 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 882EC129497 for ; Mon, 10 Oct 2016 02:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, 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 5BjocBqmuSZG for ; Mon, 10 Oct 2016 02:49:09 -0700 (PDT) Received: from srv-mail-012.zhaw.ch (srv-mail-012.zhaw.ch [160.85.104.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1D56A129426 for ; Mon, 10 Oct 2016 02:49:08 -0700 (PDT) Received: from srv-mail-012.zhaw.ch (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F1E8E337 for ; Mon, 10 Oct 2016 11:49:07 +0200 (CEST) Received: from srv-mail-043.zhaw.ch (srv-mail-043.zhaw.ch [160.85.196.13]) by srv-mail-012.zhaw.ch (Postfix) with ESMTP id CBBAB149 for ; Mon, 10 Oct 2016 11:49:07 +0200 (CEST) Received: from srv-mail-103.zhaw.ch (172.28.5.26) by srv-mail-103.zhaw.ch (172.28.5.26) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 10 Oct 2016 11:49:07 +0200 Received: from srv-mail-103.zhaw.ch ([fe80::1051:7f22:8579:fb6d]) by srv-mail-103.zhaw.ch ([fe80::1051:7f22:8579:fb6d%16]) with mapi id 15.00.1178.000; Mon, 10 Oct 2016 11:49:07 +0200 From: "Doran Hans (donn)" To: "core@ietf.org" Thread-Topic: Mail regarding draft-ietf-core-coap Thread-Index: AdIi1gCJns8raEy9RU+NylefQpm6dwAA9Jhw Date: Mon, 10 Oct 2016 09:49:07 +0000 Message-ID: Accept-Language: de-CH, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [160.85.196.21] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 13 Oct 2016 00:48:38 -0700 Subject: [core] WG: Mail regarding draft-ietf-core-coap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 06:48:12 -0000 Hi, I've been teaching CoAP in an IoT class which led me to read the RFC 7252. The standard could do with a revision in writing - one example is here: 5.2.3. Non-confirmable If the request message is Non-confirmable, then the response SHOULD be returned in a Non-confirmable message as well. However, an endpoint MUST be prepared to receive a Non-confirmable response (preceded or followed by an Empty Acknowledgement message) in reply to a Confirmable request, or a Confirmable response in reply to a Non-confirmable request.=20 This sentence links Non-confirmable message behaviour with Confirmable mess= age behaviour through the word "However" despite it being abundantly clear = that the two have nothing to do with each other. The paragraph SHOULD read: 5.2.3. Non-confirmable =20 If the request message is Non-confirmable, then the response SHOULD be returned in a Non-confirmable message as well. However an endpoint MUST be prepared to receive a Confirmable response in reply to = a Non-confirmable request. So far so good: However we have an implementation based on python libraries= running where the default response to a NON message is an ACK. It is not p= ossible to determine from the standard whether this is incorrect behaviour = or not. =20 I don't know how the RFC system works with regard to revisions - if I had r= ead the earlier versions of the document I would have done some re-writing = at the time - but if it is to be revised then maybe you could let me know.= =20 Best regards ZHAW Zurich University of Applied Sciences=20 Institute of Embedded Systems (InES)=20 Prof. Hans Dermot Doran Head of Secure and Dependable Systems=20 Technikumstrasse 9, Postfach,=A0CH-8401 Winterthur=20 T +41-58-934-7676 =A0 |=A0M=A0+41-79-636-8133=20 http://ines.zhaw.ch=A0| hans.doran@zhaw.ch From nobody Thu Oct 13 00:58:16 2016 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 8A358129431; Thu, 13 Oct 2016 00:58:08 -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 T0RFIbQvrKeI; Thu, 13 Oct 2016 00:58:06 -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 1BE501296DE; Thu, 13 Oct 2016 00:58: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 u9D7vxYS025528; Thu, 13 Oct 2016 09:57:59 +0200 (CEST) Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3svjlC4hGKz3SfM; Thu, 13 Oct 2016 09:57:59 +0200 (CEST) Message-ID: <57FF3EC8.8080605@tzi.org> Date: Thu, 13 Oct 2016 09:59:04 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Kathleen Moriarty References: <147629362183.6297.18321888937912730256.idtracker@ietfa.amsl.com> In-Reply-To: <147629362183.6297.18321888937912730256.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org Subject: Re: [core] Kathleen Moriarty's Discuss on draft-ietf-core-etch-03: (with DISCUSS) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 07:58:08 -0000 Hi Kathleen, thank you for this review. Maybe I'm not reading this right, but a lot of what you are saying sounds like considerations that apply to all of CoAP's methods. These should already be covered by the security considerations of RFC 7252, which we do refer to. Alissa indeed had an observation about a security consideration that is specific to FETCH that we had overlooked, and we have added that in the editors' draft. I can't really make out which of your comments indicate security considerations specific to FETCH, or to PATCH/iPATCH, or to both, that are not already covered by RFC 7252. Grüße, Carsten Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-core-etch-03: 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-etch/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I'd like to see more of the actual requirements for this draft in the > security considerations as the pointers include all of the configuration > options for DTLS, including the "nosec" option. I would think this > operation would require authentication to prevent unauthorized access by > devices that are clones. This is a real problem in the non-IoT space for > firmware updates and will be a problem in this space if it isn't already > - knock off hardware that installs the firmware of a popular product. In > In section 5 of RFC5789, I see this: > These > include authorizing requests (possibly through access control and/or > authentication) and ensuring that data is not corrupted through > transport errors or through accidental overwrites. > > And would like to see something similar in this section to at least list > some of the requirements and reasoning. For patch and fetch, I think the > reason outlined above needs to be included as well so it is top of mind > for implementers and they are aware of this very real threat. It is > important they understand why they need authentication and encryption to > prevent attacks against their brand. If someone buys knock-off hardware > that is faulty and uses their firmware, they have multiple problems to > deal with, not just the loss of sales. > > > > > From nobody Thu Oct 13 02:54:23 2016 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 D6F1412970F; Thu, 13 Oct 2016 02:54:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147635245787.2894.1907116527239429628.idtracker@ietfa.amsl.com> Date: Thu, 13 Oct 2016 02:54:17 -0700 Archived-At: Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, core@ietf.org Subject: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-core-etch-03=3A_=28with_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 09:54:18 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-core-etch-03: 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-etch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Does this doc update RFC7252? Maybe not; just asking... From nobody Thu Oct 13 02:59:53 2016 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 4963E12971B; Thu, 13 Oct 2016 02:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_H2=-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=fastmail.fm header.b=C4Uv1nbK; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=W4wsf5xe 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 L0P8APu_77uk; Thu, 13 Oct 2016 02:59:48 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28D5129721; Thu, 13 Oct 2016 02:59:47 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5468B20882; Thu, 13 Oct 2016 05:59:47 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute4.internal (MEProxy); Thu, 13 Oct 2016 05:59:47 -0400 DKIM-Signature: v=1; a=rsa-sha1; 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-sasl-enc :x-sasl-enc; s=mesmtp; bh=XKwghGJz0+fDQjyiH5n3dJCk42g=; b=C4Uv1n bK4NLnxjUKflHXGpIPxO4LI1ebGQ+TWHSQg06uKzsUWq/MXDIow3BJQePDy/kP+F ZexYcVGiGF29glm8qMfJW38KNI46HK1SwEicM5MzI9gF+odthJmlIPgdNVJfkp6Y fWzk0Gl166PZ+r1o0SQ6VgeWzhd75Wc/d3Csc= DKIM-Signature: v=1; a=rsa-sha1; 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-sasl-enc:x-sasl-enc; s=smtpout; bh=XKwghGJz0+fDQjy iH5n3dJCk42g=; b=W4wsf5xeTIGLOK/7NXlCWwRanvoWGUWykW73LSELaom0QfO XrZZ4gmnAk9pU2fRHW3jQSDZpJQJT7Fwg6lyJDCxrPASb7fKrN7OmjA4OBN+WBhB A8XsJlAIB3DLBNTBEIbED5fkeyDE5sxBZVepMP0Fu9ljcASaoqkAQ8MjajMY= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 2572996EAB; Thu, 13 Oct 2016 05:59:47 -0400 (EDT) Message-Id: <1476352787.1586079.754588145.2859F2AE@webmail.messagingengine.com> X-Sasl-Enc: oauhcOjVqK3IAvLmZTfNlaBhvfdH8eqquH6iqQvKmefm 1476352787 From: Alexey Melnikov To: Ben Campbell , The IESG MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-cdbff290 Date: Thu, 13 Oct 2016 10:59:47 +0100 In-Reply-To: References: <147630939503.6297.3761094841358119665.idtracker@ietfa.amsl.com> Archived-At: Cc: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-http-mapping@ietf.org Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-http-mapping-15: (with DISCUSS) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 09:59:51 -0000 Hi Ben, On Thu, Oct 13, 2016, at 01:54 AM, Ben Campbell wrote: > On 12 Oct 2016, at 16:56, Ben Campbell wrote: > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This is a generally well written document, but it seems to be defining > > protocol, or at least required practices for interoperability. Why is it > > informational? If it really does make sense for it to be informational, > > I think a paragraph explaining why would be helpful. > > > > The 2nd paragraph in section 1 seems to attempt that, but the explanation > > leads me again to think that informational is not the right status. > > "Guidelines that...should adhere to" to increase interoperability doesn't > > sound informational. > > Oops, somehow I managed to edit out the following: > > "Would experimental be more appropriate?" I think there are several implementations that follow recommendations in the document, so "Experimental" doesn't seem appropriate here. I also wanted for the document to be Proposed Standard, but I think the WG doesn't feel comfortable to mandate behavior in the document on all implementations. I would like to hear more from the WG on this. Best Regards, Alexey From nobody Thu Oct 13 03:05:14 2016 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 934EC1295D2; Thu, 13 Oct 2016 03:05:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147635310959.2894.5920321807610875593.idtracker@ietfa.amsl.com> Date: Thu, 13 Oct 2016 03:05:09 -0700 Archived-At: Cc: core-chairs@ietf.org, menachemdodge1@gmail.com, core@ietf.org, draft-ietf-core-http-mapping@ietf.org Subject: [core] Benoit Claise's Discuss on draft-ietf-core-http-mapping-15: (with DISCUSS) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 10:05:09 -0000 Benoit Claise has entered the following ballot position for draft-ietf-core-http-mapping-15: 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-http-mapping/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- [sorry for coming late to the party] One point I would like to DISCUSS: I wonder if this document is not already obsolete, now that we have the new FETCH/iPATCH/PATCH methods (draft-ietf-core-etch)? Should we expect an update document for the new mappings? Don't we need at least want a reference to draft-ietf-core-etch, expressing it's not covered. From nobody Thu Oct 13 03:43:42 2016 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 BEA721294C0 for ; Thu, 13 Oct 2016 03:43:38 -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=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 2UmwnpUSLMXD for ; Thu, 13 Oct 2016 03:43:37 -0700 (PDT) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7C51294ED for ; Thu, 13 Oct 2016 03:43:34 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.212]) by smtp-cloud2.xs4all.net with ESMTP id uyjY1t00J4aYjWA01yjYs5; Thu, 13 Oct 2016 12:43:32 +0200 Received: from AMontpellier-654-1-168-251.w92-145.abo.wanadoo.fr ([92.145.35.251]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 13 Oct 2016 12:43:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 13 Oct 2016 12:43:32 +0200 From: peter van der Stok To: Spencer Dawkins Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <147628802464.6377.2774521252462284021.idtracker@ietfa.amsl.com> References: <147628802464.6377.2774521252462284021.idtracker@ietfa.amsl.com> Message-ID: <3ad76e63e6f6b955b5373a5521bcca98@xs4all.nl> X-Sender: stokcons@xs4all.nl (ZgTJ9WmHIweempIbdIjun7BLfvizlmUD) User-Agent: XS4ALL Webmail Archived-At: Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org Subject: Re: [core] Spencer Dawkins' Discuss on draft-ietf-core-etch-03: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 10:43:39 -0000 Hi Spencer, Thanks for your DISCUSS; I will try to respond to it. There have been discussions in the WG about the utility of PATCH next to iPATCH. Good reasons were put forward to maintain both. Also the wish was expressed to only allow idem-potent requests and be able to implement iPATCH without the PATCH counterpart. Sending a PATCH request to an iPATCH only server will result in a CoAP error 4.05 method not allowed If I understand correctly, your concern is a non-idempotent request sent to an iPATCH server. In section 3.4 there is text about server reactions to inappropriate payloads. In particular the response code: Unprocessable request applies: when processing the request makes the resource invalid. We might add (e.g. non idem-potent request to iPATCH) Does this answer your concern? Greetings, peter Spencer Dawkins schreef op 2016-10-12 18:00: > Spencer Dawkins has entered the following ballot position for > draft-ietf-core-etch-03: 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-etch/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I'm following most of your reasoning behind having the twin methods > PATCH > and iPATCH, but I'm struggling a bit that there's nothing that I saw > that > prevents a problem when the client implements only PATCH and the server > implements only iPATCH. > > The only text I saw that provides guidance about which method to > implement is > > A client can mark a request as idempotent by using the iPATCH method > instead of the PATCH method. This is the only difference between > the > two. The indication of idempotence may enable the server to keep > less state about the interaction; some constrained servers may only > implement the iPATCH variant for this reason. > > Maybe I missed something? > > If not, I saw > > There is no guarantee that a resource can be modified with PATCH or > iPATCH. > > so, maybe that mismatch isn't going to be a problem in practice, but it > seems sad that you might have a patchable resource, that can't be > patched > because of that mismatch. > > I'm not asking for "clients MUST implement iPATCH if you implement > PATCH" > (which would accommodate servers that only implement iPATCH), but I > wonder if the working group talked about a way to avoid this mismatch? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I was a bit uneasy with the "nearly" in > > The security considerations for PATCH or iPATCH are nearly identical > to the security considerations for PUT ([RFC7252]). > > with no explanation of any differences, but I'll leave that for the SEC > ADs to pick up on if it matters. > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Thu Oct 13 04:02:57 2016 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 530021293FB; Thu, 13 Oct 2016 03:37:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147635502732.3016.5476275427692208467.idtracker@ietfa.amsl.com> Date: Thu, 13 Oct 2016 03:37:07 -0700 Archived-At: X-Mailman-Approved-At: Thu, 13 Oct 2016 04:02:56 -0700 Cc: =?utf-8?q?draft-ietf-core-http-mapping=40ietf=2Eorg=2C_=22Jaime_Jimenez?=@ietfa.amsl.com, =?utf-8?b?bC5jb20+?=@ietfa.amsl.com, =?utf-8?q?=22_=3Cjaime=2Ejimenez=40ericsson=2Ecom=3E=2C_core-chairs=40ietf?=@ietfa.amsl.com, =?utf-8?b?IG1lbmEgPj4g157XoNeX150g15PXldeT15InIDxtZW5hY2hlbWRvZGdlMUBnbWFp?=@ietfa.amsl.com, =?utf-8?b?Lm9yZywgamFpbWUuamltZW5lekBlcmljc3Nvbi5jb20sIGNvcmVAaWV0Zi5vcmcs?=@ietfa.amsl.com Subject: [core] Benoit Claise's Discuss on draft-ietf-core-http-mapping-15: (with DISCUSS) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 10:37:07 -0000 Benoit Claise has entered the following ballot position for draft-ietf-core-http-mapping-15: 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-http-mapping/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- [sorry for coming late to the party] One point I would like to DISCUSS: I wonder if this document is not already obsolete, now that we have the new FETCH/iPATCH/PATCH methods (draft-ietf-core-etch)? Should we expect an update document for the new mappings? Don't we need at least a reference to draft-ietf-core-etch, expressing it's not covered? From nobody Thu Oct 13 04:05:18 2016 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 1C8631296E2; Thu, 13 Oct 2016 04:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_H2=-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=fastmail.fm header.b=ILaAMOtN; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=RX6nUs0A 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 n74v_PbR4H75; Thu, 13 Oct 2016 04:05:15 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC821294B5; Thu, 13 Oct 2016 04:05:15 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id AA15F207E3; Thu, 13 Oct 2016 07:05:14 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute4.internal (MEProxy); Thu, 13 Oct 2016 07:05:14 -0400 DKIM-Signature: v=1; a=rsa-sha1; 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-sasl-enc :x-sasl-enc; s=mesmtp; bh=WR3/kJdX5tZURnV57CjnBcIXAsQ=; b=ILaAMO tNSVGLeADp3yccn7NNYEXMoQiPl1T1luBBYLZFpJ3Mo15kAvAx8Gbz/L3cNerSJj WKZCZ9kHwyng9aFvwhOZPH8USYJvWVCek6jrcuPihyv29900iTFiuY7E8XBQXtaq x0ALv1/eDgqUqK6C1ikMT542OXQGscOqRDcJc= DKIM-Signature: v=1; a=rsa-sha1; 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-sasl-enc:x-sasl-enc; s=smtpout; bh=WR3/kJdX5tZURnV 57CjnBcIXAsQ=; b=RX6nUs0AK6/djnyWPtj2Ate0xdeK60FJHX8yTHebO18WbkG pGJ3I0qA/L02MYnnL0POFXW+hvGcgbJR5zs+pXwuGPgIHmvPORj7F5GjPwJ1EcMM /FdJXyq6HVIdRIm1r4krIEKMtAA9u5fdMc4ywJ0yML+2CvQAa0O1eE6+3K7A= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 8699896EAB; Thu, 13 Oct 2016 07:05:14 -0400 (EDT) Message-Id: <1476356714.1601674.754646289.1E106782@webmail.messagingengine.com> X-Sasl-Enc: jsmwp+AmTKSOW2r3B2PKoQUaIkK01bcEevLBcdkGNKIj 1476356714 From: Alexey Melnikov To: consultancy@vanderstok.org, Spencer Dawkins MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-cdbff290 Date: Thu, 13 Oct 2016 12:05:14 +0100 In-Reply-To: <3ad76e63e6f6b955b5373a5521bcca98@xs4all.nl> References: <147628802464.6377.2774521252462284021.idtracker@ietfa.amsl.com> <3ad76e63e6f6b955b5373a5521bcca98@xs4all.nl> Archived-At: Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org Subject: Re: [core] Spencer Dawkins' Discuss on draft-ietf-core-etch-03: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 11:05:17 -0000 Hi Peter, On Thu, Oct 13, 2016, at 11:43 AM, peter van der Stok wrote: > Hi Spencer, > > Thanks for your DISCUSS; I will try to respond to it. > > There have been discussions in the WG about the utility of PATCH next to > iPATCH. > Good reasons were put forward to maintain both. > Also the wish was expressed to only allow idem-potent requests and be > able to implement iPATCH without the PATCH counterpart. > > Sending a PATCH request to an iPATCH only server will result in a CoAP > error 4.05 method not allowed > > If I understand correctly, your concern is a non-idempotent request sent > to an iPATCH server. > > In section 3.4 there is text about server reactions to inappropriate > payloads. > In particular the response code: Unprocessable request applies: > when processing the request makes the resource invalid. > We might add (e.g. non idem-potent request to iPATCH) > > Does this answer your concern? Does this mean that a client that wants doesn't care about idempotency of its request might need to try PATCH, then discover that it is not supported and then retry iPATCH? > Greetings, > > peter > > > Spencer Dawkins schreef op 2016-10-12 18:00: > > Spencer Dawkins has entered the following ballot position for > > draft-ietf-core-etch-03: 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-etch/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I'm following most of your reasoning behind having the twin methods > > PATCH > > and iPATCH, but I'm struggling a bit that there's nothing that I saw > > that > > prevents a problem when the client implements only PATCH and the server > > implements only iPATCH. > > > > The only text I saw that provides guidance about which method to > > implement is > > > > A client can mark a request as idempotent by using the iPATCH method > > instead of the PATCH method. This is the only difference between > > the > > two. The indication of idempotence may enable the server to keep > > less state about the interaction; some constrained servers may only > > implement the iPATCH variant for this reason. > > > > Maybe I missed something? > > > > If not, I saw > > > > There is no guarantee that a resource can be modified with PATCH or > > iPATCH. > > > > so, maybe that mismatch isn't going to be a problem in practice, but it > > seems sad that you might have a patchable resource, that can't be > > patched > > because of that mismatch. > > > > I'm not asking for "clients MUST implement iPATCH if you implement > > PATCH" > > (which would accommodate servers that only implement iPATCH), but I > > wonder if the working group talked about a way to avoid this mismatch? > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I was a bit uneasy with the "nearly" in > > > > The security considerations for PATCH or iPATCH are nearly identical > > to the security considerations for PUT ([RFC7252]). > > > > with no explanation of any differences, but I'll leave that for the SEC > > ADs to pick up on if it matters. > > > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > From nobody Thu Oct 13 04:15:12 2016 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 5467212972E; Thu, 13 Oct 2016 04:15:11 -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 Ti3yZs-5urJD; Thu, 13 Oct 2016 04:15: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 137E312966D; Thu, 13 Oct 2016 04:15: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 u9DBEvsu019145; Thu, 13 Oct 2016 13:14:57 +0200 (CEST) Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3svp6T36vjz3Plg; Thu, 13 Oct 2016 13:14:57 +0200 (CEST) Message-ID: <57FF6CF3.7090703@tzi.org> Date: Thu, 13 Oct 2016 13:16:03 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Alexey Melnikov References: <147628802464.6377.2774521252462284021.idtracker@ietfa.amsl.com> <3ad76e63e6f6b955b5373a5521bcca98@xs4all.nl> <1476356714.1601674.754646289.1E106782@webmail.messagingengine.com> In-Reply-To: <1476356714.1601674.754646289.1E106782@webmail.messagingengine.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: core-chairs@ietf.org, draft-ietf-core-etch@ietf.org, Spencer Dawkins , core@ietf.org, The IESG Subject: Re: [core] Spencer Dawkins' Discuss on draft-ietf-core-etch-03: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 11:15:11 -0000 Alexey Melnikov wrote: > Does this mean that a client that wants doesn't care about idempotency > of its request might need to try PATCH, then discover that it is not > supported and then retry iPATCH? How does it know that the server supports one of these methods (PATCH, iPATCH) in the first place, and what media types to use with one of these? This is usually found out using discovery (for an example, see the form relations concept introduced in draft-hartke-core-apps). This discovery would also tell the client which specific method to use, so there is no need for trial and error. What we could add is a recommendation for servers to always support both methods (that is not hard to do, because what follows), and emphasize that there is no particular onus *on the server* to check the client's intention that the request be idempotent. Grüße, Carsten From nobody Thu Oct 13 04:15:52 2016 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 E9DCE12972F; Thu, 13 Oct 2016 04:15:44 -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, HTML_MESSAGE=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 ioJbiD-UHRiG; Thu, 13 Oct 2016 04:15:42 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 0F09912972E; Thu, 13 Oct 2016 04:15:42 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id t193so50732303ywc.2; Thu, 13 Oct 2016 04:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G9/w5xMGgLo7F5kPgCUokKqoVirKJKYkGG5u7FD2drg=; b=Tczff0kfRSC8VYi38TStABSq+sD2G13tZeMuTVnz5waNZzBXMQadx5D73IrbYpn6RE B8JwePdn+MOL0dOFkF4hSzfWuUscMjkvAtRhv04oYTqrCprarBhO8fSuiv1eh3HqEAeT Jccsyo9/AtbXBQAuEW4aigYyJMVUpkLVDC2AFwhDo2tYzkjXHnbQitBXYGZSboiF0BoO 0RIako625X+D/LXbfYFBst6VbPPDP8e6gesy/axsBy1oK3OayaNBtMNI9KQcOGM5rEJ3 qmTRsKxVE710wQWA13Y1puNmC8sKseWlN0lSlzrbj9sLCEV/8gqcEbFAvM2ZIM4gEXjQ oHMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G9/w5xMGgLo7F5kPgCUokKqoVirKJKYkGG5u7FD2drg=; b=G2C+gBeWCypEWE4V5c65qWYfJjEiAGvoFyB5LH7N4PLdZviPg1OTXuLItjzj08u6iD RcAW+NG0+XanJZ9U77roX7ASmVL5v2cIfctA51gdzNwVmDHhSwTDlewmg0RXJC63+in2 vY7VtEjsudWVg+00B4+hnPo4jdKv0nbhu/JTRpVhyXrvY18C5K9QfMdeeEjn9dQlhUsG /bu4RpMdXJ5GkRVIDAIHPGRgMCcrXRG30csCpTH1bH8buh89hdKZKREI+J9+lDZa2iqr xLHKtaWPLSmSgn8R4/VjepiBlkylJsIpaJ7cds1eHSMIb4lmIeZv1U59UihbF9s3hMAi yfzw== X-Gm-Message-State: AA6/9RkuFa5kH1t4fdiH8AnPUwcLJyt1UBXO+cmFH8tKYcJTD+t+Pe8oOIQd/Qs4lYtor+eHNImHtYtOO44Now== X-Received: by 10.13.219.146 with SMTP id d140mr5045803ywe.61.1476357341332; Thu, 13 Oct 2016 04:15:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.92.67 with HTTP; Thu, 13 Oct 2016 04:15:40 -0700 (PDT) Received: by 10.37.92.67 with HTTP; Thu, 13 Oct 2016 04:15:40 -0700 (PDT) In-Reply-To: <1476356714.1601674.754646289.1E106782@webmail.messagingengine.com> References: <147628802464.6377.2774521252462284021.idtracker@ietfa.amsl.com> <3ad76e63e6f6b955b5373a5521bcca98@xs4all.nl> <1476356714.1601674.754646289.1E106782@webmail.messagingengine.com> From: Spencer Dawkins at IETF Date: Thu, 13 Oct 2016 06:15:40 -0500 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a114fa2cae44b09053ebd3af7 Archived-At: Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, iesg@ietf.org, core@ietf.org Subject: Re: [core] Spencer Dawkins' Discuss on draft-ietf-core-etch-03: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 11:15:45 -0000 --001a114fa2cae44b09053ebd3af7 Content-Type: text/plain; charset=UTF-8 Hi, Peter, On Oct 13, 2016 06:05, "Alexey Melnikov" wrote: > > Hi Peter, > > On Thu, Oct 13, 2016, at 11:43 AM, peter van der Stok wrote: > > Hi Spencer, > > > > Thanks for your DISCUSS; I will try to respond to it. > > > > There have been discussions in the WG about the utility of PATCH next to > > iPATCH. > > Good reasons were put forward to maintain both. > > Also the wish was expressed to only allow idem-potent requests and be > > able to implement iPATCH without the PATCH counterpart. This all makes sense to me, and I'm not challenging it. > > Sending a PATCH request to an iPATCH only server will result in a CoAP > > error 4.05 method not allowed > > > > If I understand correctly, your concern is a non-idempotent request sent > > to an iPATCH server. > > > > In section 3.4 there is text about server reactions to inappropriate > > payloads. > > In particular the response code: Unprocessable request applies: > > when processing the request makes the resource invalid. > > We might add (e.g. non idem-potent request to iPATCH) > > > > Does this answer your concern? > > Does this mean that a client that wants doesn't care about idempotency > of its request might need to try PATCH, then discover that it is not > supported and then retry iPATCH? What Alexey said, plus "and because we expect some servers will only support iPATCH, if a client doesn't retry with iPATCH, the client may fail to modify a resource that can be modified, but only using iPATCH". Is that clearer? Spencer > > Greetings, > > > > peter > > > > > > Spencer Dawkins schreef op 2016-10-12 18:00: > > > Spencer Dawkins has entered the following ballot position for > > > draft-ietf-core-etch-03: 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-etch/ > > > > > > > > > > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > I'm following most of your reasoning behind having the twin methods > > > PATCH > > > and iPATCH, but I'm struggling a bit that there's nothing that I saw > > > that > > > prevents a problem when the client implements only PATCH and the server > > > implements only iPATCH. > > > > > > The only text I saw that provides guidance about which method to > > > implement is > > > > > > A client can mark a request as idempotent by using the iPATCH method > > > instead of the PATCH method. This is the only difference between > > > the > > > two. The indication of idempotence may enable the server to keep > > > less state about the interaction; some constrained servers may only > > > implement the iPATCH variant for this reason. > > > > > > Maybe I missed something? > > > > > > If not, I saw > > > > > > There is no guarantee that a resource can be modified with PATCH or > > > iPATCH. > > > > > > so, maybe that mismatch isn't going to be a problem in practice, but it > > > seems sad that you might have a patchable resource, that can't be > > > patched > > > because of that mismatch. > > > > > > I'm not asking for "clients MUST implement iPATCH if you implement > > > PATCH" > > > (which would accommodate servers that only implement iPATCH), but I > > > wonder if the working group talked about a way to avoid this mismatch? > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > I was a bit uneasy with the "nearly" in > > > > > > The security considerations for PATCH or iPATCH are nearly identical > > > to the security considerations for PUT ([RFC7252]). > > > > > > with no explanation of any differences, but I'll leave that for the SEC > > > ADs to pick up on if it matters. > > > > > > > > > _______________________________________________ > > > core mailing list > > > core@ietf.org > > > https://www.ietf.org/mailman/listinfo/core > > --001a114fa2cae44b09053ebd3af7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi, Peter,

On Oct 13, 2016 06:05, "Alexey Melnikov" <aamelnikov@fastmail.fm> wrote:<= br> >
> Hi Peter,
>
> On Thu, Oct 13, 2016, at 11:43 AM, peter van der Stok wrote:
> > Hi Spencer,
> >
> > Thanks for your DISCUSS; I will try to respond to it.
> >
> > There have been discussions in the WG about the utility of PATCH = next to
> > iPATCH.
> > Good reasons were put forward to maintain both.
> > Also the wish was expressed to only allow idem-potent requests an= d be
> > able to implement iPATCH without the PATCH counterpart.

This all makes sense to me, and I'm not challenging it.<= /p>

> > Sending a PATCH request to an iPATCH only server w= ill result in a CoAP
> > error 4.05 method not allowed
> >
> > If I understand correctly, your concern is a non-idempotent reque= st sent
> > to an iPATCH server.
> >
> > In section 3.4 there is text about server reactions to inappropri= ate
> > payloads.
> > In particular the response code: Unprocessable request applies: > > when processing the request makes the resource invalid.
> > We might add (e.g. non idem-potent request to iPATCH)
> >
> > Does this answer your concern?
>
> Does this mean that a client that wants doesn't care about idempot= ency
> of its request might need to try PATCH, then discover that it is not > supported and then retry iPATCH?

What Alexey said, plus "and because we expect some serv= ers will only support iPATCH, if a client doesn't retry with iPATCH, th= e client may fail to modify a resource that can be modified, but only using= iPATCH".

Is that clearer?

Spencer

> > Greetings,
> >
> > peter
> >
> >
> > Spencer Dawkins schreef op 2016-10-12 18:00:
> > > Spencer Dawkins has entered the following ballot position fo= r
> > > draft-ietf-core-etch-03: Discuss
> > >
> > > When responding, please keep the subject line intact and rep= ly 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 position= s.
> > >
> > >
> > > The document, along with other ballot positions, can be foun= d here:
> > > https://datatracker.ietf.org/doc/draft-ietf-core-etch/
> > >
> > >
> > >
> > > ------------------------------------------------------------= ----------
> > > DISCUSS:
> > > ------------------------------------------------------------= ----------
> > >
> > > I'm following most of your reasoning behind having the t= win methods
> > > PATCH
> > > and iPATCH, but I'm struggling a bit that there's no= thing that I saw
> > > that
> > > prevents a problem when the client implements only PATCH and= the server
> > > implements only iPATCH.
> > >
> > > The only text I saw that provides guidance about which metho= d to
> > > implement is
> > >
> > >=C2=A0 =C2=A0 A client can mark a request as idempotent by us= ing the iPATCH method
> > >=C2=A0 =C2=A0 instead of the PATCH method.=C2=A0 This is the = only difference between
> > > the
> > >=C2=A0 =C2=A0 two.=C2=A0 The indication of idempotence may en= able the server to keep
> > >=C2=A0 =C2=A0 less state about the interaction; some constrai= ned servers may only
> > >=C2=A0 =C2=A0 implement the iPATCH variant for this reason. > > >
> > > Maybe I missed something?
> > >
> > > If not, I saw
> > >
> > >=C2=A0 =C2=A0 There is no guarantee that a resource can be mo= dified with PATCH or
> > >=C2=A0 =C2=A0 iPATCH.
> > >
> > > so, maybe that mismatch isn't going to be a problem in p= ractice, but it
> > > seems sad that you might have a patchable resource, that can= 't be
> > > patched
> > > because of that mismatch.
> > >
> > > I'm not asking for "clients MUST implement iPATCH i= f you implement
> > > PATCH"
> > > (which would accommodate servers that only implement iPATCH)= , but I
> > > wonder if the working group talked about a way to avoid this= mismatch?
> > >
> > >
> > > ------------------------------------------------------------= ----------
> > > COMMENT:
> > > ------------------------------------------------------------= ----------
> > >
> > > I was a bit uneasy with the "nearly" in
> > >
> > >=C2=A0 =C2=A0 The security considerations for PATCH or iPATCH= are nearly identical
> > >=C2=A0 =C2=A0 to the security considerations for PUT ([RFC725= 2]).
> > >
> > > with no explanation of any differences, but I'll leave t= hat for the SEC
> > > ADs to pick up on if it matters.
> > >
> > >
> > > _______________________________________________
> > > core mailing list
> > > core@ietf.org
> > > https= ://www.ietf.org/mailman/listinfo/core
> >

--001a114fa2cae44b09053ebd3af7-- From nobody Thu Oct 13 04:19:24 2016 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 346A5129732; Thu, 13 Oct 2016 04:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.997 X-Spam-Level: X-Spam-Status: No, score=-4.997 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=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 6euYPs197sng; Thu, 13 Oct 2016 04:19:14 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id C3BC012972F; Thu, 13 Oct 2016 04:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1476357554; d=isode.com; s=june2016; i=@isode.com; bh=PU+DI0VzeW1BgfMOannjXSzndRGj3qsIJLY5OUvD79s=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=vqHI0ZR89SFZXEdop0J62spottyB8/DdBKfjE0FQ3FtCUFyfjfep2ZkrLodUPfT6kx2QLj LZK82j28vlrkMObvCI7SAyw005s3L2usi57BjzHk1TpQ+N8khhshaBwmE96kEZK2PhQH3/ ZeJgS+Y++UuwCNGtoGYugAwUgEc1IYc=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 13 Oct 2016 12:19:13 +0100 To: Carsten Bormann , Alexey Melnikov References: <147628802464.6377.2774521252462284021.idtracker@ietfa.amsl.com> <3ad76e63e6f6b955b5373a5521bcca98@xs4all.nl> <1476356714.1601674.754646289.1E106782@webmail.messagingengine.com> <57FF6CF3.7090703@tzi.org> From: Alexey Melnikov Message-ID: Date: Thu, 13 Oct 2016 12:18:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: <57FF6CF3.7090703@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, Spencer Dawkins , core@ietf.org, The IESG Subject: Re: [core] Spencer Dawkins' Discuss on draft-ietf-core-etch-03: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 11:19:16 -0000 Hi Carsten, On 13/10/2016 12:16, Carsten Bormann wrote: > Alexey Melnikov wrote: >> Does this mean that a client that wants doesn't care about idempotency >> of its request might need to try PATCH, then discover that it is not >> supported and then retry iPATCH? > How does it know that the server supports one of these methods (PATCH, > iPATCH) in the first place, and what media types to use with one of > these? This is usually found out using discovery (for an example, see > the form relations concept introduced in draft-hartke-core-apps). This > discovery would also tell the client which specific method to use, so > there is no need for trial and error. This would be a useful text to add. > What we could add is a recommendation for servers to always support both > methods (that is not hard to do, because what follows), and emphasize > that there is no particular onus *on the server* to check the client's > intention that the request be idempotent. Sound good to me! From nobody Thu Oct 13 05:18:40 2016 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 B401F12943B; Thu, 13 Oct 2016 05:18:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147636111873.2840.15922934637733990470.idtracker@ietfa.amsl.com> Date: Thu, 13 Oct 2016 05:18:38 -0700 Archived-At: Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, core@ietf.org, jiangsheng@huawei.com Subject: [core] Benoit Claise's No Objection on draft-ietf-core-etch-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 12:18:39 -0000 Benoit Claise has entered the following ballot position for draft-ietf-core-etch-03: 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-etch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [reflections on core, as opposed to actionable items for the document] Coming back to Alissa's DISCUSS and Sheng Jiang's OPS DIR review: This Standards Track document defines a new CoAP methods, FETCH, to perform the equivalent of a GET with a request body; and the twin methods PATCH and iPATCH, to modify parts of a CoAP resource. This document is well written. I don't see any major issues from the operations and management perspective. It is almost ready to be published. There are one of potential major (the word potential means I don’t really sure how serious it may be) comments from me: In section 2.5, it raises an issue that “a FETCH request cannot be generated from a link alone, but also needs a way to generate the request payload.” From the discussion text, I am not sure whether there are existing way to generate the request payload or not. And I am not sure whether the FECTCH method needs a standard such way to be able to work or not. If the answer for my first question is no, or the question for my second question is yes. Then we probably have an major issue here. I wish my suspecting is wrong. I would like to make sure I understand (with my OPS background,): - COAP (RFC7252) is about HTTP GET, POST, PUT, DELETE for constrained nodes and constrained environments - draft-ietf-core-etch specification specifies the new CoAP methods, FETCH, PATCH and iPATCH, which are used to access and update parts of a resource. - CBOR (RFC7049) is the binary encoding of JSON for COAP. And for draft-ietf-core-etch, I guess? - There are two data modeling language in CORE YANG: draft-ietf-core-yang-cbor-02 provides the mapping for YANG data models encoding: CBOR SenML: draft-ietf-core-senml-02 provides Media Types for Sensor Markup Language encodings: JSON, CBOR, XML, EXI Good so far? Coming to Alissa's DISCUSS: It seems that FETCH is not a useful operation unless the server is capable of understanding what it is supposed to fetch. So it's not true that "any" media type can be used, but rather only those media types for which a definition exists for what the fetch parameters indicate and which part of the resource they are intended to delineate. Shouldn't the use of FETCH be constrained to such media types? So what we're missing for this to work is the equivalent of RESTCONF for constrained nodes/networks - Either "CoAP Management Interface", draft-vanderstok-core-comi-09 (btw this draft expired...) - Or Constrained Objects Language, draft-veillette-core-cool-02 Note: COMI is mentioned in the draft, but not COOL Is this what is meant behind? it is outside the scope of this document how information about admissible media types is obtained by the client There is a clear parallel with RESTCONF (REST-like) and the CORE work: NETMOD/NETCONF CORE Data Modeling Language YANG YANG or SenML (*) Data Models YANG Module YANG Module or SenML (*) Encoding XML, JSON CBOR for YANG, JSON/CBOR/XML/EXI for SENML Protocol HTTP for RESTCONF COAP Mgmt Protocol RESTCONF/NETCONF COMI or COOL for YANG, for SenML?? (**) (*) not sure if SenML is a data modeling language or data models (**) not sure if a specific mgmt protocol for SenML Please let me know. Regards, Benoit From nobody Thu Oct 13 05:44:24 2016 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 37C2B129755; Thu, 13 Oct 2016 05:44:16 -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, HTML_MESSAGE=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 5HLj0_1ZTGXI; Thu, 13 Oct 2016 05:44:13 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c: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 A843E129423; Thu, 13 Oct 2016 05:44:13 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id 2so75805376vkb.3; Thu, 13 Oct 2016 05:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U7LXN8Gz5OvWNztMNznM34z/4VizJxLUD1OoVtzTFV8=; b=A9vrdiGbssa3O5UBy3rvkBIhcBAnDxgyFCFe+TEPUsrA4T5ueYLwpYc4sTMm5N5Vk2 w1y36YF2Yeu8ekIiVyre9e0qrGAxFcaM40I4uAz/yuhG80nBS5NvfmO1B6qTo4/egltc sWbIx13iuOdyniERZ7fTBaJcR2p6reHw8TdEfiz+BGnHhFCqNNogox7wb5oxa9BRky/D 8IWb58DJv0e5nVKn17AZWHW0+n1VbpqcK6OS1EcyHi4m1ZSYsHf7kLuoVjjFFOTwSdCE bwZuCsvi9KTo/YBRrbA3Y0qFQyLW6nE6nbdsRsZL0Mzg4UW99UX5gQ3KEYzC0r+rEOEI Poww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U7LXN8Gz5OvWNztMNznM34z/4VizJxLUD1OoVtzTFV8=; b=YzpL2f6cQ8NxQGnkZYzvleTKFceWlFErEri9Pb2Q/z328b0rlfHcCh/zlck8MtUMLG Z5qQHYRJnJI/dUBKf7dFV7QR4JT55iMMIqjMv6Bn+K13RU+Li3WRaLfJZ9UqQiDjAU6+ u3Of7bL/A1AEMFOg44hDTZScN1i0K/8f2zOlQXGHiJ1JUWOY8SLzBvGSS1jZHLNRYbvO Nj2qGhCION2FXuXfsLemLZkQFTkBnYAH95BUBA9SIJULoZh1j5SiboB/WZ5CDyVFxjzs peNLyRSENMbh7Sqs7dZpEwr5w2Fur+qcIoPHh1twNTtG1c+WuA9Qp1q0Q6ImKCI06s90 GG0g== X-Gm-Message-State: AA6/9RmjM8zBRF+wB5gO1p9cTUaNVrbmOXVrBEncJ66sl3SwaFhI3Uxw0vn0cTlLGy6EPodLf7KfryNAUqyXhg== X-Received: by 10.31.56.204 with SMTP id f195mr4417705vka.61.1476362652762; Thu, 13 Oct 2016 05:44:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.68 with HTTP; Thu, 13 Oct 2016 05:44:12 -0700 (PDT) In-Reply-To: <57FF3EC8.8080605@tzi.org> References: <147629362183.6297.18321888937912730256.idtracker@ietfa.amsl.com> <57FF3EC8.8080605@tzi.org> From: Kathleen Moriarty Date: Thu, 13 Oct 2016 08:44:12 -0400 Message-ID: To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a1144005c7a6c5a053ebe773c Archived-At: Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, The IESG , "core@ietf.org WG" Subject: Re: [core] Kathleen Moriarty's Discuss on draft-ietf-core-etch-03: (with DISCUSS) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 13 Oct 2016 12:44:16 -0000 --001a1144005c7a6c5a053ebe773c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, On Thu, Oct 13, 2016 at 3:59 AM, Carsten Bormann wrote: > Hi Kathleen, > > thank you for this review. > > Maybe I'm not reading this right, but a lot of what you are saying > sounds like considerations that apply to all of CoAP's methods. These > should already be covered by the security considerations of RFC 7252, > which we do refer to. Please do read my discuss again. The main point I started off with is that the reference to section 9 of 7252 includes all of the options for COAP security, which includes no encryption or authentication. I am asking for specific requirements to this method as was done in 5789. Since the security considerations section is just a set of pointers to drafts with different options and requirements, it is not clear what applies to the FETCH, PATCH, and iPATCH methods. Specific to PATCH, I then pointed out an attack type where a resource that should not be authorized is able to get an update or modification. The more obvious case of a resource getting a malicious update may already be covered, but the case I am pointing out specific to PATCH is not covered. I pointed to a specific sentence in RFC5789 that I would like to see repeated so the requirements for these methods are clear. If you look at the security considerations section of this draft, it starts out with the most generic pointer to RFC7252 section 9 that includes all options. Then it starts to get more specific and it seems to tighten up the requirements, but then finishes referring to section 9 of RFC7252 that includes all of the methods, including nosec, again. This is confusing. As such, adding a sentence or two on the specific security considerations for this draft is important. I'd also like to see mention of the threat I pointed out in my discuss unless you can explain how that is not applicable (which I don't think is the case) to IoT. I've had to work on the remediation and prevention of that specific attack type for other devices and it's hit most (if not all) big vendors. > Alissa indeed had an observation about a security > consideration that is specific to FETCH that we had overlooked, and we > have added that in the editors' draft. > I'm not sure how this is helpful here and it's probably better that you don't expand on it. Thank you, Kathleen > I can't really make out which of your comments indicate security > considerations specific to FETCH, or to PATCH/iPATCH, or to both, that > are not already covered by RFC 7252. > > Gr=C3=BC=C3=9Fe, Carsten > > > Kathleen Moriarty wrote: > > Kathleen Moriarty has entered the following ballot position for > > draft-ietf-core-etch-03: 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-etch/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I'd like to see more of the actual requirements for this draft in the > > security considerations as the pointers include all of the configuratio= n > > options for DTLS, including the "nosec" option. I would think this > > operation would require authentication to prevent unauthorized access b= y > > devices that are clones. This is a real problem in the non-IoT space f= or > > firmware updates and will be a problem in this space if it isn't alread= y > > - knock off hardware that installs the firmware of a popular product. = In > > In section 5 of RFC5789, I see this: > > These > > include authorizing requests (possibly through access control and/or > > authentication) and ensuring that data is not corrupted through > > transport errors or through accidental overwrites. > > > > And would like to see something similar in this section to at least lis= t > > some of the requirements and reasoning. For patch and fetch, I think t= he > > reason outlined above needs to be included as well so it is top of mind > > for implementers and they are aware of this very real threat. It is > > important they understand why they need authentication and encryption t= o > > prevent attacks against their brand. If someone buys knock-off hardwar= e > > that is faulty and uses their firmware, they have multiple problems to > > deal with, not just the loss of sales. > > > > > > > > > > > --=20 Best regards, Kathleen --001a1144005c7a6c5a053ebe773c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carsten,

On Thu, Oct 13, 2016 at 3:59 AM, Carsten Bormann <cabo@tzi.org&g= t; wrote:
Hi Kathleen,

thank you for this review.

Maybe I'm not reading this right, but a lot of what you are saying
sounds like considerations that apply to all of CoAP's methods.=C2=A0 T= hese
should already be covered by the security considerations of RFC 7252,
which we do refer to.=C2=A0

Please do read= my discuss again.=C2=A0 The main point I started off with is that the refe= rence to section 9 of 7252 includes all of the options for COAP security, w= hich includes no encryption or authentication.=C2=A0 I am asking for specif= ic requirements to this method as was done in 5789.=C2=A0 Since the securit= y considerations section is just a set of pointers to drafts with different= options and requirements, it is not clear what applies to the FETCH, PATCH= , and iPATCH methods.

Specific to PATCH, I then po= inted out an attack type where a resource that should not be authorized is = able to get an update or modification.=C2=A0 The more obvious case of a res= ource getting a malicious update may already be covered, but the case I am = pointing out specific to PATCH is not covered.=C2=A0 I pointed to a specifi= c sentence in RFC5789 that I would like to see repeated so the requirements= for these methods are clear.

If you look at the s= ecurity considerations section of this draft, it starts out with the most g= eneric pointer to RFC7252 section 9 that includes all options.=C2=A0 Then i= t starts to get more specific and it seems to tighten up the requirements, = but then finishes referring to section 9 of RFC7252 that includes all of th= e methods, including nosec, again.

This is confusi= ng.=C2=A0 As such, adding a sentence or two on the specific security consid= erations for this draft is important.=C2=A0 I'd also like to see mentio= n of the threat I pointed out in my discuss unless you can explain how that= is not applicable (which I don't think is the case) to IoT.=C2=A0 I= 9;ve had to work on the remediation and prevention of that specific attack = type for other devices and it's hit most (if not all) big vendors.

=C2=A0
Alissa inde= ed had an observation about a security
consideration that is specific to FETCH that we had overlooked, and we
have added that in the editors' draft.

<= div>I'm not sure how this is helpful here and it's probably better = that you don't expand on it.


Th= ank you,
Kathleen

=C2=A0
I can't really make out which of your comments indicate security
considerations specific to FETCH, or to PATCH/iPATCH, or to both, that
are not already covered by RFC 7252.

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


Kathleen Moriarty wrote:
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-core-etch-03: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/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/dra= ft-ietf-core-etch/
>
>
>
> ------------------------------------------------------------= ----------
> DISCUSS:
> ------------------------------------------------------------= ----------
>
> I'd like to see more of the actual requirements for this draft in = the
> security considerations as the pointers include all of the configurati= on
> options for DTLS, including the "nosec" option.=C2=A0 I woul= d think this
> operation would require authentication to prevent unauthorized access = by
> devices that are clones.=C2=A0 This is a real problem in the non-IoT s= pace for
> firmware updates and will be a problem in this space if it isn't a= lready
> - knock off hardware that installs the firmware of a popular product.= =C2=A0 In
> In section 5 of RFC5789, I see this:
>=C2=A0 =C2=A0 These
>=C2=A0 =C2=A0 include authorizing requests (possibly through access con= trol and/or
>=C2=A0 =C2=A0 authentication) and ensuring that data is not corrupted t= hrough
>=C2=A0 =C2=A0 transport errors or through accidental overwrites.
>
> And would like to see something similar in this section to at least li= st
> some of the requirements and reasoning.=C2=A0 For patch and fetch, I t= hink the
> reason outlined above needs to be included as well so it is top of min= d
> for implementers and they are aware of this very real threat.=C2=A0 It= is
> important they understand why they need authentication and encryption = to
> prevent attacks against their brand.=C2=A0 If someone buys knock-off h= ardware
> that is faulty and uses their firmware, they have multiple problems to=
> deal with, not just the loss of sales.
>
>
>
>
>



--
=

Best regards,
Kathleen
--001a1144005c7a6c5a053ebe773c-- From nobody Thu Oct 13 06:30:31 2016 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 151611296DE; Thu, 13 Oct 2016 06:30:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147636542607.2926.13009154365554998886.idtracker@ietfa.amsl.com> Date: Thu, 13 Oct 2016 06:30:26 -0700 Archived-At: Cc: core-chairs@ietf.org, core@ietf.org, draft-ietf-core-http-mapping@ietf.org Subject: [core] Benoit Claise's No Objection on draft-ietf-core-http-mapping-15: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 13:30:26 -0000 Benoit Claise has entered the following ballot position for draft-ietf-core-http-mapping-15: 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-http-mapping/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Previous DISCUSS point: One point I would like to DISCUSS: I wonder if this document is not already obsolete, now that we have the new FETCH/iPATCH/PATCH methods (draft-ietf-core-etch)? Should we expect an update document for the new mappings? Don't we need at least a reference to draft-ietf-core-etch, expressing it's not covered? The point has been discussed, so moving to a COMMENT. I trust the responsible AD to take the right action. Regards, Benoit From nobody Thu Oct 13 06:58:12 2016 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 3547C1298D1 for ; Thu, 13 Oct 2016 06:58:09 -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=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 p_joPld14DAM for ; Thu, 13 Oct 2016 06:58:07 -0700 (PDT) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973671298CE for ; Thu, 13 Oct 2016 06:58:03 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.212]) by smtp-cloud2.xs4all.net with ESMTP id v1y01t00S4aYjWA011y0l8; Thu, 13 Oct 2016 15:58:01 +0200 Received: from AMontpellier-654-1-168-251.w92-145.abo.wanadoo.fr ([92.145.35.251]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 13 Oct 2016 15:58:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 13 Oct 2016 15:58:00 +0200 From: peter van der Stok To: Benoit Claise Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <147636111873.2840.15922934637733990470.idtracker@ietfa.amsl.com> References: <147636111873.2840.15922934637733990470.idtracker@ietfa.amsl.com> Message-ID: <22c969b1603799a0cfd6bb73217c719c@xs4all.nl> X-Sender: stokcons@xs4all.nl (2HqHKl2iaOy8alcTsNOh3upP5BJ/06wa) User-Agent: XS4ALL Webmail Archived-At: Cc: draft-ietf-core-etch@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org, jiangsheng@huawei.com Subject: Re: [core] Benoit Claise's No Objection on draft-ietf-core-etch-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 13:58:09 -0000 Hi Benoit, Thanks for your extensive comment. It contains very valuable feedback. Although you write that your comment exceeds the etch boundaries and refers to CORE as a whole, many of the commented subjects have my name on it. Therefore, I will answer some of your comments and trust that Carsten will expand and complete. See below, please. Benoit Claise schreef op 2016-10-13 14:18: > Benoit Claise has entered the following ballot position for > draft-ietf-core-etch-03: 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-etch/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [reflections on core, as opposed to actionable items for the document] > > Coming back to Alissa's DISCUSS and Sheng Jiang's OPS DIR review: > > This Standards Track document defines a new CoAP methods, FETCH, to > perform the equivalent of a GET with a request body; and the twin > methods > PATCH and iPATCH, to modify parts of a CoAP resource. This document is > well written. I don't see any major issues from the operations and > management perspective. It is almost ready to be published. There are > one > of potential major (the word potential means I don’t really sure how > serious it may be) comments from me: > > In section 2.5, it raises an issue that “a FETCH request cannot be > generated from a link alone, but also needs a way to generate the > request > payload.” From the discussion text, I am not sure whether there are > existing way to generate the request payload or not. And I am not sure > whether the FECTCH method needs a standard such way to be able to work > or > not. If the answer for my first question is no, or the question for my > second question is yes. Then we probably have an major issue here. I > wish > my suspecting is wrong. The answer is a bit less black and white. A draft is in preparation that describes the payload format for the FETCH request in context of CoMI and CoOL. I expect that more drafts in the future will describe payload formats for FETCH requests. > > I would like to make sure I understand (with my OPS background,): > - COAP (RFC7252) is about HTTP GET, POST, PUT, DELETE for constrained > nodes and constrained environments > - draft-ietf-core-etch specification specifies the new CoAP methods, > FETCH, PATCH and iPATCH, which are used to access and update parts of a > resource. > - CBOR (RFC7049) is the binary encoding of JSON for COAP. And for > draft-ietf-core-etch, I guess? YES, but not exclusively. > - There are two data modeling language in CORE > YANG: draft-ietf-core-yang-cbor-02 provides the mapping for YANG > data > models > encoding: CBOR > SenML: draft-ietf-core-senml-02 provides Media Types for Sensor > Markup Language > encodings: JSON, CBOR, XML, EXI > > Good so far? I am sure Carsten can elaborate on those in more detail For my part, you are absolutely correct. > > Coming to Alissa's DISCUSS: > > It seems that FETCH is not a useful operation unless the server is > capable of understanding what it is supposed to fetch. So it's not true > that "any" media type can be used, but rather only those media types > for > which a definition exists for what the fetch parameters indicate and > which part of the resource they are intended to delineate. Shouldn't > the > use of FETCH be constrained to such media types? > > So what we're missing for this to work is the equivalent of RESTCONF > for > constrained nodes/networks > - Either "CoAP Management Interface", draft-vanderstok-core-comi-09 > (btw this draft expired...) > - Or Constrained Objects Language, draft-veillette-core-cool-02 > Note: COMI is mentioned in the draft, but not COOL CoMI will be the basis that uses FETCH, PATCH, iPATCH; CoOL will expand on that > > Is this what is meant behind? yes, and other applications beyond > > it is > outside the scope of this document how information about admissible > media types is obtained by the client > > > > There is a clear parallel with RESTCONF (REST-like) and the CORE work: > > NETMOD/NETCONF > CORE > Data Modeling Language YANG > YANG or SenML (*) > Data Models YANG Module > YANG Module or SenML (*) > Encoding XML, JSON > CBOR for YANG, JSON/CBOR/XML/EXI for SENML > Protocol HTTP for RESTCONF > COAP > Mgmt Protocol RESTCONF/NETCONF COMI > or > COOL for YANG, for SenML?? (**) > > (*) not sure if SenML is a data modeling language or data models > (**) not sure if a specific mgmt protocol for SenML > > Please let me know. > > Regards, Benoit > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Oct 14 20:50:36 2016 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 37C69129409; Fri, 14 Oct 2016 20:50:35 -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 p9uJoQYC8Kov; Fri, 14 Oct 2016 20:50:32 -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 767741293E1; Fri, 14 Oct 2016 20:50:32 -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 u9F3oSV1024801; Sat, 15 Oct 2016 05:50:28 +0200 (CEST) Received: from nar-4.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3swr8h0lH6z7xhk; Sat, 15 Oct 2016 05:50:28 +0200 (CEST) Message-ID: <5801A7D0.8050100@tzi.org> Date: Sat, 15 Oct 2016 05:51:44 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: ace@ietf.org, core@ietf.org, cose@ietf.org, dtls-iot@ietf.org, t2trg@irtf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF97: DRAFT AGENDA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 15 Oct 2016 03:50:35 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF97. Remember that there is still quite some potential for changes. IoT is starting a bit late at IETF97; only two meetings of cluster WGs on Mon/Tue (but then of course we start big with the Sunday icnrg/t2trg joint meeting). CORE on HOMENET and IPWAVE (Wed) and CORE on ICNRG (Fri) are a bit painful but probably the unavoidable level of conflict. Moves due to other conflict avoidance may make this worse, though. All times are KST (UTC+0900) -- there is no DST in Korea, and DST will have ended in Europe and North America by then. (The browser timezone function still is not yet reinstated on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Grüße, Carsten SUNDAY, November 13, 2016 1300-1600 IRTF*** icnrg+t2trg joint meeting MONDAY, November 14, 2016 1330-1530 Afternoon Session I Studio 3 ART ice Interactive Connectivity Establishment WG Park BR 1 IRTF cfrg Crypto Forum Grand BR II OPS v6ops IPv6 Operations WG 1550-1750 Afternoon Session II Grand BR III INT *** lpwan IPv6 over Low Power Wide-Area Networks WG Studio 3 RTG bier Bit Indexed Explicit Replication WG TUESDAY, November 15, 2016 0930-1200 Morning Session I Grand BR II INT 6man IPv6 Maintenance WG Park BR 1 RTG detnet Deterministic Networking WG Grand BR I TSV quic QUIC WG 1330-1530 Afternoon Session I Park BR 1 ART httpbis Hypertext Transfer Protocol WG Grand BR I RTG rtgarea Routing Area Open Meeting Studio 4 SEC tokbind Token Binding WG Grand BR III TSV tsvwg Transport Area Working Group WG 1550-1820 Afternoon Session II Grand BR II INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG Park BR 1 SEC tls Transport Layer Security WG WEDNESDAY, November 16, 2016 0930-1100 Morning Session I Grand BR III OPS anima Autonomic Networking Integrated Model and Approach WG Grand BR II TSV taps Transport Services WG 1110-1210 Morning Session II Park BR 2 RTG *** roll Routing Over Low power and Lossy networks WG Grand BR I TSV tsvwg Transport Area Working Group WG 1330-1500 Afternoon Session I Studio 2 ART *** core Constrained RESTful Environments WG Grand BR I INT homenet Home Networking WG Grand BR III INT ipwave IP Wireless Access in Vehicular Environments WG Studio 4 SEC acme Automated Certificate Management Environment WG Grand BR II TSV tsvarea Transport Area Open Meeting 1520-1620 Afternoon Session II Park BR 2 INT intarea Internet Area Working Group WG Park BR 1 IRTF*** t2trg Thing-to-Thing Studio 3 SEC curdle CURves, Deprecating and a Little more Encryption WG THURSDAY, November 17, 2016 0930-1100 Morning Session I Park BR 1 INT *** 6tisch IPv6 over the TSCH mode of IEEE 802.15.4e WG Studio 4 INT dnssd Extensions for Scalable DNS Service Discovery WG Grand BR II IRTF maprg Measurement and Analysis for Protocols Grand BR I SEC saag Security Area Open Meeting 1110-1210 Morning Session II Park BR 1 ART httpbis Hypertext Transfer Protocol WG Grand BR III INT *** lwig Light-Weight Implementation Guidance WG Grand BR I SEC saag Security Area Open Meeting 1330-1500 Afternoon Session I Studio 3 SEC oauth Web Authorization Protocol WG 1520-1750 Afternoon Session II Studio 4 SEC *** ace Authentication and Authorization for Constrained Environments WG Studio 2 TSV rmcat RTP Media Congestion Avoidance Techniques WG FRIDAY, November 18, 2016 0930-1130 Morning Session I Studio 4 ART *** core Constrained RESTful Environments WG Grand BR II IRTF icnrg Information-Centric Networking Park BR 1 OPS anima Autonomic Networking Integrated Model and Approach WG Park BR 2 TSV tcpinc TCP Increased Security WG 1150-1320 Afternoon Session I Studio 2 ART webpush Web-Based Push Notifications WG Park BR 1 RTG babel Babel routing protocol WG Studio 4 SEC oauth Web Authorization Protocol WG From nobody Sun Oct 16 13:41:11 2016 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 C921F1294F5 for ; Sun, 16 Oct 2016 13:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 G2bf9q-b_e6v for ; Sun, 16 Oct 2016 13:41:07 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0103.outbound.protection.outlook.com [104.47.1.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F00071294AA for ; Sun, 16 Oct 2016 13:41:06 -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=BLKQ9NL7T/d6BwdSuOlQ9LNbfUZnq0WQDTxoPmt0vDA=; b=YmTDy8VkkLOv6gsknudc9WCgiv12Q876Z/ZcVFaQ3zottos68wzVdSxF5l775YXKD7rhFKEDKxEiLyaVWmdEjSNvkgysZPBMfEzHuUElHoapCqS7ECIWng8KoCSf5BsvDopd4m7qebJzWXkvPpqfFSjLyeDR2jVh9oweJqH8WH8= Received: from AM3PR04CA0062.eurprd04.prod.outlook.com (10.164.94.30) by HE1PR04MB1258.eurprd04.prod.outlook.com (10.162.249.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.8; Sun, 16 Oct 2016 20:41:03 +0000 Received: from AM1FFO11FD029.protection.gbl (2a01:111:f400:7e00::110) by AM3PR04CA0062.outlook.office365.com (2a01:111:e400:52b6::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.12 via Frontend Transport; Sun, 16 Oct 2016 20:41:03 +0000 Authentication-Results: spf=none (sender IP is 23.103.247.132) smtp.mailfrom=philips.com; zhaw.ch; dkim=none (message not signed) header.d=none;zhaw.ch; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (23.103.247.132) by AM1FFO11FD029.mail.protection.outlook.com (10.174.64.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.7 via Frontend Transport; Sun, 16 Oct 2016 20:41:03 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com (141.251.190.18) by HE1PR9001MB0172.MGDPHG.emi.philips.com (141.251.190.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Sun, 16 Oct 2016 20:41:02 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) by HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) with mapi id 15.01.0649.027; Sun, 16 Oct 2016 20:41:02 +0000 From: "Dijk, Esko" To: "Doran Hans (donn)" Thread-Topic: Mail regarding draft-ietf-core-coap Thread-Index: AdIi1gCJns8raEy9RU+NylefQpm6dwAA9JhwAUTHRfA= Date: Sun, 16 Oct 2016 20:41:02 +0000 Message-ID: <7211a9dd2c6f464ba7f552634e64a564@HE1PR9001MB0170.MGDPHG.emi.philips.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.85.138.53] X-MS-Office365-Filtering-Correlation-Id: e7a2f807-1dab-4175-2984-08d3f604bf28 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: HE1PR9001MB0172.MGDPHG.emi.philips.com X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:23.103.247.132; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(428002)(189002)(374574003)(85714005)(13464003)(55904004)(199003)(189998001)(66066001)(50986999)(50466002)(69596002)(47776003)(23756003)(3846002)(102836003)(626004)(87936001)(97736004)(6116002)(586003)(16601075003)(81166006)(81156014)(8676002)(4326007)(24736003)(2906002)(8936002)(356003)(11100500001)(68736007)(86362001)(8746002)(16799955002)(2900100001)(15975445007)(10400500002)(105586002)(305945005)(108616004)(230783001)(19580395003)(101416001)(106466001)(2950100002)(5660300001)(7696004)(6916009)(92566002)(110136003)(7736002)(19580405001)(7846002)(76176999)(54356999)(587094005)(33646002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR04MB1258; H:011-smtp-out.Philips.com; FPR:; SPF:None; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD029; 1:Y0dejEVMwQoqmvUEb5QSP55aOTid+voM/29pSDc2i23zMcEk0eY7jqcWHgLSkPaHMKLI5r8WGh4BbMlA/7nljH4G+ubjjLVvxk8/9j+ZsJrtg/Y3PHLHRVZGvpjJyy5RYD5nLD8q3qklgdegRy9latpWPF4gsF3Ym3/V9qH//MkJ44cjSlZThPrIdw2//IZiCOFU26wGJ/OCRKfVTC2pHGTnb4AQPWvLQgxvKX3w7981vjQCdD6wS0BpQ8B4oLJJJLLs6EYurqpbAvPNX7bVrb2OVLJ61ZGvMYcf7UL5A2psSCwrDJs0DTnyLmWFTxWNrce8rWrptgjPmKQ4T7GWKZuedSjhQKq4oQ3DiF4NXrcQy9NvvWXRzBpiww87sqCPdW0nmP+TjsDAghW3s/IML9p/XSd/vBWf2lMly5iLfvxJ11lQ0PWlWy3V8h9mzbFMv0PPNSlwM511G41mZrJPzFJfAO9ZScuyl63jtDwaRDn/KdO2ZluTbDZAUEw3puMk X-CrossPremisesHeadersFiltered: AM1FFO11FD029.protection.gbl X-Microsoft-Exchange-Diagnostics: 1; HE1PR04MB1258; 2:tJSjd70UOQajq3P75dTPt1qgpFnDzoVQnIcHz6yGVg6kMRO1YZCtqeIqzxN8dpWMMG6ur7A6GY3nUwgsaxUh/U5rPR4YMJsqyJtoivO0QmX360HgCAsl9l8S/1RYOqTYBXYNkQjwAEOTqr+w3+rTzIrMhUMY4cb7M4286GYI99L6rKCYrEonhqolfrUP2d1ezirOBmEiafUZk1/v+yNgmA==; 3:uY0brTien2bVHtRK1lrUnAKxxjVTvWel99c1NqDaXHOeQX8bCy5jMExW7J5YgoUrZnKeKZzOhsLSC2oFG+pTpW6FAUXof30nldKEA58Ho5ZewahTDNSwAStSYqWeYLNCxTHuZQnIWf7N+zU2fXdS34S4DhnyzMsYo1ygzo1Rz+HImKinsRM0moHrYzlNCKDdaxe5g+9SGtMw47le4qQRK00b+ECXZ4o04+vN4GAdd3lB2eA5ZkfppXlX35072AZ7 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1258; X-Microsoft-Exchange-Diagnostics: 1; HE1PR04MB1258; 25:Arc+h3YDklAsTMgTkDCsCGM5yXJaY8c+w2vrzW1hf6pmj5YKVykukai6zX0jsv9BJtbPMK5e8gt1plRyq7DOV4J7ZMJ0i/4Ng4s53Ie23qEN8AepEigkXtRyVPWdqRBPH6C8HyNvQXRRpuO/m2lRmY81rS7t1ujzkoC2rkvepl9fnExiWdX8Y8tUq/hgt+USFmIXOId4sY8Zi1AWuC7sEW4V1v3bZJGTe+344ChNUzV2cOjKK50beN0vtWUBeH+P47HlVFcordpkQAiT6X8EIHp1pt3GBbsCNtCualiUXT6vgd2vd9CnEWHXYGMn3yn8mwlMohblfhkN2/WPxicvDf79YVMGKs7wPCWzQCiwk1n5RoM55DY93YMIx9e0DiEg5Nj5Mk3R+M2tcRAZldwKLEXpDPEaepbVEUEwQTphkB3ZlGpW0SupL/eFmvYKaDDeWmSh5fX1gfmsz2rKn1S/vLC55Qv2/ck+2Hmsxdy5qRZmzQ+LKbuCgPSiTxt6deRaobEVkJNFnSQGfAMmrpIX1TW+E0SSezobbZX65ybgTU5RXnJHluf2OBe/n62XU63YmqtGiMS4D9/Tcijz/i6I0nyoEl15lzHpyp017EAuOBz6tdX17nrAA7zWIoXgvfoA9rPVR7ZOfuYhJUHo8OWJ08lFAmVhzuhtywmKPs3ZLlCZD1v9nW17h3tj0Sxja7xxFATzgSGniea/7NoZK1b+H5w+seG4+ojY/M2KKRHktg4cROVjyKk7uGdtsoYFy40WabmOGoEihmoGvWl+wfnT8Z1K4i2JsfUZECgP+fpvaZ+YaYUjiDVOLASoVhINwZlkDC118eDy00BtMAW2dMujBZo9djhLc4M0yxoyTF/Po6Q+MvrG2N1KHl2Yt/nRGoc2 X-Microsoft-Exchange-Diagnostics: 1; HE1PR04MB1258; 31:VOaBxmy//UFpdMOJoRLVK4FmrZHH6DtmYMx9OLgZYEoXGTZA5mcXvFNaVigqTJs1um/e7Q2WVsayvJgr/36LIQhPGogSArXF5Nj2zvQ6T2rJsY/LvFr76mlX1fh6945RxKTL3cG1XXWlCrPOav4rbW+I/gwjOkUDE9e6MV6MQs1Jn6oKq7uFSK7zWWvz+rimu70ynDYngPtXH/qFLApvNvAXtVdzGl1ZsSJj7lFSgo8gjGF2/c3Kzh0hatZMSlI0nmx2swHa17+VZIXQYSjhLQ==; 20:/YfC6wfgY27NG+jivc85rQCfxbSLsAknrmXOZdG6gGb+/GOUGTPxHquK95ilC5RjR+ruQ08z7jjCqKs5X1wLBHNI+7un/0J+3+VLi8lfCBzWHbEd42lRQrXyUdAr6gIbx5X7TXqYf+zIOJYhuE7bVDTsnYpby/Xjpm0CRXb5oVQHwOfil1XcWL9SgAh27MtdZA6Y55jx41PWJNhyjdSj1ibjnB+0UyeoVk/tMZd7qwR6Wi9o3fbLvz6snknkgH4+64EKDArg8OwTNjWvAraYKyTll9K+7sBUL3bhMHejMptfkk8ue0mbI/svKy0Bh02GOwRNFngUtLIvsr4Wu7nh73gSOzZIJRE0dWCI1USVJfXbkr3QHs55ftXt1rTSZP98c1eeRgKHwFxAVpz698ZnTqEq21u0gbe7cGLsmMyvg2YCVAaK7IVK+ZQtTFCjzqoiIR/ErdF1c5RkwyzXP993BHzA5m1NzRH9E+VcvzJdBjjgHQTUeNAbpi+ld8QnNN3I X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(13016025)(13018025)(3002001)(10201501046)(6055026); SRVR:HE1PR04MB1258; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1258; X-Microsoft-Exchange-Diagnostics: 1; HE1PR04MB1258; 4:+Btfly+GrBa/GjElQ98xrebcDRcbTMqitYZRA6NeXOAOY+ybijyDVxJostOyWIHYO+odBEYcmjBXgPlLS6HspDItftMrTN87tLJMMdYnBC/DxkLHSCDYJl6RzFPrKv9nHG/7IuV/4642Dl/IOxTJv+OqbIYXbCus+IEfxIkg5m0P7Q6juVDORtcjjup4mFfyHU4qc5TSodgrtsHaUqtVUOVFZPHWTeBaAQU8s5Tc88loWGu3wkwToyhH+ehwd6GPHdc4c86ySRIvaNi5rBGDbL/d9v//cizDCB9SRLeGOQUFuIxjtehRdUkXyncs9/Yzd7AedSADzJr/QbOuSJqKRuzGw4GWMsF87k9uSDb9lPvguBM0AhM+wxjAuBMamp9HjkRqdt+H+CZvrCA6rAvCrqL/l5XVRG9YnOBr8TXUbE2aBo1bI5oQ3wNBvTwTTXduIT5ihy1sCuX7Q3BYOePlyQ== X-Forefront-PRVS: 00979FCB3A X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR04MB1258; 23:Z/1VjXKl2JLR4BmUimred3Hz1MoEchK2yLnmNKo?= =?iso-8859-1?Q?oiPHq0Xlqi+IjHwzlLa8Z+9tSDHllBOFqlFYN/gtevxO8CndX8Yb8dApdU?= =?iso-8859-1?Q?lP+Civ7I8YHdpFvaLUPO/tFDY7wxehLeRmE1VNcfR3G7pzqTjv42+/A2Ow?= =?iso-8859-1?Q?yHFijtguJwrZ++tVFIgeg+eK9ec1QOyO8sHQUpvSH93kUWmVfYYuhBoFFp?= =?iso-8859-1?Q?Y1Wl0M56ze0w5IlKXzXFwAo7cUylfTugBERetVNeCYFZxsnFO8zi34NsEM?= =?iso-8859-1?Q?1m2Y4SG/0kLVpqZ3E37q5p4DMcWiD4EEiCsDISmGZCCNZcEjen/uFN/UDQ?= =?iso-8859-1?Q?8a/HcS93cYllg9Qmj9AXfZVCfJ7TRm8b/H2DRgQMmiguzi66LVUy6J8KTk?= =?iso-8859-1?Q?q8SkhMreLKXGEGW9GIWKKOpdgwENpkvHTVk76Q+SUKun+9nEc4bL+0Ypf6?= =?iso-8859-1?Q?xtSu3AxZeXufRrCtpJRtmPTQiFqu/W/R9nu9+Ygng5V2NQq42sDmdCE5DG?= =?iso-8859-1?Q?x7eWjH+/ER2EatfAhWq0ixxf0znTzg+FrWhY/hlbLT7m9lgeRSWDANMQfe?= =?iso-8859-1?Q?IEjopoHW17pVZ6KJp6pZV1/It/5XoxBbsLjLTTcgHRBKuHIg8d5lknJJ3Q?= =?iso-8859-1?Q?cLbKv2pjOH/0nFR0PcZo/o49hKOd3G40fRFaQH8r434ntrJklGd4GY8nt7?= =?iso-8859-1?Q?eNqNXy881tSHmWFzlinLTv9DrCU9PoKdy+Z9TxJqI5Ftrqy8DAUnbnGFpv?= =?iso-8859-1?Q?Tj/DpBw8sqQJWBm1/DOJz4nRs6jnjx/ZEFZgCr1rU7SJUl0nuCKEZGOMNY?= =?iso-8859-1?Q?Ppw4XZiPXDVGC2toiRNUlULNARIuwZN48+5dCXco2ohQb+yHhdLtucunmb?= =?iso-8859-1?Q?gNv0F6qXCeJEqb86B9Ghl+HDwobhv5Pq/yDOxoid/ZmgF5ytaCPU9yVuhY?= =?iso-8859-1?Q?m0fEKYhcxQTwRQcyAtPJoTfY/6MuwqTUrDBs07pvs1nMicpP+gFPECGrKy?= =?iso-8859-1?Q?E40cVetmBUDLB3QMTZb8BGMdvAvJmwAcIkKTZHcgciE1rlN5RmFwKiX94o?= =?iso-8859-1?Q?eWFbDYPNSY5+0xIagvWLNcmEnyAMAyiXpfgU8/Blzv/tY4BFue9ihGfjsB?= =?iso-8859-1?Q?eZt4d/ztXFNyJyni8s1Ap+kBRQO5KX6K6ABVW3bfLyj1Bm1Uo8PyK4nKh2?= =?iso-8859-1?Q?zVGSAU+ddmz10TuxzZFj7CKLO6Vlg7BEiUdcT56BkMJITECA/DmlLzZlxs?= =?iso-8859-1?Q?uc5niUQNGnqAjXU7ol9JBQnfcN8oMr8UXOcJFPzXzh8V5M1K0MTGxnzso8?= =?iso-8859-1?Q?CAmfA6UlGqK5S6KhvMyLCgeXL0WvR408ztMqz3FuEaKBN+ycnkmsNVgIYf?= =?iso-8859-1?Q?L7GV+BgMXTn8AwWhxYVTAuBGoaUTici2ZUdbuGWovuhxESSRV83l5Z1FmO?= =?iso-8859-1?Q?bkBVOh1a6yn+aUYdV3cSt9LLWsmfb86slqnGPfEhi4M4zgTOJuAxVMhvxV?= =?iso-8859-1?Q?/xof6uR5UF/unMkhu5cg2+MC2CN4mWzFiX30fCNw9+7rnAUvqnIpDCW6Il?= =?iso-8859-1?Q?CxSOg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR04MB1258; 6:QVeftA4WE4AjIJSeZ5HO9HWjDXKiv/PbCuQWLlFTfsHbB6RkVNgGzpk7ImHroHbtRt6I+qUefHG0bIVAP0+9lQb7N8DE8RiH5MR8noJ6sIzUFUjBf4kX/kKsJ61FSY/UVUdnhwXpZbPvQsvicCN3uTHcabSUJEKXitQOWSFSCSb09VpwHPolPP0b959SfpPO6OGsxEbz36Cha688PmSYU/bGvFzfGX1uNCwfLDbxSNcoHh4W4lb4DgjrwnJaQiXNpeJObWptSPOceOtWz7yP6b9sESIJIM9izVyT9NSHv2E+/97ieC3MUQbgNIwuB7cglU9NMLZOyr3FguNEUGOsYCwB7Dk/k8d6F0+HvybuCkQ=; 5:wnMF5fZo0M0pVkc+4O7SFxauNesa9bCB5bAidGbiWSPDT7oyY2uxr3yzJCchUGm8pcLqIcQp4+yyvp6nU580rz/dMoF3l6gdoyA/AFzt9TR+J65LQ0fKMJA5mFH0G0Z2V7sjxcFP9z+0oPjtwOfg2qGRPodB3gEy23h+P6v5dM8=; 24:qALQyz/QszvzeL4rucu7WHIeKkTy4miSjgxbgYIU33QaGZZXWAgEI34gJA8yzz2Nt+ENlAR5oOYUzu5eV/l934mJRjc8X+Uat7qBOEMebio= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR04MB1258; 7:cyOrm0moZZnZTG2gXwvqBcNCg5t72OL4LV/un5Q9g1qHYGv+ppI3EFXCeJmP5qtPba8wz1lV9CHWMfLGWIxnuKXMdA6TGkI5CrcmSJOREf1dKpfhlxBuKA3+T0IUqM63Gl2bXGcuuF5nCRx3dAHtCVzPLeTFcZdbL+NpArLR0CSPYIELue+36U6xifN9N7VDpi9xK/sCliCxYMcHsm1F1ECiBIXQL/1+68YpgNr+5HkZg+GHzlffISDliZj56p0uiuZiTuW2M9VPY9I0exv4SPV0GlGW480ic/FyIbuRAail+PelaYUOABSC9krcSXo2TWrwSib0xXjTtexDvrECh6Wb9L712y/kwTWEv8BHd7w= X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2016 20:41:03.5974 (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.247.132]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1258 X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 23.103.247.132 X-MS-Exchange-CrossPremises-AuthSource: AM1FFO11FD029.protection.gbl X-MS-Exchange-CrossPremises-AuthAs: Anonymous X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1258.eurprd04.prod.outlook.com Archived-At: Cc: "core \(core@ietf.org\)" Subject: Re: [core] Mail regarding draft-ietf-core-coap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 16 Oct 2016 20:41:10 -0000 Hello Doran, errata can be reported via this page: https://www.rfc-editor.org/errata.php= (section "Report new errata"). In my reading of the text it is clear that a NON should never trigger an AC= K, but of course these sentences could be interpreted in various ways. best regards Esko -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Doran Hans (donn) Sent: Monday, October 10, 2016 11:49 To: core@ietf.org Subject: [core] WG: Mail regarding draft-ietf-core-coap Hi, I've been teaching CoAP in an IoT class which led me to read the RFC 7252. The standard could do with a revision in writing - one example is here: 5.2.3. Non-confirmable If the request message is Non-confirmable, then the response SHOULD be returned in a Non-confirmable message as well. However, an endpoint MUST be prepared to receive a Non-confirmable response (preceded or followed by an Empty Acknowledgement message) in reply to a Confirmable request, or a Confirmable response in reply to a Non-confirmable request. This sentence links Non-confirmable message behaviour with Confirmable mess= age behaviour through the word "However" despite it being abundantly clear = that the two have nothing to do with each other. The paragraph SHOULD read: 5.2.3. Non-confirmable If the request message is Non-confirmable, then the response SHOULD be returned in a Non-confirmable message as well. However an endpoint MUST be prepared to receive a Confirmable response in reply to = a Non-confirmable request. So far so good: However we have an implementation based on python libraries= running where the default response to a NON message is an ACK. It is not p= ossible to determine from the standard whether this is incorrect behaviour = or not. I don't know how the RFC system works with regard to revisions - if I had r= ead the earlier versions of the document I would have done some re-writing = at the time - but if it is to be revised then maybe you could let me know. Best regards ZHAW Zurich University of Applied Sciences Institute of Embedded Systems (I= nES) Prof. Hans Dermot Doran Head of Secure and Dependable Systems Techniku= mstrasse 9, Postfach, CH-8401 Winterthur T +41-58-934-7676 | M +41-79-636= -8133 http://ines.zhaw.ch | hans.doran@zhaw.ch _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ 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 Sun Oct 16 16:55:16 2016 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 BE25E127071 for ; Sun, 16 Oct 2016 16:55:14 -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, HTML_MESSAGE=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 JKgp-rRS2Plo for ; Sun, 16 Oct 2016 16:55: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 745BC129511 for ; Sun, 16 Oct 2016 16:55: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 u9GNt6Yh011959; Mon, 17 Oct 2016 01:55:08 +0200 (CEST) Received: from nar-4.local.mail (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (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 3sxyrB5N1hz7yGL; Mon, 17 Oct 2016 01:55:06 +0200 (CEST) Date: Mon, 17 Oct 2016 01:55:06 +0200 From: Carsten Bormann To: "Doran Hans (donn)" , "=?utf-8?Q?core=40ietf.org?=" Message-ID: In-Reply-To: References: X-Mailer: Airmail (390) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5804135a_1cb3824b_2128" Archived-At: Subject: Re: [core] WG: Mail regarding draft-ietf-core-coap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 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, 16 Oct 2016 23:55:15 -0000 --5804135a_1cb3824b_2128 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 13 October 2016 at 09:48:49, Doran Hans (donn) (donn=40zhaw.ch) wrote:= we have an implementation based on python libraries running where the def= ault response to a NON message is an ACK. ACK messages are acknowledging CON messages. =C2=A0ACK messages sent in r= esponse to NON messages are wrong. Right there in 1.2: =C2=A0 =C2=A0Acknowledgement Message =C2=A0 =C2=A0 =C2=A0 An Acknowledgement message acknowledges that a speci= fic =C2=A0 =C2=A0 =C2=A0 Confirmable message arrived. =C2=A0By itself, an Ack= nowledgement =C2=A0 =C2=A0 =C2=A0 message does not indicate success or failure of any = request =C2=A0 =C2=A0 =C2=A0 encapsulated in the Confirmable message, but the Ack= nowledgement =C2=A0 =C2=A0 =C2=A0 message may also carry a Piggybacked Response (see b= elow). Please note that 4.2 says: =C2=A0 =C2=A0Rejecting an =C2=A0 =C2=A0Acknowledgement or Reset message (including the case where t= he =C2=A0 =C2=A0Acknowledgement carries a request or a code with a reserved = class, or =C2=A0 =C2=A0the Reset message is not Empty) is effected by silently igno= ring it. =C2=A0 =C2=A0More generally, recipients of Acknowledgement and Reset mess= ages MUST =C2=A0 =C2=A0NOT respond with either Acknowledgement or Reset messages. So the bad python library is interoperable (the bad ACK will be silently = ignored*), but still wrong. The text you are citing is answering a different question: If the request= was in a NON, does the server respond with a NON or with a CON=3F =C2=A0= (The latter would imply that the client sends an ACK for that.) =C2=A0The= text that you want to delete describes that a separate response to a CON= message (which needs an empty ACK do indicate a separate response will b= e sent later) MAY be responded to in a NON message. =C2=A0(See also the p= enultimate paragraph of 4.2=E2=80=A6) Gr=C3=BC=C3=9Fe, Carsten *) Well, unless the client manages to reuse the NON message-ID for a CON = before the ACK arrives. =C2=A0Should not really happen, because of=C2=A0E= XCHANGE=5FLI=46ETIME. --5804135a_1cb3824b_2128 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline