From nobody Mon Nov 2 00:47:24 2020 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 6173B3A0AB0; Mon, 2 Nov 2020 00:47:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <160430684235.18641.1554016719234271346@ietfa.amsl.com> Date: Mon, 02 Nov 2020 00:47:22 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-dev-urn-08.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 08:47:23 -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 WG of the IETF. Title : Uniform Resource Names for Device Identifiers Authors : Jari Arkko Cullen Jennings Zach Shelby Filename : draft-ietf-core-dev-urn-08.txt Pages : 19 Date : 2020-11-02 Abstract: This document describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage, or equipment inventories. A URN-based representation can be easily passed along in any application that needs the information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-dev-urn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-dev-urn-08 https://datatracker.ietf.org/doc/html/draft-ietf-core-dev-urn-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-dev-urn-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 2 09:39:36 2020 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 646323A0DDF; Mon, 2 Nov 2020 09:39:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <160433876936.25078.6012423937171853986@ietfa.amsl.com> Date: Mon, 02 Nov 2020 09:39:29 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-groupcomm-bis-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 17:39:29 -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 WG of the IETF. Title : Group Communication for the Constrained Application Protocol (CoAP) Authors : Esko Dijk Chonggang Wang Marco Tiloca Filename : draft-ietf-core-groupcomm-bis-02.txt Pages : 44 Date : 2020-11-02 Abstract: This document specifies the use of the Constrained Application Protocol (CoAP) for group communication, using UDP/IP multicast as the underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource- constrained networks. The most common of such use cases are also discussed. This document replaces [RFC7390] and updates [RFC7252] and [RFC7641]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-groupcomm-bis-02 https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-groupcomm-bis-02 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 Nov 2 09:44:21 2020 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 541E63A0E34; Mon, 2 Nov 2020 09:44:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <160433906029.4820.14907779807204481594@ietfa.amsl.com> Date: Mon, 02 Nov 2020 09:44:20 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-oscore-groupcomm-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 17:44:20 -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 WG of the IETF. Title : Group OSCORE - Secure Group Communication for CoAP Authors : Marco Tiloca Goeran Selander Francesca Palombini Jiye Park Filename : draft-ietf-core-oscore-groupcomm-10.txt Pages : 76 Date : 2020-11-02 Abstract: This document defines Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of CoAP messages exchanged between members of a group, e.g. sent over IP multicast. In particular, the described approach defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-10 https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-oscore-groupcomm-10 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 Nov 2 10:05:20 2020 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 0961E3A0128; Mon, 2 Nov 2020 10:05:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <160434031399.4820.4411222635030175127@ietfa.amsl.com> Date: Mon, 02 Nov 2020 10:05:14 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-echo-request-tag-11.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 18:05:14 -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 WG of the IETF. Title : CoAP: Echo, Request-Tag, and Token Processing Authors : Christian Amsüss John Preuß Mattsson Göran Selander Filename : draft-ietf-core-echo-request-tag-11.txt Pages : 32 Date : 2020-11-02 Abstract: This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC7252 with respect to the client Token processing requirements, forbidding non-secure reuse of Tokens to ensure binding of response to request when CoAP is used with a security protocol, and with respect to amplification mitigation, where the use of Echo is now recommended. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-echo-request-tag-11 https://datatracker.ietf.org/doc/html/draft-ietf-core-echo-request-tag-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-echo-request-tag-11 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 Nov 2 11:57:34 2020 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 A0DF93A11FE; Mon, 2 Nov 2020 11:57:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <160434704261.23549.9923307790200304901@ietfa.amsl.com> Date: Mon, 02 Nov 2020 11:57:22 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-resource-directory-26.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 19:57:23 -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 WG of the IETF. Title : CoRE Resource Directory Authors : Christian Amsüss Zach Shelby Michael Koster Carsten Bormann Peter van der Stok Filename : draft-ietf-core-resource-directory-26.txt Pages : 84 Date : 2020-11-02 Abstract: In many IoT applications, direct discovery of resources is not practical due to sleeping nodes, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-resource-directory-26.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-26 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 Nov 2 14:10:21 2020 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 2AA8B3A1261; Mon, 2 Nov 2020 14:10:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <160435501413.12104.18445738121351318043@ietfa.amsl.com> Date: Mon, 02 Nov 2020 14:10:14 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-stateless-07.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 22:10:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP) Authors : Klaus Hartke Michael C. Richardson Filename : draft-ietf-core-stateless-07.txt Pages : 22 Date : 2020-11-02 Abstract: This document provides considerations for alleviating CoAP clients and intermediaries of keeping per-request state. To facilitate this, this document additionally introduces a new, optional CoAP protocol extension for extended token lengths. This document updates RFCs 7252 and 8323 with a new definition of the TKL field in the CoAP message header. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-stateless/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-stateless-07 https://datatracker.ietf.org/doc/html/draft-ietf-core-stateless-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-stateless-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 2 14:41:18 2020 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 BD01B3A125E for ; Mon, 2 Nov 2020 14:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnZT7rUGd9Ne for ; Mon, 2 Nov 2020 14:41:14 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFCD53A1258 for ; Mon, 2 Nov 2020 14:41:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1F615389A1 for ; Mon, 2 Nov 2020 17:48:16 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 78dj8m-cORUd for ; Mon, 2 Nov 2020 17:48:15 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 80790389A0 for ; Mon, 2 Nov 2020 17:48:15 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 21F691FB for ; Mon, 2 Nov 2020 17:41:13 -0500 (EST) From: Michael Richardson To: core@ietf.org In-Reply-To: <160435501413.12104.18445738121351318043@ietfa.amsl.com> References: <160435501413.12104.18445738121351318043@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-stateless-07.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 02 Nov 2020 22:41:17 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I merged https://github.com/core-wg/stateless/pull/14/files (via closing https://github.com/core-wg/stateless/pull/11/files it seems. Actually, I'm bit confused by what happened) I decided to time out on the conversation. Please read the diffs and let's talk about the question about recommendation on replay size. This is non-normative text, as it's really a local decisio= n. internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. > This draft is a work item of the Constrained RESTful Environments WG = of the IETF. > Title : Extended Tokens and Stateless Clients in the Constr= ained Application Protocol (CoAP) > Authors : Klaus Hartke > Michael C. Richardson > Filename : draft-ietf-core-stateless-07.txt > Pages : 22 > Date : 2020-11-02 > Abstract: > This document provides considerations for alleviating CoAP clients > and intermediaries of keeping per-request state. To facilitate this, > this document additionally introduces a new, optional CoAP protocol > extension for extended token lengths. > This document updates RFCs 7252 and 8323 with a new definition of the > TKL field in the CoAP message header. > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-stateless/ > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-core-stateless-07 > https://datatracker.ietf.org/doc/html/draft-ietf-core-stateless-07 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-stateless-07 > Please note that it may take a couple of minutes from the time of sub= mission > 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/ > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+giwgACgkQgItw+93Q 3WVsKggAsSS1XkT0hgru38kVfhA0kiuHt/dSj3oMqcLSXy2+LpFN2PjyNurs+UNK XKgD+7htqruzDUcqF/j3rWjBajKfmU1HDljCZtBczrptsHCVqNOFye4euYNv75AW KoKLnZhAQI583+q3rXCegQI0s+ncolFG8jRz8VWdP81Fiwyn109FOBVhgEswyfEE D/X68ZBvFmkWLZ/xKiD0dvwCDXc1EGS2SIKyq+M+pt5EL92qGzLgYGxzFNlr4+/H j/XiWujK3s4gSTU5avPmWXcLKRCyBXGzZkRDiewxs34Q7W2KkbYfD18PBMHFsGv+ tDzSxq3zDOGRwmvHs+1LzhDFP5ZhOQ== =6Qjb -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 3 07:50:49 2020 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 EE5423A0D32; Tue, 3 Nov 2020 07:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mI59MwjyVGP; Tue, 3 Nov 2020 07:50:45 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25403A0D1E; Tue, 3 Nov 2020 07:50:40 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id B35BB40013; Tue, 3 Nov 2020 16:50:38 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id F2929AB; Tue, 3 Nov 2020 16:50:36 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:be1b:33a0:9df5:4f6f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 7547B34; Tue, 3 Nov 2020 16:50:36 +0100 (CET) Received: (nullmailer pid 32143 invoked by uid 1000); Tue, 03 Nov 2020 15:50:36 -0000 Date: Tue, 3 Nov 2020 16:50:36 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Barry Leiba Cc: "draft-ietf-core-echo-request-tag.all@ietf.org" , "core@ietf.org" Message-ID: <20201103155036.GA4187010@hephaistos.amsuess.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2020 15:50:48 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello Barry, all the changes following from the discussion after your review of -10 are included in the version [-11] submitted yesterday. The change log is copied below for convenience. Together ith the discussion had earlier on this thread, all raised concerns should now be resolved. If you see your points as addressed, please clear the document for further processing. Thanks Christian [-11]: https://tools.ietf.org/html/draft-ietf-core-echo-request-tag-11 --- o Changes since draft-ietf-core-echo-request-tag-10 (Barry's comments) * Align terminology on attacker * A number of clarifications and editorial fixes * Promote DTLS and OSCORE to normative references * Add counter-based version to the Methods for Generating Echo Option Values appendix * Use 64-bit randomness recommendation throughout (but keep it as SHOULD so applications with strict requirements can reduce if if really needed) * Speling and Capitalization --jI8keyz6grp/JLjh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+hfEYACgkQOY0REtOk veFeuxAAyCZ0Oi79f3F2QkOjnccIBdLKj5gGrNCVDzCirqBWLighhx3DMEo5mAP6 3qYdYN/HNRbYY5KRuwkqHhObjO8w1c4WF8U8nqXaTww3mzNvJxU/TDqy2XbUgwEb qybX4OOGujl5FBXfxv5JI6W90sUex6fYynEO/7ClEIvDCPP3kANhSLk27KN5wmqx celEAwFIW6qZUrtXv8f9kjs5abj+RT3HsNdSQ46ZG8utgqWBcf347wWZFtgo5jiQ P9BgFvIwU4rAFOMAgv6e8snLWZctYKPi3peAEFmoeeUevvZjEhcnwYC6bfFOYcBp 8ZO76uOK+2MLT1edkyo/UzXdw5+T/OaoRf7DgrfC48hDrRSVjLO3HyLEp8RTCSNy FYat10vIoEjqX/0XxO+ryZB1jXfiOsJAugq4HSe/k/66sjCHxt14nr+pOJvmpXVw NslPRUXq68Eb5R4kXuUC3ciVkHnS22FXSotE7EqxdQ+Qgpv2s8Vc8BizA9hxLQCE W+s+mS2eqf/Wt9bvnWVHWcBZ4czBIjEZU2fA/kB7eIR70QJxckKtcsphSqmIYu8I V99esWUhb3IIjcxObPbpXtAe0LYxk62p6+RiK0xr8sTGaKluQ9VgCPFi8iT4V+nb vPRP0o6RbyhMkpmjz/D8PptJNJhXwAv9wzHUjzM/kQ4jyQbEqNg= =tDDK -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From nobody Tue Nov 3 08:39:30 2020 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 4EE0A3A0DBA; Tue, 3 Nov 2020 08:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmPxCToeUgGa; Tue, 3 Nov 2020 08:39:26 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 507523A0DAC; Tue, 3 Nov 2020 08:39:25 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 11F3040013; Tue, 3 Nov 2020 17:39:24 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id E2EF0AB; Tue, 3 Nov 2020 17:39:22 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:be1b:33a0:9df5:4f6f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 4699D34; Tue, 3 Nov 2020 17:39:22 +0100 (CET) Received: (nullmailer pid 43419 invoked by uid 1000); Tue, 03 Nov 2020 16:39:21 -0000 Date: Tue, 3 Nov 2020 17:39:21 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: ipv6@ietf.org, core@ietf.org Message-ID: <20201103163921.GB4187010@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZoaI/ZTpAVc4A5k6" Content-Disposition: inline Archived-At: Subject: [core] IPv6-related allocations and mechanism in CoRE's Resource Directory X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2020 16:39:29 -0000 --ZoaI/ZTpAVc4A5k6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello 6man group, as CoRE group's work on the Resource Directory ("RD", draft-ietf-core-resource-directory, [1]) is hopefully drawing to a conclusion, it is long overdue to draw on the 6man group's expertise on the document's IPv6 related IANA registrations and other v6 related mechanisms. While reviews on the whole document are always appreciated, here are the points most likely worth your attention: (As a preface: The RD is a place where embedded web servers can deposit information about their resources; IPv6 interactions are primarily on the side of how an RD can be found in a network if not explicitly configured). * We introduce RDAO, the Resource Directory Address Option. It is transported in RAs, and generally very similar to RDNSS. Full text at [2] (yes we know 38 is already taken, IANA is trusted to pick the next free one at time of publication). * For more ad-hoc use, we ask that an "All CoRE Resource Directories" multicast address be assigned in the Variable Scope Multicast Addresses space at [3]. * The CoAP protocol has defined REST semantics for multicast requests and uses them with the above (or a locally configured) addresses. Unless extra steps are taken, the communication between the registering endpoint and the RD happens using the IP address the RD answers the multicast request from. The client address used in these later exchanges is communicated to other parties. Thus, it is desirable to guide the process towards the use of a routable address, even when the client originally sent the request to a link-local multicast address. To ease implementation, we recommend that the RD answer the multicast requests from a routable source address. The mechanism we suggest for picking that source address is expressed in terms of the RFC6724 address selection around [4]. Is that use within the intended applications of the source address selection mechanism, or (if it's a stretch but passes for creative merit) at least formally correct? * For the examples we want to use multicast addresses that are globally unique (as they may be used on nomadic devices) but still valid example addresses. Lacking precedent or guidance in RFC3849, a unicast-prefix based site-local example address was constructed as ff35:30:2001:db8:f1::8000:1. (The :f1: part is there because each section with internally consistent examples takes a /48 out of 2001:db8::/32). As should have been expected, both idnits and reviewers asked questions, but this still seems to be closest there is to globally unique example address. Is it constructed correctly, or is there a better example address for this purpose? Thanks for your attention Christian [1]: https://tools.ietf.org/html/draft-ietf-core-resource-directory-26 [2]: https://tools.ietf.org/html/draft-ietf-core-resource-directory-26#sect= ion-4.1.1 [3]: https://tools.ietf.org/html/draft-ietf-core-resource-directory-26#sect= ion-9.5 [4]: https://tools.ietf.org/html/draft-ietf-core-resource-directory-26#page= -17 --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --ZoaI/ZTpAVc4A5k6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+hh7YACgkQOY0REtOk veECChAAlgczVqap7Jh7Sot1A0mtGvO1ZbWqxpBV+uczpUa1G616wysAciz3WESO k62K3NlbLO73KsHYfTuZGbEf/tIkQ4SlI1VRYduKm+1bxC23MMDiATmzf5PK/46F GDrAfTzwlbSEXey/kOA8HfWqO3HLG9W4INmY9hsb9g/8U8IELB/JIWeB3Oj567n5 fYMXxbIXqNgavApEBq98+bmT9on01FriT7gAC+FkgylnjSnX8PT5oiryh5N23O06 eWMOD/E14MWV0Av1kMQ0/XOSL9YWBtqNXgJ0pS8Mh/9Hc65T2cV+0Bj9KeAqjIk3 ljBCvv9YR6R2lp5wuCBAUGEiQijk6jI5c3o0qlJVPJftQZPoIiPG9/g5gjcOauJa +6eqcoQaE9FxMffqcTZOgUbNPeqFmUtlFxE6e3+r5nK5pwAkvn4kxsmLGhL66a9t U0p8asPbVWSUvpEKj2u0fjS7S2d0Ux/unhUtjMPhEn7/4IVWMvVgcpOztPI73OGF l80lhOF4/5vcrBoxkvpgp4m7e+2ErJeBqTneocOkM4xz/luGTTGb1nbXLE5Qgc9g XbZArXVJQnBrl5j6C2jjBzalLeM0eyPOVzkknoeV4iYakTWq5kEwmPIn80FQZ7fF 0ocm31mJLMvtR+/6LJtTjQafTgJa1tgQjJnnFKsY5MVFJeBa10Y= =yx4V -----END PGP SIGNATURE----- --ZoaI/ZTpAVc4A5k6-- From nobody Tue Nov 3 09:17:41 2020 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 E03E73A0DEB; Tue, 3 Nov 2020 09:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkLaBIWK1zG8; Tue, 3 Nov 2020 09:10:05 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CC563A0DE6; Tue, 3 Nov 2020 09:10:02 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 16C5840013; Tue, 3 Nov 2020 18:10:00 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 916D2AB; Tue, 3 Nov 2020 18:09:58 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:be1b:33a0:9df5:4f6f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6086134; Tue, 3 Nov 2020 18:09:58 +0100 (CET) Received: (nullmailer pid 50344 invoked by uid 1000); Tue, 03 Nov 2020 17:09:58 -0000 Date: Tue, 3 Nov 2020 18:09:58 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: =?iso-8859-1?Q?=C9ric?= Vyncke , Warren Kumari , Roman Danyliw , Erik Kline , Alissa Cooper , Martin Duke , Murray Kucherawy , Robert Wilton , Benjamin Kaduk Cc: The IESG , jaime.jimenez@ericsson.com, core-chairs@ietf.org, bob.hinden@gmail.com, draft-ietf-core-resource-directory@ietf.org, otroan@employees.org, core@ietf.org Message-ID: <20201103170958.GA45088@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline In-Reply-To: <159730632066.12379.5174560093789503034@ietfa.amsl.com> <159732268335.29656.5724379569570361825@ietfa.amsl.com> <159730418060.12332.7885245575969951169@ietfa.amsl.com> <159729581019.30986.4796757249133933498@ietfa.amsl.com> <159725166775.21744.348589503930840040@ietfa.amsl.com> <159721596413.8457.13314798043091474779@ietfa.amsl.com> <159720107494.28255.1546033232009788973@ietfa.amsl.com> <159717402717.27772.14957520028083871786@ietfa.amsl.com> <159661278180.30518.10421410106159995546@ietfa.amsl.com> Archived-At: X-Mailman-Approved-At: Tue, 03 Nov 2020 09:17:40 -0800 Subject: Re: [core] The various positions on draft-ietf-core-resource-directory-25 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2020 17:10:08 -0000 --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Reviewers, CoRE and IESG members, thanks for your input to the Resource Directory document, and your patience while it was being processed. Before the individual point to point responses can go out, this mail is to address the general status, and answer a few points that were brought up by different reviewers (it will be referred back to in the point to point responses). In summary, the points raised in the reviews led to the changes of the recently uploaded [-26], and where no changes were made, the reasoning behind the choices in the document is outlined below or in the following mails. (Either way, short of aggregated nits paragraphs, all points are responded to in the following mails). A few larger issues evolved from the review comments being discussed in the interim meetings, so please expect a -27 at a later point (after IETF109) with the changes mentioned below. Kind regards Christian [-26]: https://tools.ietf.org/html/draft-ietf-core-resource-directory-26 Preface =3D=3D=3D=3D=3D=3D=3D References into the issue tracker are primarily intended for bookkeeping an= d to give you access to the altered text if you're curious -- but for general re= view purposes, the responses are self-contained. Anticipated changes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We have opted to submit a new version that should clear out all the other comments, so that the remaining work can be focused and swift: * Replay and Freshness (OPEN-REPLAY-FRESHNESS) The comment on DTLS replay made us reevaluate the security properties of operations on the registration resource. While these are successively har= der going from DTLS without replay protection to DTLS with replay protection = and hardest with OSCORE, the text as it is is still vulnerable to an attacker stopping a reoccurring registration, or undoing alterations in registrati= on attributes. Mitigation from a concurrent document (the Echo mechanism of I-D.ietf-core-echo-request-tag in event freshness mode) is planned, but t= he text is not complete yet. * Necessity of the `anchor` value in all responses The requirements around Limited Link Format and the necessity to express = all looked up links in fully resolved form have stemmed from different ways RFC6690 has been read, both in the IETF community and by implementers. A comment from Esko Dijk has shown a clear error in one of the readings. = That reading is single-handedly responsible for most of the overhead in the wi= re format (savings can go up to 50%), which is of high importance to the CoRE field. Due to that, it is the WG's and authors' intention to remove the reading = =66rom the set of interpretations that led to the rules set forth. The change wi= ll not render any existing RD server implementation incompatible (older RDs would merely be needlessly verbose), and the known implementations of Link-Format parsers can easily be updated. The updates to the document could not be completed in time with the rest = of the changes, because a) it requires revisiting the known implementations = for confirmation and b) will affect almost every example that contains lookup results. * Server authorization (OPEN-SERVER) The two areas of "how is the RD discovery secured" and "what do applicati= ons based on the RD need to consider" jointly opened up new questions about server authorization and the linkage between a client's intention and the server's promises that may easily not conclusde in timeframe reasonable f= or RD. While steps have been taken to address the issue both on the RD discovery= and the applications side (https://github.com/core-wg/resource-directory/pull/306), the ongoing discussions in the working group may turn up with a less cumbersome phras= ing for these parts. * There's a few small open issues Esko brought up on the issue tracker that could not be addressed in time; most of them are about enhancing the examples, which best happens after the anchor cleanup anyway. Repeated topics =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A few common topics came up in multiple reviews, and are addressed in the following section; the individual responses can be found in follow-up mails, and refer to the common topics as necesary. GENERIC-FFxxDB -------------- "Where do the ff35:30:2001:... addresses come from?" response: There's a coverage gap between RFC3849 (defining example unicast addresses)= and RFC3306 (defining unicast-prefix-based multicast addresses). For lack of an agreed-on example multicast address, the used ones were created by applying= the unicast-prefix derivation process to the example address. The results (ff35:30:2001:db8::1) should be intuitively recognizable both as a multicast address and as an example address. The generated address did, however, fail to follow the guidance of RFC 3307= and set the first bit of the Group ID. Consequently, the addresses were changed =66rom ff35:30:2001:db8::x to ff35:30:2001:db8::8000:x, which should finall= y be a legal choice of a group address for anyone operating the 2001:db8:: site. (= The changes can be viewed at https://github.com/core-wg/resource-directory/pull= /270). GENERIC-6MAN ------------ "Whas this discussed with 6MAN?" response: Not yet; a request for feedback was sent out recently. (Mail at https://mailarchive.ietf.org/arch/msg/ipv6/xY0AqPvbja45gxgW02GU3oW= PTwc/). GENERIC-WHOPICKSMODEL --------------------- "How does the client know which security policies the RD supports?" response: The client can only expect any level of trustworthiness if there is a claim to that in the RD's credentials. Typically, though, that claim will n= ot be encoded there, but implied. For example, when configuring an application that relies authenticated endpoint names, then telling the application to u= se the RD authenticated via PKI as coaps://rd.example.com should only be done = if the configurator is sure that rd.example.com will do the required checks on endpoint names. Some clarification has been added in https://github.com/core-wg/resource-di= rectory/pull/265. GENERIC-SUBJECT --------------- "Section 7.1 says: '... can be transported in the subject.' -- where precis= ely?" response: That text was only meant to illustrate to the reader what such a policy cou= ld contain, not to set one (which would require more precision). It has been made more explicit that this is merely setting the task for the policies. As an example, some more precision is given by referring to SubjectAltName dNSName entries. Changes in https://github.com/core-wg/resource-directory/pull/308. (If you have read up to this point, please continue reading the follow-up mails addressing the individual reviewer's points.) --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+hjuIACgkQOY0REtOk veH0TBAAplpSV/hcvLDgZT/B+0PFpP6trgOu3eeGYyO0jDG4a8/mLArU3ftrbjLP F1qrVBeR5YkJOzQwsOh3ie+qk+wpEUDaij5trnbSF6VKFXkQfg3bBCLAyTSUV/ge EtMWgJKbLyPnKkvd0boNIHv9wP4QcM9/zSysXMGvcy4GXFdF3AYgKMT57w6ZAEq2 BD+Wk8HWiqbOF58o40BpcKV1rgCGzCQc8RMqS9ZbvlhXr3RoQSDZ5kpczH8iO8js Nioy2FhmR80k8g9s+/SqobJpgPekeCAXmLvOVMFEh18igLO4xkXJbupbWaX+uPwF zJoa1fDg1TtFNLel9CxaxDHKhVttpoTCZ7soRfX+RbJqbwS+OZyenE8pV8VN8Y2/ 1VN6iOdybUtasoAO3o/KBk2owoGOz1pxKSncbvpB0cBidg/QpzDz5KNn4GK3hBWd C6/8TJpC279bJ1wTJr4gLlbrNuPm2ZJaDUBaIpnr3gQT7o60nc3GcY9oN5VYxLYn XEdclaeaN/fhKKCmKbJ+q8YIqsM+Xl4AtO0YyY4Ky9ThG4yqfk9vm77H3hPFIt9y XwAts2zoI6PxmIQTbOi8CJcu6QFqVQDZCMyT6de+nAQZgVIm8YnplNKegUM1UgOT 7J5lYf5F48cnm+dxb0yHzgJKDDrHsqLe9SlsustClj65J0SvTKI= =mK1p -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz-- From nobody Tue Nov 3 09:21:26 2020 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 E09BC3A0DEE; Tue, 3 Nov 2020 09:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T789swjeiMUD; Tue, 3 Nov 2020 09:21:19 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50ABE3A0DD5; Tue, 3 Nov 2020 09:21:16 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 3F919406FC; Tue, 3 Nov 2020 18:21:14 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id DECD4AB; Tue, 3 Nov 2020 18:21:12 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:be1b:33a0:9df5:4f6f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 7E51F34; Tue, 3 Nov 2020 18:21:12 +0100 (CET) Received: (nullmailer pid 52395 invoked by uid 1000); Tue, 03 Nov 2020 17:21:12 -0000 Date: Tue, 3 Nov 2020 18:21:12 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Russ Housley Cc: gen-art@ietf.org, last-call@ietf.org, core@ietf.org, draft-ietf-core-resource-directory.all@ietf.org Message-ID: <20201103172112.GB45088@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MW5yreqqjyrRcusr" Content-Disposition: inline In-Reply-To: <159587595578.28258.680109279207698132@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com> Archived-At: Subject: Re: [core] Genart telechat review of draft-ietf-core-resource-directory-25 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2020 17:21:22 -0000 --MW5yreqqjyrRcusr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (This is one of the point-to-point follow-up mails on the RD -25 reviews; for the preface, please see the preceding mail on "The various positions on draft-ietf-core-resource-directory-25" at ). > Section 7.1 says: "... can be transported in the subject." I think > you should say "subject field" or "subject name". Do you mean to > exclude the subject alternative name? response: See GENERIC-SUBJECT. > Section 7.1.1 says: >=20 > Registrants that are prepared to pick a different identifier when > their initial attempt at registration is unauthorized should pick an > identifier at least twice as long as the expected number of > registrants; registrants without such a recovery options should pick > significantly longer endpoint names (e.g. using UUID URNs [RFC4122]). >=20 > I think that the reason for the recommendation on length is to reduce > the likelihood of name collision. However, it is not clear to me why > this is linked in any way to authorization failures on the first > attempt to register. response: With growing numbers of participants, the chances some collision happening stays at a constant level even with the 2n length due to the birthday parad= ox, which is why the collision on the initial attempt is highlighted. A bit of clarifying information was added in https://github.com/core-wg/resource-directory/pull/248, without attempting = to verbosely lay out the whole background. > Nits: [...] resonse: All addressed in https://github.com/core-wg/resource-directory/pull/246 > IDnits reports: >=20 > =3D=3D There are 3 instances of lines with non-ascii characters in the > document. response: Two of them are in an author's name, the third is in an example and relevant there (as it talks about variations of a representation containing non-ascii charactes). > =3D=3D There are 1 instance of lines with multicast IPv4 addresses in the > document. If these are generic example addresses, they should be > changed to use the 233.252.0.x range defined in RFC 5771 response: That instance is a suggestion to IANA, it will be replaced with the actually assigned address. > =3D=3D There are 3 instances of lines with non-RFC3849-compliant IPv6 > addresses in the document. If these are example addresses, they > should be changed. response: see GENERIC-FFxxDB --MW5yreqqjyrRcusr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+hkYEACgkQOY0REtOk veEGvQ/+OLb6ozjdM2I2FP33O62IEa3sANOaFaBC+Me5/zWzZV9F3wT9jJoANuLf bCcYlqODefTiJP5TLZrbXrnigfRdxNW6T2mNuh733w/MtcbxdKwLsGOpeva1d33c CiSTkQQqqtNea7nADZtzgsMkjaXBSf4F2HSlmo1GC0fAxXVE/ZjdNfOWxSinhjhF 5/oOzyqLTkAs2v6okbriJOJccW1T4ZQ8I0LErm5dKWJMmkOWnZoI8RDaob1yhuHS HK7iYDWou+RNE3ezGYdaKuOALVBeTwNyhLnkUOOmIQ8nuyeLgvzs4rTCRoIQcvTn ibwdhBMebtT6vmC7rlI5f9AuJfvIeHOip20DYK8JSickoSVs/s3TIGtvNjUhgvRL z/F9NbAT4EuQTrEAFgSlE1msGOXVmtaY2pe0xk1KL+k5WyUFTuanWP+XMM2eNVGl 8sgwuselRdPHckwAk09fYuEuCvbRG+Ir/YZ7gyUvm5TuPhGE/MeAhMTGU90U/3dy wwQBP7igOKo3aGR/zPYOplUOnm10/HfJ7ooGDMWCNFh3G11Wihk3EeXkR4kxrpLX v+C/OJEnqaahzVsToWATOyHDkaNhpktr2fplc68uaJc9ipN6Y2sONLDBHhAt2E0i X+C/w7F6jUMhzfQoK1erM4F4HoZy7DKMPXa0fl1Gbphb/bMMMH0= =LiHs -----END PGP SIGNATURE----- --MW5yreqqjyrRcusr-- From nobody Tue Nov 3 09:23:13 2020 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 CA26C3A0DFF; Tue, 3 Nov 2020 09:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFiboYpStJcd; Tue, 3 Nov 2020 09:23:02 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF343A0DD5; Tue, 3 Nov 2020 09:22:44 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 464644082E; Tue, 3 Nov 2020 18:22:42 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 3E762AB; Tue, 3 Nov 2020 18:22:41 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:be1b:33a0:9df5:4f6f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 0394C34; Tue, 3 Nov 2020 18:22:41 +0100 (CET) Received: (nullmailer pid 52607 invoked by uid 1000); Tue, 03 Nov 2020 17:22:40 -0000 Date: Tue, 3 Nov 2020 18:22:40 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Valery Smyslov Cc: secdir@ietf.org, draft-ietf-core-resource-directory.all@ietf.org, core@ietf.org, last-call@ietf.org Message-ID: <20201103172240.GC45088@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="E13BgyNx05feLLmH" Content-Disposition: inline In-Reply-To: <159704204394.11310.18005109400419971010@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com> Archived-At: Subject: Re: [core] Secdir telechat review of draft-ietf-core-resource-directory-25 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2020 17:23:05 -0000 --E13BgyNx05feLLmH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (This is one of the point-to-point follow-up mails on the RD -25 reviews; for the preface, please see the preceding mail on "The various positions on draft-ietf-core-resource-directory-25" at ). > The -24 version of this draft was reviewed by Adam Montville. I looked ov= er > his review and I think that the issue he raised about possible mitigatio= n of > DDoS amplification attacks has been addressed in this version. I personal= ly > think that sentences describing how DNS and NTP are vulnerable to > amplification attacks are redundant in this document, but that's a matter= of > taste and doesn't hurt. response: We've taken the comment as an opportunity to cut back on the history lesson (change in https://github.com/core-wg/resource-directory/pull/249). > It is my impression, that Security Considerations were mostly written hav= ing > in mind that (D)TLS is always used, however it is only "SHOULD" in this d= raft > (or even "MAY" if we look at RFC6690 which Security Considerations this d= raft > refers to). I think that adding a few words describing which consequences= for > security not using (D)TLS would have and in which cases it is allowed will > make the Security Considerations more consistent.=20 response: Which level of protection is adaequate depends on the security policies. The text you refer to was missed in updates, and now reflects that some security mechanism ((D)TLS or OSCORE) SHOULD be used where the policies in place indicate sensitive data. (See https://github.com/core-wg/resource-directory/pull/250 for the full change). --E13BgyNx05feLLmH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+hkeAACgkQOY0REtOk veELWg/+I5PZ1v8JiR/qDGtogDM7EcUEtm+4fGFSwGHNVUwp7BvJxPnxUtpruQaY OHUP12eKwLp4gjfFXXhv+ZwIf1V6uQF8AATA8bT4esDKER2382/NCstzVaoUOIkd WnXfSQmWvj5Db+exyrK3SP3VB//KSIa6bs8vkyAUoVwAkB7pHN/bz3gltC/4OD7O P7DhM4mWr1051tFdPV2deFQClF9GzR3avFYhNcHtbancUTbRojDmiG+tL/Yl+W1r 0gdw7YpCvTxNlqiGx4Tm1/Uag+GkHD3m1Z2hgcqj6rHRVCcyUvkOGLfqgVIkGC11 yiHGa2MMiZWSLAzaYxzY+qmxEV5u8Pom1mwvWr3KxUvh6+el9ynDagF+ISxl9Ach PxXJhKJw6gMXYjuU3ZI9I0dlmhK7J+LXBpvKZkE+3SF/ra258tK6+3WgQD1CHYAR Vwf4F2G/2lAZJv285fb4Y1j4+XS0YIrX2nuvkW9Q05DeqwOPyJPzpp8EXhcaPyB3 /oPbImdG6m/womqmgFAzDPIPiyBD4LQI2TJbhTYF92zAFXEvO0F2Haj3Ooswq+ky bUael9T3pWfKwhtbxxTgvZFvpWjXSBrnRXCxDqYaZsbIMOPWBkj3gJxyQMX1RuJA VF+C9I03Njs8/Bw2FDnW0RrGx5eIj8VGTbsp4dB8P560drpSIrk= =VeO4 -----END PGP SIGNATURE----- --E13BgyNx05feLLmH-- From nobody Tue Nov 3 09:25:21 2020 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 E95413A0DF6; Tue, 3 Nov 2020 09:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44f0cVrVaEW9; Tue, 3 Nov 2020 09:25:13 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A313A0DD5; Tue, 3 Nov 2020 09:25:10 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id A342E4082E; Tue, 3 Nov 2020 18:25:08 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 42D6EAB; Tue, 3 Nov 2020 18:25:07 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:be1b:33a0:9df5:4f6f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id E66AC34; Tue, 3 Nov 2020 18:25:06 +0100 (CET) Received: (nullmailer pid 53187 invoked by uid 1000); Tue, 03 Nov 2020 17:25:06 -0000 Date: Tue, 3 Nov 2020 18:25:06 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Roman Danyliw Cc: The IESG , draft-ietf-core-resource-directory@ietf.org, jaime.jimenez@ericsson.com, core-chairs@ietf.org, core@ietf.org Message-ID: <20201103172506.GD45088@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="k4f25fnPtRuIRUb3" Content-Disposition: inline In-Reply-To: <159720107494.28255.1546033232009788973@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com> Archived-At: Subject: Re: [core] Roman Danyliw's Discuss on draft-ietf-core-resource-directory-25: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2020 17:25:16 -0000 --k4f25fnPtRuIRUb3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (This is one of the point-to-point follow-up mails on the RD -25 reviews; for the preface, please see the preceding mail on "The various positions on draft-ietf-core-resource-directory-25" at ). As DISCUSS: > There appear to be a few areas of straightforward, under-specified elemen= ts > of the authorization model. =20 >=20 > -- How does the RD know that a node claiming to be a CT is in fact a CT a= nd > is permitted to register on behalf of end-points? It seems like there is= a > missing, simple statement to make that this is configured out of band with > the RD? Or is that carrier somehow in a authentication credentials?=09 response: The RD does not distinguish between endpoints and CTs; both are just CoAP clients that have to present suitable credentials. The first mention of CTs in the security policies has some text to that. > -- Is there are reason why there is not normative guidance requiring the = RD > to check whether authentication clients are authorized to register partic= ular > resources? Section 7.1 covers the issue, but all of Section 7.* is > explicitly noted as informative. Section 8.1. says =E2=80=9CEndpoint aut= hentication > needs to be checked independently of whether there are configured > requirements on the credentials for a given endpoint name (Section 7.1) or > whether arbitrary names are accepted (Section 7.1.1)=E2=80=9D but this te= xt seems to > frame it as authentication issue. Section 8.2 seems to stress only the > distinction between the registration and lookup API. response: The "authentication" here is a plain error -- it is the authorization that needs to be checked. (Fixed in https://github.com/core-wg/resource-directory/pull/271). The First-Come-First-Remembered policy that is now provided should help the reader to understand how a policy can come to an authorization decision even with arbitrary endpoint names (see https://github.com/core-wg/resource-directory/pull/258). > -- Section 8.1. Per =E2=80=9CIf the server does not check whether the id= entifier > provided in the DTLS handshake matches the identifier used at the CoAP la= yer > then it may be inclined to use the endpoint name for looking up what > information to provision to the malicious device.=E2=80=9D, this is good = advice. If > DTLS PSK and RPK are used, what identifiers does the RD have to check to > ensure the DTLS and CoAP layers match? Per 9.1.3.1. (for PSK) and 9.1.3.= 2.1 > (for RPK) of RFC7252 there is the notion of identifiers for DTLS but those > don=E2=80=99t manifest in CoAP? Additionally, when DTLS with a certifica= te is used, > is it intended to compare the subjectAltName with the authority in the > Registration Base URI (i.e., which exact certificate fields should it com= pare > with the CoAP)? response: The precise identifiers used will depend on the security policies in place. The abovementioned First-Come-First-Remembered policy makes precise points about the fields to introspect for that case, other to-be-defined policies = are expected to do the same. And as COMMENT: > ** Section 3.5. Per =E2=80=9CWhen endpoints are not connected =E2=80=A6 = a remote server is > usually used to provide proxy access to the endpoints=E2=80=9D, this arch= itecture > wasn=E2=80=99t entirely clear to me. How can a proxy provide access to a= n endpoint > that isn=E2=80=99t connected? Or is proxy meant as a substitute here or = an > intermediary? response: There have been different approaches to the sleepy nodes problem. None has resulted in a WG document even, but the awake helper being a proxy is a com= mon theme. Note that a proxy does not need to contact the origin server to serve all requests as it may have a fresh representation. The different approache= s to sleepy result in "beefed up" proxies that have better chances of being able= to serve some kind of cached response. > ** Section 3.6. The home and building automation use case doesn=E2=80=99= t make any > reference to the RD architecture (like the other two use cases). response: They do now (as per https://github.com/core-wg/resource-directory/pull/264). > ** Section 4.0. Per =E2=80=9C=E2=80=A6 falling back to failing the opera= tions if recovery is > not possible=E2=80=9D, can =E2=80=9Cfailing the operation=E2=80=9D be cla= rified? response: Not without growing the text a lot. A failed operation's meaning depends on= the operation: In steps from finding an RD to registration, it means stopping whatever was just tried and continuing with other options, and eventually running out of them notifying the user. In regstration updates, it means th= at a new registration is started. In lookups, the application may fall back to methods outside the specification (eg. doing multicast discovery when no RD= is around or usable) or just report to the user. For where there is something to say, sections contain paragraphs starting "= If the ... fails". > ** Per Section 4.0. Per =E2=80=9CAn RD MAY make the information submitte= d to it > available to further directories=E2=80=9D, are there circumstances where = end points > would not want that? response: If there is a security policy in place for link confidentiality, yes. The presence of such a policy doesn't rule out replication at all, though -- if= the target directory is authorized to receive the links (as it upholds the same link confidentiality policies), forwarding can still be justified, and is expected to happen like that in managed installations. The paragraph has been amended to refer to the security policies applicable= to lookups. (Concrete change in https://github.com/core-wg/resource-directory/pull/272). > ** Section 4.1. Per =E2=80=9C2. In a network that supports multicast wel= l, =E2=80=A6=E2=80=9D, what > does it mean to =E2=80=9Csupport multicast _well_=E2=80=9D? response: "Not well" is meant to roughly summarize "not efficiently" (when the multic= ast would be flooded over many individual links), "not conveniently" (when it w= orks but the tooling around it makes it hard to use for implementations), or even "not at all" (when other CoAP transports than CoAP-over-UDP are involved). > ** Section 5. Per the ep definition of the URI Template Variables, what = does > it mean for the an endpoint to be =E2=80=9C(mostly mandatory)? "Mostly mandatory" here means that it is mandatory unless the RD is configu= red to recognize the endpoint name from the credentials. Enhancements have been made to the wording of the exception at https://github.com/core-wg/resource-directory/pull/273, which should make t= he phrase "mostly mandatory" fully understandable by the end of the item. > ** Section 7.1. Per =E2=80=9CWhen certificates are used as authorization > credentials, the sector(s) and endpoint name(s) can be transported in the > subject=E2=80=9D, recommend being more precise on what exact X.509 field(= s) you mean > when saying =E2=80=9Csubject=E2=80=9D. response: See GENERIC-SUBJECT. > ** Section 7.1.1. Per =E2=80=9CRegistrants that are prepared to pick a di= fferent > identifier when their initial attempt at registration is unauthorized sho= uld > pick an identifier at least twice as long as the expected number of > registrants=E2=80=9D, how would a registrant know the population size? response: Applications can describe typical sizes of their deployments; for example, = in a single-tenant home automation system, 256 is a sane upper bound for the size estimate, so 4 hex digits would suffice. Where there's no such estimates available, the UUID way is universally applicable. > ** Section 7.2. Per =E2=80=9CTo avoid the limitations, RD applications s= hould > consider prescribe that lookup clients only use the discovered informatio= n as > hints, and describe which pieces of information need to be verified with = the > server=E2=80=9D, I wasn=E2=80=99t sure which verification this would be. response: The intended verification is with a trusted source, which would typically be the server hosting the resource. This became part of a larger discussion around server authorization at , and while there is hope that what comes of this will be useful to CoRE (or = even web) applications in general, the changes to the text ("to request it again =66rom an authorized server, typically the one that hosts the target resour= ce", https://github.com/core-wg/resource-directory/pull/306) should make the paragraph itself clear enough. > ** Section 7.3. This section cautions about the differences between the > registrant publishes itself vs. what is in the RD. It might be worth > reiterating that the RD may also publish what it knows to others per Sect= ion > 4.0=E2=80=99s =E2=80=9CAn RD MAY make the information submitted to it ava= ilable to further > directories=E2=80=9D response: A reference has been added in the other direction, as that is where the care must be taken -- the "MAY make [...] available" now cautions about any link confidentiality policies (change in https://github.com/core-wg/resource-directory/pull/272). > ** Editorial Nits -- Global. s/can not/cannot/g response: Addressed in https://github.com/core-wg/resource-directory/pull/253 > -- Section 4. Editorial. Per =E2=80=9COnly multicast discovery operatio= ns are not > possible on HTTP, and Simple Registration can not be executed as base > attribute =E2=80=A6 can not be used there=E2=80=9D, this sentence didn=E2= =80=99t parse. response: Understandable; it was changed in https://github.com/core-wg/resource-direc= tory/pull/274. --k4f25fnPtRuIRUb3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+hknIACgkQOY0REtOk veEa9A//UH2iNUhSLBSo1hkECCS43b23c1I/+og6Jd9i8YJ+YzZU4I3VgUpXZSgi vQtfB45+WpZ9w//3l20qFO+r4sRXW+uhtcDquPWNnOGFzO2QlF2SsZGDg4Sp9UYW kGtoh0aHuDyVlVamJEx5VfctULHuxSxk9CVc1aJMwzu1kNXqccwblZIExI8tRQO2 LulbT6o1xKHQE9ELGjVUEdSm3mKCwvDYfycbXML07fsBpb1L5BX7QYBf5EFn2hM6 7vVU97In7iCqJvXfgRab26mV7bHt1KJDLY4sYmfHIdVa0SMrmLSkQpVu99gSQ0Zz o/N4KFij0CrZe+C9wSoepqpOE8JsicZWsWA4GQBAYPUw7NOdKm/6b7wq+mpA/KGN VXb8Sm+H87X4ZkuHKbI9ihUZPHH6KUB4z1r0fhp7o/kFclW72NBRb8VuU8CU1alk kTf4Vhlmrq4b2kg7n4W/XIKaT6U+cwsjAOpfzNdxEYfTvEAj08FGBxaLR7zQqEyZ Jv+PHIDC9avC4Zio/9HAYc/+9uwOm9vfNA92kecBqzblWZli44GAQv1LT4TZc6DT AKvrWUr9s/28go6PBKSLizu8o12prHlk9+B0oLCl/ovb8QI0r7lWelbKpSrlhdZA IneKLnj8L4s4SsnCyic6RFAKACCWZsD05j1fKzvRS8jQpCJP7Is= =9Ytx -----END PGP SIGNATURE----- --k4f25fnPtRuIRUb3-- From nobody Tue Nov 3 09:27:54 2020 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 927233A0DF9; Tue, 3 Nov 2020 09:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEVvABCVBX3r; Tue, 3 Nov 2020 09:27:47 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EC3F3A0DF6; Tue, 3 Nov 2020 09:27:46 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 1604A40013; Tue, 3 Nov 2020 18:27:44 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 723CEAB; Tue, 3 Nov 2020 18:27:40 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:be1b:33a0:9df5:4f6f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 3D08C34; Tue, 3 Nov 2020 18:27:40 +0100 (CET) Received: (nullmailer pid 54167 invoked by uid 1000); Tue, 03 Nov 2020 17:27:39 -0000 Date: Tue, 3 Nov 2020 18:27:39 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Benjamin Kaduk Cc: The IESG , draft-ietf-core-resource-directory@ietf.org, jaime.jimenez@ericsson.com, core-chairs@ietf.org, core@ietf.org Message-ID: <20201103172739.GE45088@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TD8GDToEDw0WLGOL" Content-Disposition: inline In-Reply-To: <159730632066.12379.5174560093789503034@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com> Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-resource-directory-25: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2020 17:27:52 -0000 --TD8GDToEDw0WLGOL Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (This is one of the point-to-point follow-up mails on the RD -25 reviews; for the preface, please see the preceding mail on "The various positions on draft-ietf-core-resource-directory-25" at ). As DISCUSS: > I agree with Roman that the authorization model seems under-developed. > While I recognize that there is need for flexibility across various > deployments, I think that we should be providing a default model (and > procedures for it) that will apply in many cases, and let > deployments specify alternate models if needed. This stuff is hard > enough to get right that we should have a secure option that people can > use if they don't need to have customized details. (To be clear, I > agree with the change of focus from -24 to -25 on the properties that a > security policy needs to provide and/or consider, as that is > fundamentally the important thing. I just want a fallback/default > option that "does something reasonable in most cases" in addition. > Doing that by reference to some other existing thing would be fine, if > such a thing exists.) response: There is no external policy we could reference, so a new section was create= d. The First-Come-First-Remembered policy implements one of the candidates that were considered for this role, and was picked because unlike its "endpoint = name comes from the certificate" it is a mode which an implementation can use without any further configuration whatsoever. The related changes can be viewed in https://github.com/core-wg/resource-directory/issues/258. > In particular, the current text seems to rely on the authorization > model including: >=20 > (1) the RD knowing how clients will be using it (and thus what > properties the RD needs to enforce), which in the general case cannot be > known (though for static networks it could be), yet I don't see any > discussion that indicates this as a prerequisite; and >=20 > (2) the client either knowing out-of-band that an entity is authorized > to act as a RD or just blindly trusting any of the unauthenticated (*) > advertisement mechanisms. (* Yes, there may be some protection in the > network on subscribing to the relevant multicast address, DNS-SD, etc., > but the client cannot a priori know that such protections are in place.) > > Relatedly, the naming model and naming authority should have some > clearer discussion. We do mention in Section 7 the possibility for a > weak naming model where the RD is responsible for enforcing uniqueness > of names but otherwise link attributes are the primary authorization > criteria (vs. a traditional scheme with a naming authority and naming > hierarchy), but with naming as a fundamental prerequisite of any > authentication/authorization scheme, I think clearer discussion of how a > naming model is to be selected (and, perhaps more importantly, that it > must be fixed as part of a given deployment) for a given network is > needed. respond: The responsibilities are the other way around. The RD does not need to know= the clients' expectations, the clients may only expect things they know to be t= rue of the RD. See GENERIC-WHOPICKSMODEL. > If I understand correctly, we have some codepoint squatting going on in > the examples (e.g., for resource types). response: The rt=3Dtemperature-c, rt=3Dlight-lux and if=3Dsensor are used where endpo= ints mimick the examples of RFC6690; it is a point here to have things look just like in direct discovery. The if=3Dcore.a and if=3Dcore.p use values from the expired and partially a= bandoned core-interfaces -- given its future is unclear, they've been replaced by examples with tag URIs, as has the et=3Doic.d.sensor (a value that's regist= ered, but not to for et but for rt) and rt=3D"light"; rt=3Dsensor was dropped as = it was not essential to the example. The individual changes are listed in https://github.com/core-wg/resource-directory/pull/266. > We should talk about the security properties of the various RD discovery > mechanisms that are defined. response: A section was added in the security considerations on this topic (see https://github.com/core-wg/resource-directory/pull/275 for text changes). It does not go into the properties of each mechanism, as the host discovery steps are generally unprotected; instead, it emphasizes the importance of checking the RD's authorization for any security properties t= he client would expect. In the context of the server authorization topic (see OPEN-SERVER), it was added that if the authorization is conditional on the resources being advertised with a particular resource type, that authorizat= ion already needs to be checked during the discovery phase (details in https://github.com/core-wg/resource-directory/pull/306). As COMMENT: > My apologies for where these comments diverge off into rambling > incoherency, or where I'm misunderstanding something that's clearly laid > out; this document had the misfortune of being the last one I got to > this week. >=20 > Section 1 >=20 > [RFC6690] only describes how to discover resources from the web > server that hosts them by querying "/.well-known/core". In many > constrained scenarios, direct discovery of resources is not practical > due to sleeping nodes, disperse networks, or networks where multicast > traffic is inefficient. These problems can be solved by employing an > entity called a Resource Directory (RD), which contains information > about resources held on other servers, allowing lookups to be > performed for those resources. >=20 > nit(?): I'd consider specifying that the RD is "a trusted entity". > (Even when the resources themselves are authenticated, a hostile RD can > still deny existence of a given resource, so by choosing to use an RD > there is some level of trust involved.) response: Putting it in there as a trusted entity would give the reader a wrong impression of the general case. Any trust placed in the RD must be earned b= y a security policy backed by the RD's credentials. > Section 2 >=20 > Resource Directory (RD) > A web entity that stores information about web resources and > implements the REST interfaces defined in this specification for > discovery, for the creation, the maintenance and the removal of > registrations, and for lookup of the registered resources. >=20 > nit: the list structure is not parallel here. Maybe "for discovery, > creation, maintenance, and removal of registrations, and for lookup of > the registered resources"? response: The intended structure that's linearized into the sadly untreeish structure= of written language was * discovery * of registrations - creation - maintenance - removal * lookup I think this is what the current text expresses, whereas the proposed one groups discovery with "of registrations", while it's more a top-level thing. > Commissioning Tool > Commissioning Tool (CT) is a device that assists during the > installation of the network by assigning values to parameters, > naming endpoints and groups, or adapting the installation to the > needs of the applications. >=20 > Is "the installation of the network" a one-time event? (Might a CT be > involved when adding a new device to a network at a later time?) response: CTs can come back to help new devices into the network; the text has been clarified to that point in https://github.com/core-wg/resource-directory/pull/295. There are remaining questions about how long a network can operate autonomo= usly while the CT is absent and can thus not refresh registrations, but those ex= ceed the scope of the document. (Discussed at https://github.com/core-wg/resource-directory/issues/290). > Section 3.1 >=20 > Information SHOULD only be stored in the RD if it can be obtained by > querying the described device's /.well-known/core resource directly. >=20 > When might that not be the case? response: The prime example here is with devices that don't even have a copy of what = they might want to (but can't for resource constraints) express there; those use= a CT to do their work. The second example I can come up with is when devices have complex confidentiality requirements on the links, but rely on the RD and thus publ= ish data to an authorized RD of which they don't even know who precisely might = be authorized to read them. > Section 3.2 >=20 > The RD architecture is illustrated in Figure 1. An RD is used as a > repository of registrations describing resources hosted on other web > servers, also called endpoints (EP). An endpoint is a web server > associated with a scheme, IP address and port. A physical node may >=20 > (side note) hmm, I feel like in the HTTP world an endpoint is more > likely to be associated with a DNS name than an IP address, in common > usage. Also, we later go on to assert that the endpoint's name has > primacy and that the IP address/port can be ephemeral. response: This is leading the reader from the CoAP definition of endpoints to the endpoints as registrants as used in the RD. > An endpoint uses specific interfaces to register, update and remove a > registration. It is also possible for an RD to fetch Web Links from > endpoints and add their contents to its registrations. >=20 > At the first registration of an endpoint, a "registration resource" > is created, the location of which is returned to the registering > endpoint. The registering endpoint uses this registration resource > to manage the contents of registrations. >=20 > Does the "RD fetches links unilaterally" case count as a "first > registration of an endpoint"? I'm having a hard time seeing how these > two statements are consistent with each other, and a naive reading > admits the possibility that a given endpoint could be "locked out" of > the ability to manage the contents of its registrations. response: The act of the endpoint triggering the RD to fetch links from it is the creation. And the "locking out" is the correct reading -- a client that uses simple client has no way of managing the contents. If it were capable enoug= h to do that, it'd go the regular registration route. > Section 4 >=20 > REST clients (registrant-EPs and CTs during registration and > maintenance, lookup clients, RD servers during simple registrations) > MUST be prepared to receive any unsuccessful code and act upon it > according to its definition, options and/or payload to the best of > their capabilities, falling back to failing the operation if recovery > is not possible. In particular, they should retry the request upon >=20 > "MUST be prepared [...] to the best of their abilities" seems > non-actionable. The stuff after "In particular", on the other hand, is > actual concrete guidance that could be mandated using normative > language. response: Right; fixed in https://github.com/core-wg/resource-directory/pull/276. > Section 4.1 >=20 > 1. In a 6LoWPAN, just assume the Border Router (6LBR) can act as an > RD (using the ABRO option to find that [RFC6775]). Confirmation > can be obtained by sending a Unicast to "coap://[6LBR]/.well- > known/core?rt=3Dcore.rd*". >=20 > nit(?): I was unaware that "Unicast" was a proper noun. response: Addressed in https://github.com/core-wg/resource-directory/pull/277. > Section 4.3 >=20 > "core.rd" in the query string. Likewise, a Resource Type parameter > value of "core.rd-lookup*" is used to discover the URIs for RD Lookup > operations, core.rd* is used to discover all URI paths for RD > operations. [...] >=20 > Is the distinction between URIs (for RD Lookup) and URI paths (for RD) > important here? response: No, it isn't. Fixed in https://github.com/core-wg/resource-directory/pull/2= 77. > While the link targets in this discovery step are often expressed in > path-absolute form, this is not a requirement. Clients of the RD > SHOULD therefore accept URIs of all schemes they support, both as > URIs and relative references, and not limit the set of discovered > URIs to those hosted at the address used for URI discovery. >=20 > I'm not sure I see how the "not limit [...] to those hosted at the > address used for URI discovery" follows from the non-requirement for > expression of the link-targets from discovery in path-absolute form. > (Given the ability to send the discovery query to a multicast address, > the guidance seems okay; it's just the "therefore" that is puzzling me.) response: If it was a requirement on the server, the clients could rely on it and thus implicitly limit the set by failing to parse the full URIs. (It could say "explicitly or implicitly limit", but only the "implicitly limit" case justifies the "therefore".) > It would typically be stored in an implementation information link > (as described in [I-D.bormann-t2trg-rel-impl]): >=20 > Req: GET /.well-known/core?rel=3Dimpl-info >=20 > This seems to be depicting a link-relation type that is not registered > at https://www.iana.org/assignments/link-relations/link-relations.xhtml > , i.e., codepoint squatting. Please put in a stronger disclaimer that > this is an example link relation type, not just an example exchange. response: A note has been added that the type is just proposed in a WIP document (in https://github.com/core-wg/resource-directory/pull/278). > Section 5 >=20 > These first few paragraphs give the impression that this is > first-come-first-served with minimal authentication or authorization > checking. Mentioning that there are authorization checks, with a > forward-reference, might be helpful. response: It's more a last-come-longest-remembered, but even the most minimal security policies would ensure that the registration resources belong to the "same" device (for whatever the policy defines as same). Clarified in https://github.com/core-wg/resource-directory/pull/292. > further parameters (see Section 9.3). The RD then creates a new > registration resource in the RD and returns its location. The >=20 > Is this returned "registration resource" expected to function as a > "capability URL" (https://www.w3.org/TR/capability-urls/) that would > need to contain an appropriate amount of entropy to be reasonably > unguessable by parties other than the registrant-ep/CT responsible for > it? response: No, it is not a capability URL -- it will be discoverable through the endpo= int lookup interface. Note that around ACE, bearer tokens (which capability URLs are) are general= ly discouraged in favor of proof-of-possession tokens. > The registration request interface is specified as follows: >=20 > Interaction: EP -> RD >=20 > I thought that the CT could be a requestor as well as the EP. response: Yes it can be. The expression in the interaction tables is an artifact of t= he CTs being a not-even-special case of EPs, but as we have both of them in the rest of the text, so do we now in those lists. (Changes in https://github.com/core-wg/resource-directory/pull/309). > well. The endpoint name and sector name are not set when one > or both are set in an accompanying authorization token. >=20 > What should the RD do if they are set but also present in the > accompanying authorization token? response: The wording has been updated in https://github.com/core-wg/resource-directory/pull/273; it now (by construction, but also explicitly) explains conflict handling. > Req: POST coap://rd.example.com/rd?ep=3Dnode1 > Content-Format: 40 > Payload: > ;ct=3D41;rt=3D"temperature-c";if=3D"sensor", >=20 > (side note) XML for the sensors, not SenML? With Carsten as an author, > even? ;) response: This is clearly a mistake, and got removed in an emergency update in https://github.com/core-wg/resource-directory/pull/279. More seriously, though, these examples are from RFC6690 (which does not have ct=3D entries for reasons of chronology), and keeping them aligned is a good thing. > An RD may optionally support HTTP. Here is an example of almost the > same registration operation above, when done using HTTP. >=20 > Req: > POST /rd?ep=3Dnode1&base=3Dhttp://[2001:db8:1::1] HTTP/1.1 > Host: example.com >=20 > Wouldn't "Host: rd.example.com" be closer to "almost the same > registration"? response: Fixed in https://github.com/core-wg/resource-directory/pull/277. (I had brief qualms about introducing a protocol-negotiation situation here, but performing "almost the same registration" over two protocols already necessarily does that). > Section 5.1 >=20 > I'm a little uneasy about specifying new behavior for POST to the > existin /.well-known/core that was defined by RFC 6690 for other uses. > What factors go into using the same well-known URI vs. defining a new > one for this usage? response: It-always-having-been-that-way, primarily. As no large deployments are know= n, this is fixed in https://github.com/core-wg/resource-directory/pull/259 by switching to a standalone /.well-known/rd. > The sequence of fetching the registration content before sending a > successful response was chosen to make responses reliable, and the > caching item was chosen to still allow very constrained registrants. >=20 > I'm not sure what "the caching item" is supposed to be (if it's not a > typo/misordering of words). response: Now phrased as "the point about caching" (in https://github.com/core-wg/resource-directory/pull/277) which should be easier to read. A few lines up we recommend that the RD caches the .wk/c, and this provides the rationale. > Section 5.3 >=20 > queries concerning this endpoint. The RD SHOULD continue to provide > access to the Registration Resource after a registration time-out > occurs in order to enable the registering endpoint to eventually > refresh the registration. The RD MAY eventually remove the > registration resource for the purpose of garbage collection. If the > Registration Resource is removed, the corresponding endpoint will > need to be re-registered. >=20 > (This MAY is actually a MUST for the simple registration case, per =A75.1, > right?) response: No, it's a choice there as well. One server may keep them around forever, a= nd when the simple client comes back it'll show with the same registration resource in the resource lookup. Another server may GC it and assign a different registration resource when it returns. > Section 5.3.1 >=20 > An update MAY update the lifetime or the base URI registration > parameters "lt", "base" as in Section 5. Parameters that are not >=20 > What about the "extra-attrs"; are they inherently forbidden from > updates? response: The introduction paragraph was overly specific and fixed in https://github.com/core-wg/resource-directory/pull/294. > base :=3D Base URI (optional). This > parameter updates the Base URI established in the original > registration to a new value. If the parameter is set in an > update, it is stored by the RD as the new Base URI under which > to interpret the relative links present in the payload of the > original registration, following the same restrictions as in > the registration. If the parameter is not set in the request >=20 > nit: is it the interpretation of relative links that is following the > same restrictions as in the registration, or the new value of the > parameter being supplied in the update? response: The restrictions apply to the new value, and were moved up there in https://github.com/core-wg/resource-directory/pull/294. > The following example shows how the registering endpoint updates its > registration resource at an RD using this interface with the example > location value: /rd/4521. >=20 > The path component "4521" contains a worryingly small amount of > unpredictableness; I would prefer examples that used longer random > locations, as for capability URLs. (Throughout the document, of > course.) See also draft-gont-numeric-ids-sec-considerations, that I'm > AD sponsoring, though I do not see any clear issues on first glance. response: See comment on the original capability URL question -- they are not. > (Also, it might be worth another sentence that this update is serving > just to reset the lifetime, making no other changes, since this might be > expected to be a common usage.) response: Stating purpose rather than mechanism now (since https://github.com/core-wg/resource-directory/pull/294). > Section 6 >=20 > With "Resource Lookup" and "Endpoint Lookup" as (apparent) top-level > siblings, would it make sense to put 6.2, or at least 6.3, as > subsections under 6.1? response: It would from a hierarchical table-of-contents point of view, but given the focus of lookup is on resource lookup, the existing sequence captures the narrative of "With an RD, you can look up resources, here is how you use it, here is what it looks like, and by the way if you really need it you can ev= en look at the registrations themselves". > Section 6.1 >=20 > Resource lookup results in links that are semantically equivalent to > the links submitted to the RD. The links and link parameters > returned by the lookup are equal to the submitted ones, except that > the target and anchor references are fully resolved. >=20 > Are the "submitted ones" the submissions at registration time, or during > the lookup query itself? (I assume registration-time, but being > explicit costs little.) response: Some words added for clarity in https://github.com/core-wg/resource-directory/pull/294. > If the base URI of a registration contains a link-local address, the > RD MUST NOT show its links unless the lookup was made from the same > link. The RD MUST NOT include zone identifiers in the resolved URIs. >=20 > Same link as what? response: The link the endpoint sits on; clarified in https://github.com/core-wg/resource-directory/pull/294. > Section 6.2 >=20 > The page and count parameters are used to obtain lookup results in > specified increments using pagination, where count specifies how many >=20 > (We haven't introduced the page and count parameters yet.) response: Wording has been enhanced in https://github.com/core-wg/resource-directory/pull/294. > operator as in Section 4.1 of [RFC6690]. Attributes that are defined > as "link-type" match if the search value matches any of their values >=20 > Where is it specified how an attribute might be "defined as > 'link-type'"? This is the only instance of the string "link-type" in > this document, and it does not appear in RFC 6690 at all... response: That should have said "relation-types"; it does now, and also refers to the 6690 ABNF (since https://github.com/core-wg/resource-directory/pull/294. > references) and are matched against a resolved link target. Queries > for endpoints SHOULD be expressed in path-absolute form if possible > and MUST be expressed in URI form otherwise; the RD SHOULD recognize > either. The "anchor" attribute is usable for resource lookups, and, > if queried, MUST be for in URI form as well. >=20 > I don't see how it can be only a SHOULD to recognize either given these > generation criteria. response: If the URI is on a different scheme/host, I assert things are clear. (Just = to ensure I didn't get your point wrong.) Otherwise, in practice there can happen mistakes where server and client disagree about the default values of the Uri-Scheme, Uri-Host and Uri-Port options -- as anyone who's ever tried to set up an HTTP reverse proxy for a WebDAV server can attest to. We're trying to avoid creating these situation= s, but when they do happen. We don't automatically declare the offending party broken by putting a MUST here, but encourage the peer to assist it. The cli= ent can help by providing the relative reference (for then, disagreement passses unnoticed), and the server by recognizing the full URI (for the client may = have obtained it and not know that it'd match what the server thinks is its Uri-= Host name). (The "and MUST be expressed in URI form otherwise" sounds like a factual necessity, but it is here to rule out the corner case of a client handing o= ut //hostname/path style references). > Section 6.3 >=20 > The following example shows a client performing a lookup of all > resources of all endpoints of a given endpoint type. It assumes that > two endpoints (with endpoint names "sensor1" and "sensor2") have > previously registered with their respective addresses > "coap://sensor1.example.com" and "coap://sensor2.example.com", and > posted the very payload of the 6th request of section 5 of [RFC6690]. >=20 > Er, the 6th request is a GET; do we mean to say the response to the 6th > request? response: Yes. Fixed in https://github.com/core-wg/resource-directory/pull/294. > Section 6.4 >=20 > The endpoint lookup returns registration resources which can only be > manipulated by the registering endpoint. >=20 > This seems to leave it unclear whether the endpoint lookup is expected > to return resources that the requestor will not have permission to > manipulate (in addition to those it does have permission for). response: Clarified in https://github.com/core-wg/resource-directory/pull/294. > While Endpoint Lookup does expose the registration resources, the RD > does not need to make them accessible to clients. Clients SHOULD NOT > attempt to dereference or manipulate them. >=20 > But why expose them at all if they're not going to be accessible? response: They serve as identifiers (think URI rather than URL), and may additionally= be used in implementation defined operations on the resource that could be all= owed for administrators. Last but not least, link-format (unlike the upcoming Co= RAL) does not have means of talking about something without naming it. (I do see the point, and if we started RD anew with the benefit of having CoRAL, chances are this would look a bit different, and the names would not= be exposed to just any lookup client). The WG discussion of this did, however, lead to a point added to the securi= ty considerations about the RD's choice of what to put in there (change in https://github.com/core-wg/resource-directory/pull/267). > An RD can report endpoints in lookup that are not hosted at the same > address. [...] >=20 > The "same address" as what? response: Sharpened in https://github.com/core-wg/resource-directory/pull/294. > Section 7.1 >=20 > Whenever an RD needs to provide trustworthy results to clients doing > endpoint lookup, or resource lookup with filtering on the endpoint >=20 > How will the RD know whether the client is expecting trustworthy > results? (When would a client *not* expect trustworthy results?) response: It won't per-client, it is configured for one. See GENERIC-WHOPICKSMODEL. > name, the RD must ensure that the registrant is authorized to use the > given endpoint name. This applies both to registration and later to > operations on the registration resource. It is immaterial there > whether the client is the registrant-ep itself or a CT is doing the > registration: The RD can not tell the difference, and CTs may use >=20 > I suppose there might be plausible authorization models where a > return-routability check to a given address constitutes authorization to > use that address as an endpoint name, in which case the RD can tell the > difference between a registrant-ep and a CT attempting to act on its > behalf. WGF-6 response: The RD might do such checks, but then again the EP might just be using different network interfaces simultaneously. At that point where the EP use= s a different (and usually dormant) network interface for registration, the line between EP and the CT gets blurry; we tolerate that blurriness because the distinction is not so much a technical one (the REST server does not care whether the request originates at its network peer, is proxied through ther= e or sent from there on behalf of someone completely different) as long as the credentials are good. Frankly, I'm personally not too happy with distinguishing CTs in the first place; it is more reflective of what I understand to be an industry practice than a distinction in this CoAP application. > When certificates are used as authorization credentials, the > sector(s) and endpoint name(s) can be transported in the subject. In > an ACE context, those are typically transported in a scope claim. >=20 > As Russ noted in the Gen-ART review, "transported in the subject" is > sufficiently vague to not really be actionable. It might be better to > say that the holder of the private key corresponding to the public key > certified in the certificate is generally considered authorized to act > on behalf of any identities (including endpoint names) contained in the > certificate's subject name. response: See GENERIC-SUBJECT. > Section 7.1.1 >=20 > Conversely, in applications where the RD does not check the endpoint > name, the authorized registering endpoint can generate a random > number (or string) that identifies the endpoint. The RD should then >=20 > How much entropy/randomness in the random name? Does a CSPRNG need to > be used? (I do see the follow-up about doubling the length in case of > failure or starting with a UUID if that's not possible, but some > guidance on where to start still seems appropriate.) respond: There is no requirement here as collisions only result in retries. For those cases where the client implementer thinks they can get away with = not implementing retry, UUID URNs are pointed to, which themselves cover the to= pic. > Section 7.2 >=20 > When lookup clients expect that certain types of links can only > originate from certain endpoints, then the RD needs to apply > filtering to the links an endpoint may register. >=20 > As before, how will the RD know what behavior clients are relying on? response: It will not. It may, however, advertise it explicitly. If, for example, an application like LwM2M always ensures trusted endpoint names, the RD may advertise as rt=3D"core.rd-lokup-ep example.lwm2m", and then clients that t= rust that metadatum (which they'll want to verify from some claim) know they can trust the RD to have checked ep names. See also GENERIC-WHOPICKSMODEL > An RD may also require that only links are registered on whose anchor > (or even target) the RD recognizes as authoritative of. One way to >=20 > I don't think I can parse this sentence (especially "the RD recognizes > as authoritative of"). response: Rephrased to "require that links are only registered if the registrant is authorized to publish information about the anchor [...] of the link." in https://github.com/core-wg/resource-directory/pull/294. > Section 8 >=20 > In contexts where we discuss DTLS and TLS as being generally comparable, > we typically will state that DTLS replay protection is required in order > to provide equivalent levels of protection. response: This item rippled quite a bit beyond the original response of "Huh? CoAP doesn't already do this? Well, here we need it". As things stand, requiring replay protection make it harder to exploit the issue described at OPEN-REPLAY-FRESHNESS, but once that is addressed for go= od, replay protection should not be necessary any more for the RD, as all its operations are becoming long-term idempotent. > We might also want to reiterate or refer back to the previous discussion > of the potential for attributes or resource/endpoint names, link > relations, etc. that may need to be confidential, the relevant access > control/filtering, and the avenues by which disclosure of resource names > can occur even when access to those resources will not be permitted. (I > think some of this overlaps with 8288 and 6690, but don't mind repeating > it.) response: There is a pointer back saying that the necessary access control depends on= the protection objectives set in the policies (since https://github.com/core-wg/resource-directory/pull/250). > Section 8.1 >=20 > It's probably worth reiterating that all name comparisons must be done > at sector scope (since failing to do so can lead to attacks). response: It is; fixed since https://github.com/core-wg/resource-directory/pull/296. > Endpoint authentication needs to be checked independently of whether > there are configured requirements on the credentials for a given > endpoint name (Section 7.1) or whether arbitrary names are accepted > (Section 7.1.1). >=20 > I think this is more properly authorization than authentication. response: Yes; fixed in https://github.com/core-wg/resource-directory/pull/271. > Section 8.3 >=20 > attacks. There is also a danger that NTP Servers could become > implicated in denial-of-service (DoS) attacks since they run on > unprotected UDP, there is no return routability check, and they can > have a large amplification factor. The responses from the NTP server > were found to be 19 times larger than the request. An RD which >=20 > (It's not clear to me why the specific discussion of NTP numbers is > relevant here, since RD is not NTP.) response: The section has been shortened in https://github.com/core-wg/resource-directory/pull/249. > Section 9.3 >=20 > Should we also include "rt" in the initial entries? I see it is used as > a query parameter for resource lookup in the examples in Section 6.3. response: It's used as is any other link attribute. There's no registry for them, and while there's been talk over ond over that it would be nice, I don't think there will be any until linkformat-CoRAL conversion is defined (and even th= en it may not be comprehensive). Selectively picking some distinguished common link attributes into this registry won't make things less messy. The prime line of defense against this getting messy is the expert guidance that for some types of parameters their short names should be checked again= st "commonly used target attributes". > * indication of whether it can be passed as a query parameter at > registration of endpoints, as a query parameter in lookups, or be > expressed as a target attribute, > > (Since this text does not clarify about lookup of endpoints vs. > resources... >=20 > Review" as described in [RFC8126]. The evaluation should consider > formal criteria, duplication of functionality (Is the new entry > redundant with an existing one?), topical suitability (E.g. is the > described property actually a property of the endpoint and not a > property of a particular resource, in which case it should go into > the payload of the registration and need not be registered?), and the >=20 > ... and this text suggests that query parameters for *resource* lookups > need not be registered.) >=20 > potential for conflict with commonly used target attributes (For > example, "if" could be used as a parameter for conditional > registration if it were not to be used in lookup or attributes, but > would make a bad parameter for lookup, because a resource lookup with > an "if" query parameter could ambiguously filter by the registered > endpoint property or the [RFC6690] target attribute). >=20 > Then why do we use it as an example of lookup filtering in Section 6.2? response: The text suggests that target attributes for registered resources need not = be registered. These unregistered wild-west attribute names can be used both w= ith resource lookups (matching only resources which), and in endpoint lookups (matching endpoints that contain any resource which). If `if` were to be put in for use in an RD parameter used with lookup, that would not per se create ambiguous queries (the rules would still say "match= es either"), but the results would be prone to causing confusion. > Section 10.1.2 >=20 > Should we really be using unregistered resource types (i.e., codepoint > squatting) in the examples? response: Addressed together with the earlier code squatting comments in https://github.com/core-wg/resource-directory/pull/266. > After the filling of the RD by the CT, the application in the > luminaries can learn to which groups they belong, and enable their > interface for the multicast address. >=20 > Just to check: the luminaries are learning their own group membership by > querying the resource directory? response: Not directly. They (in this very particular example that seems to be based = on industry process but which I'd not necessarily recommend for imitation) use= a heuristic to find any multicast URI they might possibly provide, and join t= hat group. > Section 10.2.2 >=20 > Please expand MSISDN. response: Taking a step back from this and other comments led to a drastical shorteni= ng of the example. See also GENERIC-ODDEXAMPLES > Section 13.2 >=20 > I think RFC 7252 should probably be normative. >=20 > Likewise for RFC 8288 ("the query parameter MUST be [...] a token as > used in [RFC8288]"). response: RFC7252 (CoAP) and RFC7230 (HTTP) were promoted to a normative reference. (RFC7641 (CoAP observe) wasc left as informative because while they are optional components, RD is not so much specified using them but more happen= s to combine with them). RFC8288 was also promoted, but not due to the quoted line (that's not implementation relevant but merely setting out rules for the registry operation), but because we explicitly pull it in in terminology and the information model. (Changes in https://github.com/core-wg/resource-directory/pull/307). --TD8GDToEDw0WLGOL Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+hkwsACgkQOY0REtOk veFKzhAAyUM+vgvN0QJSK7GS9+VwCA6hnzsVQnMTq8ijNYRCUiO/G1fGWf4o6Cge yX0I/fZUXkDzmVso89hZQUnuGrF5fw+b7YHWpIblIzq55Zfr18lpq4dtPIiwT1dv kNoKvL5pfTahtEYUiZwnZ8i1AclUly6v+PyJCthWnPVKjrxgJA032D3MC5tyenDo UGbOfiwoL+WQ5/CMS+LqavNIXZuIxlWxAd0FUM3GWRkqNfaxWf79WaskuEPU9vNp OARiLT+77PyjvuFuyHtuZRBTIM/c5hqtfjdZ2Lw0C/y1E5Xg3wijy9AkDuXQLAYp 6LOabns2bYsTD1yOA9xRE5tNd3QXZd7EKi9a33cFrfneX1+AmQRuQpZsD3rxyAGs 5POgwHg0kTHkEhbDpdHgbKg4nPdLBItGC5AUwRQXvfuET2pXIAgDK4U2cHAFkA0L gfZWZva300ILhikr5KtJ2zX7uSqSB3JzMXzBSZ0HwmxMVftLSIgwd4PfkElbGzb4 B65ktcFrECW5psiu2D3R+8sKchzAn2cm/g4hiroWxXPrbwQoGzbTAJCnx7XtW0La d66jEwnHTAHBys1kQqfLlZMbTubjlw+xKVAHcW57cBnco5/eDsNfA/OQXczo5aHg QZ6S1ad+lTS0Csu1xJGdMWdGRU7a+gt0QYs3vfot1bA15k8pm7E= =BikH -----END PGP SIGNATURE----- --TD8GDToEDw0WLGOL-- From nobody Tue Nov 3 09:29:02 2020 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 E171D3A0DEF; Tue, 3 Nov 2020 09:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKLcktLejACd; Tue, 3 Nov 2020 09:28:53 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1AF53A0DEC; Tue, 3 Nov 2020 09:28:52 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 3BEFA40013; Tue, 3 Nov 2020 18:28:50 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 49463AB; Tue, 3 Nov 2020 18:28:48 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:be1b:33a0:9df5:4f6f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 27A3B34; Tue, 3 Nov 2020 18:28:48 +0100 (CET) Received: (nullmailer pid 54403 invoked by uid 1000); Tue, 03 Nov 2020 17:28:47 -0000 Date: Tue, 3 Nov 2020 18:28:47 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Erik Kline Cc: The IESG , draft-ietf-core-resource-directory@ietf.org, jaime.jimenez@ericsson.com, core-chairs@ietf.org, core@ietf.org Message-ID: <20201103172847.GF45088@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Wb5NtZlyOqqy58h0" Content-Disposition: inline In-Reply-To: <159721596413.8457.13314798043091474779@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com> Archived-At: Subject: Re: [core] Erik Kline's Discuss on draft-ietf-core-resource-directory-25: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2020 17:28:56 -0000 --Wb5NtZlyOqqy58h0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (This is one of the point-to-point follow-up mails on the RD -25 reviews; for the preface, please see the preceding mail on "The various positions on draft-ietf-core-resource-directory-25" at ). As DISCUSS: > [ section 4.1.1 ] >=20 > * Did this get presented to 6man at any point, either via mail to the lis= t or > chair or in a presentation slot at an IETF meeting or a 6man interim? >=20 > I feel confident that there would be no objection to the option as desc= ribed > here, but the working group should have its chance to make an evaluation > irrespective of my opinion. see: GENERIC-6MAN > If this is to be used when link-local methods don't work, another option > would have been to add an RD PVD API key and recommend including a PVD > option. response: The RDAO should compose well with PvD based options without further measure= s, but does not receive explicit treatment here as no use of PvDs is known with constrained devices yet. Please see the more comprehensive discussion of Pv= D in the comment =C9ric Vyncke raised. > [ section 4.1.1 & 9.2 ] >=20 > * Please clarify which ND messages can carry an RDAO. I suspect they sho= uld > only appear in RAs, but it would be good to state the expectation expli= citly. respond: You are right, and the text now says so. The concrete change is in https://github.com/core-wg/resource-directory/pul= l/262. > [ Appendix A. ] >=20 > * Can you explain the ff35:30:2001:db8:1 construction? RFC 3306 section 4 > defines some fine-grained structure, and I'm wondering how a group ID o= f 1 > is selected/computed/well known. If there is already a COAP document > describing this vis. RFC 3307 section 4.*, perhaps it's worth dropping a > reference in here. response: See GENERIC-FFxxDB As COMMENT: > [ section 1 ] >=20 > * I'm unclear on what "disperse networks" might mean. response: Well how do I phrase this ... so were we. As the term does not provide justification for using an RD, it was removed from abstract and introductio= n in https://github.com/core-wg/resource-directory/pull/269. > [ section 10.1.1 ] >=20 > * What is meant by "therefore SLAAC addresses are assigned..." followed b= y this > table of not-very-random-looking IPv6 addresses? >=20 > Is the assumption that there might not be some off-network DNS server b= ut > there is some RA with a /64 A=3D1 PIO? response: There are two scenarios that satisfy the tacit assumptions -- a router can = be in place without an uplink or any DNS server and still supply ULA A=3D1 PIO= s, or there is a routable prefix around, but not yet coordinated with the lighting installation. The 2001:db8:: addresses are indeed not what one would get out of SLAAC, but full random addresses would make the examples hard to read. Where the addre= sses are introduced, they are now called stand-in addresses for the examples (see https://github.com/core-wg/resource-directory/pull/268 for full change). --Wb5NtZlyOqqy58h0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+hk08ACgkQOY0REtOk veH9tQ//Yq4hGkclh40Man2N6plrMbeY+/fJFQG1diCp0o08YDoo0W/bj1IePzQw HQ881J9DzqFTpg5ZQUhLC54qm1qvGTCIX6UAGiYIgtbdh2mtqonA0jd4wS1c0E64 pdwdqJKgylrctjj+G/XYtRjrzZLKUi1dRDhNvlCYAY7gXbKOuMoh7v/IwKYNjN6K cLItk7rJu5yg+pddCwLAtBSrtFNNx077D06SSkMYLpt5DUXbASch6FXMlIi6A2ny tGAr5dtUlXclZQn325gyHJlmyP4BW1CT7KomCp4OZtzGfiOHklq4Gl2AgalXeNcE T8rmfmpJ3YrqtWp7RVTllZg1m1Tb96Qv/XFEFb/ikhI55FHY1J9GrZMixLaBoAdT rL5xrbK+Hia6WWLEojl00NRnf9SgXA7Tb/wpGgwyjyIWaxVm3u3NeQfz9wh5/MfE W1Y1iIT0Z+94GJgIpkcODAd0iMPwgevW94gxLIbfY42MjS7FJ4PJkdUZeze6/irM hilzihq7UG0yBpmZ6rrsBHOBG921clu/hxFfV3p9/4X/FzWsATmVu/xWQmgI3PcL muRK5xxJuShQ0wS+H11rCgP4l0XgfZ1LisJkTyH46oJycw9w/KheUyxJ+ToT0Qg5 AC/PNxg95ESchXU7zo4zUtOjARgUMO4V4ZvzZKBbYWeqn+fMwr4= =w4Zd -----END PGP SIGNATURE----- --Wb5NtZlyOqqy58h0-- From nobody Tue Nov 3 09:30:44 2020 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 0BFAC3A0E06; Tue, 3 Nov 2020 09:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-8_gl5L6nPS; Tue, 3 Nov 2020 09:30:39 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 235F13A0E02; Tue, 3 Nov 2020 09:30:39 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id BA52D40013; Tue, 3 Nov 2020 18:30:36 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id A6BDBAB; Tue, 3 Nov 2020 18:30:35 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:be1b:33a0:9df5:4f6f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 875F734; Tue, 3 Nov 2020 18:30:35 +0100 (CET) Received: (nullmailer pid 54912 invoked by uid 1000); Tue, 03 Nov 2020 17:30:35 -0000 Date: Tue, 3 Nov 2020 18:30:35 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: =?iso-8859-1?Q?=C9ric?= Vyncke Cc: The IESG , jaime.jimenez@ericsson.com, core-chairs@ietf.org, bob.hinden@gmail.com, draft-ietf-core-resource-directory@ietf.org, otroan@employees.org, core@ietf.org Message-ID: <20201103173035.GG45088@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WkfBGePaEyrk4zXB" Content-Disposition: inline In-Reply-To: <159661278180.30518.10421410106159995546@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com> Archived-At: Subject: Re: [core] =?iso-8859-1?q?=C9ric_Vyncke=27s_Discuss_on_draft-ietf-co?= =?iso-8859-1?q?re-resource-directory-25=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2020 17:30:42 -0000 --WkfBGePaEyrk4zXB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (This is one of the point-to-point follow-up mails on the RD -25 reviews; for the preface, please see the preceding mail on "The various positions on draft-ietf-core-resource-directory-25" at ). As DISCUSS: > Thank you for the work put into this document. I am little puzzled by the > document shepherd's write-up dated more than one year ago (the responsibl= e AD > has even changed and the change is not reflected in the write-up)... while > well-written this write-up seems to indicate neither a large consensus no= r a > deep interest by the CORE WG community. But, I am trusting the past and > current responsible ADs on this aspect. response: The shepherd write-up has been updated. > Did the authors check with 6MAN WG about the new RDAO option for IPv6 NDP= ? I > was unable to find any 6MAN email related to this new NDP option and, aft= er > checking with the 6MAN WG chairs, they also do not remember any discussio= n. response: Just recently (see GENERIC-6MAN). > =3D=3D DISCUSS =3D=3D >=20 > -- Section 4.1 -- It will be trivial to fix, in IPv6 address configuration > (SLAAC vs. DHCP) is orthogonal to DHCP 'other-information'. E.g., even if > address is configured via SLAAC, DHCPv6 other-information can be used to > configure the Recursive DNS Server (or possibly the RD). response: Thanks, fixed in https://github.com/core-wg/resource-directory/pull/263. Conversely, the RDAO's applicability is now phrased more generally as well. > -- Section 4.1.1 -- Another trivial DISCUSS to fix: in which message is t= his > RDAO sent ? I guess unicast Router Advertisement but this MUST be specifi= ed. response: Indeed; fixed in https://github.com/core-wg/resource-directory/pull/262. As COMMENT: > =3D=3D COMMENTS =3D=3D >=20 > In general, I wonder how much interactions and exchanges of ideas have > happened in the long history of this document with the DNSSD (DNS Service > Discovery) Working Group that has very similar constraints (sleeping node= s) > and same objectives. WGF-5 response: Discussion was primarily on the level of granularity of service description (what is announced in DNS-SD often corresponds to multiple resources in an = RD), and on protocol negotiation (input which is more suitable for the protocol-negotiation work than it is going into RD). > -- Section 2 -- To be honest: I am not too much an APP person; therefore,= I > was surprised to see "source address (URI)" used to identify the "anchor= =3D"... > I do not mind too much the use of "destination address (URI)" as it is re= ally > a destination but the anchor does not appear to me as a "source address".= Is > it common terminology ? If so, then ignore my COMMENT, else I suggest to > change to "destination URI" and simply "anchor" ? response: "Context" is the term that RFC8288 uses, and other than when defining the Context we don't use source address for that (as that term is used more commonly with CoAP/UDP messages). The "source" part in the definition has no clear lineage in RFC8288 (which = does not introduce the term formally), it stems from a link going "from" somewhe= re (the context, or source) "to" somewhere (the target, or destination). > -- Section 3.3 -- Should the lifetime be specified in seconds at first us= e in > the text? WGF-3 response: The lifetime is thought of as a quantity of time, which is only expressed in multiples of a unit when serialized (and there, it is consistently used with seconds). > -- Section 3.6 -- Is the use of "M2M" still current? I would suggest to u= se > the word "IoT" esp when 6LBR (assuming it is 6LO Border Router) is cited > later. response: For Home and Industrial Automation, IoT is indeed used more commonly these days. Updated in https://github.com/core-wg/resource-directory/pull/297. > Please expand and add reference for 6LBR. response: Done (in https://github.com/core-wg/resource-directory/pull/297). > Using 'modern' technologies (cfr LP-WAN WG) could also add justification = to > section 3.5. response: At least with the currently available setups, the cellular applications have the "advantage" (from the perspective of motivating the RD) that they are l= ess integrated with typical application deployments, and thus have a more pronounced need for discovery in networks that are not under full control of the device operator. > -- Section 4.1 -- About "coap://[MCD1]/.well-known/core?rt=3Dcore.rd*", w= hat is > the value of MCD1 ? The IANA section discuss about it but it may help the > reader to give a hint before (or simply use TBDx that is common in I-D). response: TBDx would have been easier in hindight, but there's hope that until RFC ed= itor replaces that, more people will be reading the diffs than new people that m= ight stumble here will read the document, so it's kept that way. > Any reason to use "address" rather than "group" in "When answering a > multicast request directed at a link-local address" ? No, and 'group' should reduce the chances of readers overlooking that this = is about multicasts. (Changed in https://github.com/core-wg/resource-directory/pull/297). > Later "to use one of their own routable addresses for registration." but > there can be multiple configured prefixes... Which one should the RD sele= ct ? > Should this be specified ? response: I don't think it needs to be fully specified out (especially as this is mer= ely a suggestion), but the terms of RFC6724 seem to be helpful and were added in https://github.com/core-wg/resource-directory/pull/298. A review from this has been requested in the review request to 6MAN (see GENERIC-6MAN). > As a co-author of RFC 8801, I would have appreciated to read PvD option > mentionned to discover the RD. Any reason why PvD Option cannot be used ? response: Probably because 8801 was just published, and the RDAO predates even -pvd-0= 0 by a year. Sassiness aside, as I understand the PvD option from a skim and the vague recollections of having had a look at this at some earlier time, this would= be orthogonal to the RDAO: a router with multiple PvDs could forward the RDAO = =66rom either uplink inside PvD options, and pick a primary one to forward to PvD-unaware hosts. I don't see any conflict, but don't see much potential either (are there ma= ny constrained devices that benefit from becoming PvD-aware?) -- so I'd keep i= t as with any other RA option: They can be combined, but there's no particular reason to point that out on either side. If such a combination can be expected, this could be a good example for the "MAY keep concurrent registrations if explicitly configured to do so" part,= but that was not added in this iteration for lack of known use cases. (This is slightly more interesting in cases when the RD picks the addresses= ; a note on that will appear in the next version of draft-amsuess-core-resource-directory-extensions). > -- Section 4.1.1 -- I suggest to swap the reserved and lifetime fields in > order to be able to use a lifetime in units of seconds (to be consistent = with > other NDP options). response: Implementors will appreciate that; done in https://github.com/core-wg/resource-directory/pull/299. > -- Section 5 -- May be I missed it, but, can an end-point register multip= le > base URI ? E.g., multiple IPv6 addresses. response: No, that is deferred to protocol-negotiation (where whatever comes out of i= t is expected to do multiple addresses on the same protocol just as well as different protocols). > -- Section 9.2 -- For information, value 38 is already assigned to RFC 87= 81. response: Leaving it in the draft as-is, anticipting that IANA just picking the next available number will create less total cognitive load than another set cha= nged lines in the diffs. > =3D=3D NITS =3D=3D >=20 > -- Section 2 -- The extra new lines when defining "Sector" are slighly > confusing. Same applies to "Target" and "Context". This is cosmetic only. response: We're having issues with the tooling here; if it can't be ironed out before= the final version, this will be fixed manually during the handover to RFC edito= r. Issue: https://github.com/core-wg/resource-directory/issues/252 --WkfBGePaEyrk4zXB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+hk7sACgkQOY0REtOk veFabBAAgp8IFWV30CWwA1wX4ttoChBnYYguXzr7TzvRUyRFNJdJS9RE6KCCsWbK iMHupLhRAgIVxrU3AMpwjOl37QmgTRhLcCqJFwdaYGi2iWy0r4rlZ5FgxeddxHa/ vDTe1/egSaT6lhzdgwP7bi7Uc7acYJjOBQcBD13y/bs0qP4SIpBrJFeRkKkBzyTn feQwfbEGewS9y6LrOV6bT0k7mdkwGWykYaXeMxvsoyzrHVjl3HpnADaIURAE0jGl NllzDSFjWMYc2XM2FwiBOgwkOlu+QQsJoJv+FUNpq0pAr8BmuTQy4nzvm1LCGkF0 vC3zS/y2I5NQVpfwSDqdz6J5Rh7Bhm7XrZ1h6ROFmk2DiEYJQ6+FGsV8CGwy78ZU ky9sxhUgLJPs0F504rzukTXp6poTaGHccqlL3ier0oVkXoTrLmr4uActJLc76Jh3 rU232i4XYGUcXcJHc7ejUo2zET0ftBDBsnYimjfvgRbRHeErORKHbmYRVXJp7Yl2 ho3niDtkYLuQsO9dW4h86XUH7XnXZpuDsXwItgybF/8HzV8oCaw0VkGvYBs46OD6 TaMAfepeyh5mVw0rCUn6miqSOled/FcJBIpjsvn474kLT/1nGRrkuMD+3kXLUJyC 6MAmYoUfmEr1e6Y7q47ClhUWBgKewABmxQ4cMHJxivs6s31BCXk= =Vs4z -----END PGP SIGNATURE----- --WkfBGePaEyrk4zXB-- From nobody Tue Nov 3 09:31:58 2020 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 1B7E43A0E06; Tue, 3 Nov 2020 09:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ibj5STLWGIYj; Tue, 3 Nov 2020 09:31:51 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A108B3A0E02; Tue, 3 Nov 2020 09:31:50 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 54EF040041; Tue, 3 Nov 2020 18:31:48 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id C31B4AB; Tue, 3 Nov 2020 18:31:47 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:be1b:33a0:9df5:4f6f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 7327A34; Tue, 3 Nov 2020 18:31:47 +0100 (CET) Received: (nullmailer pid 55138 invoked by uid 1000); Tue, 03 Nov 2020 17:31:47 -0000 Date: Tue, 3 Nov 2020 18:31:47 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Martin Duke Cc: The IESG , draft-ietf-core-resource-directory@ietf.org, jaime.jimenez@ericsson.com, core-chairs@ietf.org, core@ietf.org Message-ID: <20201103173147.GH45088@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Yia77v5a8fyVHJSl" Content-Disposition: inline In-Reply-To: <159729581019.30986.4796757249133933498@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com> Archived-At: Subject: Re: [core] Martin Duke's No Objection on draft-ietf-core-resource-directory-25: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2020 17:31:53 -0000 --Yia77v5a8fyVHJSl Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (This is one of the point-to-point follow-up mails on the RD -25 reviews; for the preface, please see the preceding mail on "The various positions on draft-ietf-core-resource-directory-25" at ). > One nit: the sentence that contains =E2=80=9Ccannot be executed as a base= attribute=E2=80=9D > appears to have been mangled. response: The paragraph has been reworded (in https://github.com/core-wg/resource-dir= ectory/pull/274). --Yia77v5a8fyVHJSl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+hlAMACgkQOY0REtOk veFV8w/+PnnCbkDl1kygTfOTh6uwGShUM5IkC+s5Q+V7pY33YJIgrnLk8NBOSZWO H0t2NiH85Bd49/yHRwrqFxRqhouTpdAu/ij97hr1AyRvOXBzJGBHNZgc5r/BAhfY 0PmEruCY7KOTOZdnbGlj3PMEPptk3IqJpvksO0McBCOcrs7fzs5ubg60SJrr64kG m0au0PAlOjTkRQM2c4PW8xclvBoTgAOGspvU2PGf7/PjxvHnf0bqfCCJs3Jh/yPG wdlRSB+2WMd7BlfqMUcEhcTJ7wuCUYcNQwYLNm5QuNYIGfkZ6QVTI0Nq46U6qHRg ZgCuHRWweCk/nST+pwg7xS2Pk+R8vRf55WkDRDAmpwrtH3aIPDJTs1Iw44O+A72l DIbvugs6KEeIKhoWSc1d7IH6ZwY4fqeX/PeOiL2qfnS3YSf6GjxvyuScBDR9XvCP 84cmuxI+o4WBmqSiuo5h+IyIGUQxny2pjE+xstrmo31AlVUDY0CVULCInhkHNSHQ H67ykxqtW83hsSos8iq3hFgqvDN9HfCFBsKvkjK1hF4ANa9NqoaW0xfibQEFVLOE Kwhbp+6/rGeiWZa+7wmDyu2V0Tbm+4O8bZBudwLVW6COSAFVNWQfNlFWjXJpZwbA 1ksZ4YUa8W3DjftXfaJMAi15y8ClarOJp6OfxsrxPMWIBsmov0s= =1fVb -----END PGP SIGNATURE----- --Yia77v5a8fyVHJSl-- From nobody Tue Nov 3 09:32:51 2020 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 7AB4C3A0E10; Tue, 3 Nov 2020 09:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7NBSYCbn4iY; Tue, 3 Nov 2020 09:32:46 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948F03A0D98; Tue, 3 Nov 2020 09:32:45 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id CA77240041; Tue, 3 Nov 2020 18:32:43 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 544E2AB; Tue, 3 Nov 2020 18:32:43 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:be1b:33a0:9df5:4f6f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 1FE8334; Tue, 3 Nov 2020 18:32:43 +0100 (CET) Received: (nullmailer pid 55304 invoked by uid 1000); Tue, 03 Nov 2020 17:32:42 -0000 Date: Tue, 3 Nov 2020 18:32:42 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Murray Kucherawy Cc: The IESG , draft-ietf-core-resource-directory@ietf.org, jaime.jimenez@ericsson.com, core-chairs@ietf.org, core@ietf.org Message-ID: <20201103173242.GI45088@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="D6z0c4W1rkZNF4Vu" Content-Disposition: inline In-Reply-To: <159730418060.12332.7885245575969951169@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com> Archived-At: Subject: Re: [core] Murray Kucherawy's No Objection on draft-ietf-core-resource-directory-25: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2020 17:32:48 -0000 --D6z0c4W1rkZNF4Vu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline (This is one of the point-to-point follow-up mails on the RD -25 reviews; for the preface, please see the preceding mail on "The various positions on draft-ietf-core-resource-directory-25" at ). As COMMENT: > In Section 9.2, you might want to mention that you're talking about a > sub-registry under "Internet Control Message Protocol version 6 (ICMPv6) > Parameters". response: Expanded (in https://github.com/core-wg/resource-directory/pull/300). > In Section 9.3, you enumerate six fields in each registration, but the > initial table of entries has only five columns. It's obvious (I think) that > the sixth column would be "this document" for all entries, but I suggest that > you should either include the column or some prose making this explicit > (since everything else is). response: There is a sentence in the paragraph below the figure to that respect. --D6z0c4W1rkZNF4Vu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+hlDoACgkQOY0REtOk veFWPhAAyFUmlSar4yVGbrwYmYdTkpHgngD/4/3QGDycY7mybad99HtYL6+PNZr7 AYYUBJj2xaB8HnBzGnUZhXMCBGOZdtNQUQqDLh2LFgLbV0XN+XhURUXsUqOZEqJH SeDyxOOYnFuVK5oSZgmSmh5r7WsQ8IPsRPAIT/7aBQLL9tdZm8T6YaQhktwQn2pu EdogOou5U5xyrHX4CuAX57ZAQe1fzPQ92IGVF1fVEhFE8bPupmsqxwoxTlgs68Ib nmD/leIjsMIKl2+TGuI5s/GWtpJwCyoSoITBnRUEWxP9SQRXWOGmAtZ9K/4sVDuW f+EosV998wfvltstKG+Y9ztBw/rj0frhDbOqBj/yh6tyK1pyK1n5rwNqaNdIpuOX 2iHIh/CfFc2d5gH/ItCiWB3jypTqXPb8wCF52M5phxrk4XvS0rGDC5VeeS4zm9l3 kmVjMURKDx2XJB9Jn004amJyTqa8z1oE81OB6A235wQ+A+v7tYRCIm3WpGTHfNQQ Zt8Qzn+ldBDxQbwgFnX7zIUA9GTdbbVynB65LCc7d+rlmp7YZ5Y+dnhQRfwo86ho glB7NYX1aesQfjdiXfBtqvUyzT4Md0q4ewFHmxheFBv956E2U4Qf1+u/NGOcgnCi eRRfupU/2UPqS1gpa5TmNY6VeZjUyx07RDlUEeWotoIDiaTvHLg= =xwm5 -----END PGP SIGNATURE----- --D6z0c4W1rkZNF4Vu-- From nobody Tue Nov 3 09:34:15 2020 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 F18253A0DDD; Tue, 3 Nov 2020 09:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXiQb4ATuaN3; Tue, 3 Nov 2020 09:34:09 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96503A0D98; Tue, 3 Nov 2020 09:34:08 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 31AB340041; Tue, 3 Nov 2020 18:34:07 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 5C5E0AB; Tue, 3 Nov 2020 18:34:06 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:be1b:33a0:9df5:4f6f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 1B9C934; Tue, 3 Nov 2020 18:34:06 +0100 (CET) Received: (nullmailer pid 55595 invoked by uid 1000); Tue, 03 Nov 2020 17:34:05 -0000 Date: Tue, 3 Nov 2020 18:34:05 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Warren Kumari Cc: The IESG , draft-ietf-core-resource-directory@ietf.org, jaime.jimenez@ericsson.com, core-chairs@ietf.org, core@ietf.org Message-ID: <20201103173405.GJ45088@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dwWFXG4JqVa0wfCP" Content-Disposition: inline In-Reply-To: <159717402717.27772.14957520028083871786@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com> Archived-At: Subject: Re: [core] Warren Kumari's No Objection on draft-ietf-core-resource-directory-25: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2020 17:34:11 -0000 --dwWFXG4JqVa0wfCP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (This is one of the point-to-point follow-up mails on the RD -25 reviews; for the preface, please see the preceding mail on "The various positions on draft-ietf-core-resource-directory-25" at ). As COMMENT: > Comments: > > 1: "These CTs are thought to act on behalf of endpoints too constrained, = or > generally unable, to present that information themselves. " > > This reads very oddly - "thought to act on" sounds like we've seen some of > these in the wild, and only have a vague idea about how they work. Does > "These CTs act on behalf of endpoints too constrained, or generally unabl= e, > to present that information themselves. " work? response: Yes that works. (Fixed in https://github.com/core-wg/resource-directory/pull/301). > 2: "From the system design point of view, the ambition is to design > horizontal solutions that can enable utilization of machines in different > applications depending on their current availability and capabilities as = well > as application requirements, thus avoiding silo like solutions" - this is > very buzzwordy, and I have no idea what it is actually trying to say... response: What it was trying to say was that parts of the complete system should not = be specific to an application. The sentence has been replaced with something t= hat is less keyword oriented and more descriptive. (See https://github.com/core-wg/resource-directory/pull/302 for precise tex= t). > 3: " A (re-)starting device may want to find one or more RDs for discove= ry > purposes." > > Either I don't understand what this sentence is trying to say, or "for > discovery purposes" should be dropped....=20 response: The intention here was to express that some host must be found before the further URI discovery steps can take place. Enhanced in https://github.com/core-wg/resource-directory/pull/301. > 4: "As some of the RD addresses obtained by the methods listed here are j= ust > (more or less educated) guesses, endpoints MUST make use of any error > messages to very strictly rate-limit requests to candidate IP addresses t= hat > don't work out. " What happens if device A discovers RD X, and device B > discovers RD Y? Surely there has to be some sort of deterministic method = so > that one doesn't end up in a "split brain" type outcome?=20 response: There are various approaches that can apply depending on the actual applica= tion: * In managed networks, care can be taken to not make multiple RDs discovera= ble. * In larger setups, multiple RDs may be available but set up for federation= as it is being explored in draft-amsuess-core-rd-replication * RDs that are deployed without overarching coordination can opt for the Opportunistic Resource Directory approach that is being explored in draft-amsuess-core-resource-directory-extensions, where one RD yields to = the other. The error handling steps in RD make that transition smooth. But long story short, this draft does not attempt to solve them. > Nits: > > 1: " The input to an RD is composed of links and the output is composed of > links constructed from the information stored in the RD." While true, th= is > sentence doesn't actually communicate anything useful to the reader -- I'd > suggest removing it from the Abstract (note that this is just a nit). response: There has been repeated confusion about what an RD stores, with people understanding it to store resources. This sentence serves to visibly emphas= ise that only links go in and out. > 2: "The RD is primarily a tool to make discovery operations more efficient > than querying /.well-known/core on all connected devices, or across > boundaries that would be limiting those operations." > > s/would be limiting those/that would limit those/ response: Fixed in https://github.com/core-wg/resource-directory/pull/253. --dwWFXG4JqVa0wfCP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+hlI0ACgkQOY0REtOk veFn/A/9EaBXb8UzOjLzngTLfhtyFY6Lxn+fzzMXqGMUUYKcUEUni8FJmfcCgFQJ LoQSW15B3EytzEOBSkN9EDq8x32RQ4D1jZR/wtBV/d++Tvz2Zy2qTenMSBEMwkU6 Ujim9FL2Ba3zAlXJH4SxxnY2V+1ixTmaBWbIqN9jKFS+GpBluu0KvO9HcW14HGDM Y2UE1owvVurAjdr/agq4G8IYDWgpApOmylNHzlyXnHweIfuBE0o3atumnzbFV+5+ 3F69s5TTFweCq5t5khzx10sj4ZQbHAjrPkXnT3GfG1clNZeuXUK54ft3tCVvJ3ok NTfaff87wIGMABZqg7+HHV7nA5uC740GzI7kDNPUnWPewPei5aYzYx5XiktfWAcO 6CWao54bYovVzP4T7/5fVUutO4BZ7fT/PsTtROtQWGanoBw8g80o8veQi3g44d6G BpYDRyrHIDkd+M3a+I4cHuza3aAYqvjncgzdYmovhxGrl7HKsCC+GhbVHRb1HBXK DcLLZ6UMKUgJjKgqOoMM/aLKC1MuULGzqzBtFlQ/xx9d4nIXmo9C3IG5eFDXgyzq KNPExbwhwPA2Mj1zY2YA9kc6NuM7ywFkjRbaKXQtCo7pDUCRZjXpQCbZdUcfZHeZ 50kwsmT3nC11lqOh5yVYUOfi0f2e1cTC3ovJXg7Phc0goImF+yU= =TTik -----END PGP SIGNATURE----- --dwWFXG4JqVa0wfCP-- From nobody Tue Nov 3 09:35:45 2020 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 5BF633A0E30; Tue, 3 Nov 2020 09:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O61nwhifQ3hi; Tue, 3 Nov 2020 09:35:31 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A54823A0E10; Tue, 3 Nov 2020 09:35:31 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id EB22340041; Tue, 3 Nov 2020 18:35:29 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 35803AB; Tue, 3 Nov 2020 18:35:28 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:be1b:33a0:9df5:4f6f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id E60CD34; Tue, 3 Nov 2020 18:35:27 +0100 (CET) Received: (nullmailer pid 56033 invoked by uid 1000); Tue, 03 Nov 2020 17:35:27 -0000 Date: Tue, 3 Nov 2020 18:35:27 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Robert Wilton Cc: The IESG , draft-ietf-core-resource-directory@ietf.org, jaime.jimenez@ericsson.com, core-chairs@ietf.org, core@ietf.org Message-ID: <20201103173527.GK45088@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NqNl6FRZtoRUn5bW" Content-Disposition: inline In-Reply-To: <159732268335.29656.5724379569570361825@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com> Archived-At: Subject: Re: [core] Robert Wilton's No Objection on draft-ietf-core-resource-directory-25: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2020 17:35:40 -0000 --NqNl6FRZtoRUn5bW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (This is one of the point-to-point follow-up mails on the RD -25 reviews; for the preface, please see the preceding mail on "The various positions on draft-ietf-core-resource-directory-25" at ). As COMMENT: > I'm glad that the shepherd's writeup indicates that there are implementat= ions > since that indicates that there does appear to be value in standardizing = this > work, despite its long journey. >=20 > My main comment (which I was considering raising as a discuss) is: >=20 > Since this document is defining a new service, I think that this document > would benefit on having a short later section on "Operations, Administrat= ion > and Management". This document does seem to cover some > management/administration considerations in various sections in a somewha= t ad > hoc way, but having a section highlighting those would potentially make it > easier deploy. Defining a common management model (or API) would potenti= ally > also make administration of the service easier, I don't know if that had = been > considered, and if useful could be done as a separate document. response: The wide variety of possible deployments and associated security policies m= ake it hard to say anything generic on operations. We did, however, add an exemplary and potentially default security model (based on Ben's suggestion= , in https://github.com/core-wg/resource-directory/issues/258). The configuration options for such an RD are listed at its end (since https://github.com/core-wg/resource-directory/pull/303), but how to set them is out of scope here. (CORECONF would be a good candidate, but too little exploration has gone into RD configuration using that yet to warrant= a reference). > A few other comments: >=20 > 5.3. Operations on the Registration Resource >=20 > An endpoint should not use this interface for registrations that it > did not create. This is usually enforced by security policies, wh= ich > in general require equivalent credentials for creation of and > operations on a registration. > > What happens if an endpoint is managing the registration and is upgraded = to > new hardware with a different certificate? Would the updated endpoint ex= pect > to be able to update the registration? Or would it have to wait for the > existing registration to timeout (which could be a long time)? response: Certificates are not compared by literal comparison of the certificate, but= by whether their claims are sufficient for the resource (which in the end establish an identity). With unmanaged setups like the newly introduced First-Come-First-Remembered policy, a device with a new certificate might become uneligible for accessi= ng its previous registration resource (and likewise for reregistering with the same endpoint name and sector), but in such a setup the endpoint is prepare= d to switch names anyway when it comes up with the new certificate. (Although it should rarely come to that -- when the certificate is updated with the same subject claims by an authority the RD recognizes, the new one is good for continuation). In managed setups, it is up to the managers to configure EPs with certifica= tes matching their endpoint names, and when the name does not change, the new certificate is good for continuation as well. > 5.3. Operations on the Registration Resource >=20 > The Registration Resource may also be used cancel the registration > using DELETE, and to perform further operations beyond the scope of > this specification. >=20 > These operations are described below. > =20 > Nit: Perhaps reword the second sentence. Otherwise it seems to conflict = with > the last sentence of the prior paragraph. response: This has been resolved (in https://github.com/core-wg/resource-directory/pu= ll/253). > 5.3.1. Registration Update >=20 > The update interface is used by the registering endpoint to refresh > or update its registration with an RD. To use the interface, the > registering endpoint sends a POST request to the registration > resource returned by the initial registration operation. >=20 > An update MAY update the lifetime or the base URI registration > parameters "lt", "base" as in Section 5. Parameters that are not > being changed SHOULD NOT be included in an update. Adding paramet= ers > that have not changed increases the size of the message but does n= ot > have any other implications. Parameters MUST be included as query > parameters in an update operation as in Section 5. >=20 > The "SHOULD NOT" feels a bit strong to me, and I would prefer to see this= as > "MAY NOT". In many cases, if the configuration is not too big then provi= ding > the full configuration makes it easy to guarantee that the receiver has > exactly the correct configuration. I appreciate that there are many cases > where from an endpoint perspective it may want to keep the update small, = but > if I was doing this from a CT, I think that I would rather just resend the > entire configuration, if it is not large. response: This is indeed not a compatibility but a quality-of-implementation recommendation, and was changed to a lower-case 'should not' (in https://github.com/core-wg/resource-directory/pull/304). > 5.3.1. Registration Update >=20 > Req: GET /rd-lookup/res?ep=3Dendpoint1 >=20 > Res: 2.05 Content > Payload: > ;ct=3D41; > rt=3D"temperature-c";if=3D"sensor"; > anchor=3D"coap://local-proxy-old.example.com:5683/", > ; > anchor=3D"coap://local-proxy-old.example.com:5683/sensors/temp= "; > rel=3D"describedby" >=20 > Figure 14: Example lookup before a change to the base address >=20 > Just to check, is it correct that the anchor in the http link is also to > coap://? If this is wrong then there is a second example in the same sec= tion > that also needs to be fixed. response: This is correct. The link's context was originally relative= to the endpoint's base, and while this is being changed from to , the link always points f= rom the resource on the EP to the description hosted on HTTP. --NqNl6FRZtoRUn5bW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+hlN8ACgkQOY0REtOk veFOLA/9Hey3WH10GRyeALi7aw09xU2zy9t4aVNHmWciXCkddzR8fg/Zg+lfcwNf lPwzP4ZvlhV2RRvlpHqj8KBAtQVHlJK3RmPAYye8r6sJIh26mAd4+8EGiwfJDuuB Bn/k7JPuIcFBiakxrYYcXg8UXAj2WAXegnkwVghfT7oNsyplfPDAvFTOm96Bcunz wMbZJgPJl7OvuQvY3jNirbbfbRkD2PmAw/7KBUmh7ImmA2jcNIx2Qg70LFEATny4 9bcumtACVRn4NOLcpYkCDwAtj+LNIvFQTIjj6Kc1IwMXL2kZZ9z9nNAPgAM/sP8b G2c6fTV1Yo6IGpVLfAeABXA1BbUUGm/yUb3lThzEGBE+z7eHyrv15FlLk3RKbGLv MpWq/q4QOkZCCn1MGjxea6iwGdt3R5/kuJASmwOaqWL4W+bCRZDjZ8U/vNC4qu4m 9+3HLaoGs9n/uzaqiZcapytyF5nhBwShZhlkNhYgLJbq85XM0W6bnx62DAqJCzgM Hc//3KFkvhjwVnAZZBj44H+9tlUJiv8BjsTZGNRLO0OMIfFToLBUPKWudMbaqr1a Or0w0JDL0L15c2cSl/YQ181CPwHH2eI/eYnbOq/G4vOSKrdPyqj86sKLq4ybFail sHCq6M2rlxPsqpYW8ey7bUjWUGRO62gzK9wu/B0dCY51WGolOG8= =g/hJ -----END PGP SIGNATURE----- --NqNl6FRZtoRUn5bW-- From nobody Tue Nov 3 09:46:41 2020 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 4716C3A0E6B; Tue, 3 Nov 2020 09:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ezqMVpgOPlGY; Tue, 3 Nov 2020 09:46:37 -0800 (PST) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 840093A0E65; Tue, 3 Nov 2020 09:46:37 -0800 (PST) Received: by mail-il1-x131.google.com with SMTP id z2so16844590ilh.11; Tue, 03 Nov 2020 09:46:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kgvGCHlQOGTFz9m+y5LpVgUqp3U4wKRgDGe6rJdaGdw=; b=CvLalC5rYNoNdNFAjv5Hl0QqmOF+Y114+Q6Ayd5p/+up87h5nSWuXpcZ7qBoopO2XY 7xUsVtw+laRJqPpTYZpg0pCJuPqGbBPr/uYDjSDy+2CBMsNm8jusEGycPN7eUkpvweF1 uvD3psxXBOz23iLDRqg1Wv8ycHbM/mhGj2dJELNDyjVlWRJbE9o477Gn/WT5EKOmko60 mTEtfpPbZYD2RDPPCqRJhkBUbKDtN880omzC+9mDCOWXs2HkeK8VQs8yhtwB3CaDnNx2 KoCE5eDV56X/hYfcCD6SSWxGLMxMKz6I+4JgowbRh4k2gI3fShWdpWHH7peS7tOlIiWV Ds1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kgvGCHlQOGTFz9m+y5LpVgUqp3U4wKRgDGe6rJdaGdw=; b=WffgP8XMJELDmHmTEm2yB9tJ/fQHCiirjKi2n/0Ntr6xv2gX6vEtBQ739p7+Bmnnu5 bz0XtwrzQtz5H5UVc3qY4e5MwGvsd8bBfKlCZvZ6mpK+BN7kNpvKOm2oTIh9ZvBz7fHa GUDT3BCs4joP3+BcyAs9QyqV2pYhbMFcWGJdtkarsoIN+OjhBGdE7JKp5EyZHCziuqCE OGYWdPZY7aCko8u/fTN15zV12GRcBy6AlRb0HefG0EBYm8+CiWJpYvPVkW6wiCnveKm7 e2ZT6jxxVOVIRMxYkwThleoyuzRTrGXrJyBFS7Uj2lHU0gKgL8O0iUr3YszHFeyubg6/ vfNg== X-Gm-Message-State: AOAM531Cqn+fkLkLUTnYbzXY5ttTQ9NlkD6FsFNN2MbKrNne8uSBRewm fV2jrpmRagQV9ECsdA4u+J4FCzYh3LAUdD/I/iRvLUxMN/U= X-Google-Smtp-Source: ABdhPJwla/QOAEn2ZABWOlCZRNOWUNJAEBVjfd4xHGUc7oEHjewUIWbB6BTYkFvUoUhI3aIL2vPQDBnih/nmGJJOQW4= X-Received: by 2002:a05:6e02:926:: with SMTP id o6mr15862232ilt.287.1604425596727; Tue, 03 Nov 2020 09:46:36 -0800 (PST) MIME-Version: 1.0 References: <159729581019.30986.4796757249133933498@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com> <20201103173147.GH45088@hephaistos.amsuess.com> In-Reply-To: <20201103173147.GH45088@hephaistos.amsuess.com> From: Martin Duke Date: Tue, 3 Nov 2020 09:46:25 -0800 Message-ID: To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Cc: The IESG , draft-ietf-core-resource-directory@ietf.org, jaime.jimenez@ericsson.com, core-chairs@ietf.org, core@ietf.org Content-Type: multipart/alternative; boundary="000000000000c2f68805b337718f" Archived-At: Subject: Re: [core] Martin Duke's No Objection on draft-ietf-core-resource-directory-25: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2020 17:46:39 -0000 --000000000000c2f68805b337718f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks! On Tue, Nov 3, 2020 at 9:31 AM Christian Ams=C3=BCss wrote: > (This is one of the point-to-point follow-up mails on the RD -25 > reviews; for the preface, please see the preceding mail on "The various > positions on draft-ietf-core-resource-directory-25" at > >). > > > One nit: the sentence that contains =E2=80=9Ccannot be executed as a ba= se > attribute=E2=80=9D > > appears to have been mangled. > > response: > > The paragraph has been reworded (in > https://github.com/core-wg/resource-directory/pull/274). > --000000000000c2f68805b337718f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks!

On Tue, Nov 3, 2020 at 9:31 AM Christian Ams=C3=BCs= s <christian@amsuess.com>= ; wrote:
(This i= s one of the point-to-point follow-up mails on the RD -25
reviews; for the preface, please see the preceding mail on "The variou= s
positions on draft-ietf-core-resource-directory-25" at
<https://mailarchive.ietf.= org/arch/msg/core/xWLomwwhovkU-CPGNxnvs40BhaM/>).

> One nit: the sentence that contains =E2=80=9Ccannot be executed as a b= ase attribute=E2=80=9D
> appears to have been mangled.

response:

The paragraph has been reworded (in https://gi= thub.com/core-wg/resource-directory/pull/274).
--000000000000c2f68805b337718f-- From nobody Tue Nov 3 10:01:18 2020 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 EFF1D3A0ED9 for ; Tue, 3 Nov 2020 10:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 bXJqqFCVKAak for ; Tue, 3 Nov 2020 10:01:10 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 A474E3A0ED6 for ; Tue, 3 Nov 2020 10:01:10 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id l28so23378739lfp.10 for ; Tue, 03 Nov 2020 10:01:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1EYd9olTvnMT3F1K97Q1o6mLv+OndenAFMVPKyIy0mI=; b=kLIuk1FqKbHZWGX9NLgU6kuAIAOwuxNT/4wHNttC3+ZNGa1CnKcAyhBobwZWwuLBGN ZAl7oxVJo1nSS7S8W5bMy5M2G6aymrZlTR05mRq6ZrWfbGdN4LgIcb2eT22jVTpIwOi0 VBdQJAp62wWMyfib87d94JUH0zoT6tKkr6UGYia7iGkkRbHQgAA+y1CryDJtXUYVjc0/ 2vHRN2sdyASgClnYnnel5TqtHmp5b869A/XKEh7TN8BbtWIcTdbvRa9kOM+1r3njvhbH Hd8l4FAJwjk/M/ax1aHQkcxSp9uKkP6FTIG5YmRVqLVgsK8pDs09pXfUBBwFYjmYLB8t 0usw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1EYd9olTvnMT3F1K97Q1o6mLv+OndenAFMVPKyIy0mI=; b=qVxbfO2j21tLGefjG5CExZ995wu2fDNv2wYK+wngo67y+CCn8YaeKMOvXBdVlpyJ7B rr89KhOGzpxkvSYHq/FsJjh8cs+FeDCk8or3dWVc6QGk0YzoiFmxJ+XIKo+qdZEstZKT ciiW6NoYRseEt7EIxjRLTqrjtxfPgbmN9KyCrH8HT8urRZQubiXARQqMpG0n9M4dfH76 7T29cBsqwnTQ0yMK8KcQJ2VBxsHDn1062gQmthk2jVDfu28zkXUqC3EOCR7inuGeIGO0 blQsrxT/VLivknH0XKKR+Qqds6SiggQTn1IBUkGo/Y7cw6iMuw6VSfHct8Y9TCN4vmHz a9Lw== X-Gm-Message-State: AOAM531RJBJ1dIgWfCIMnk/BzJaA6r7uze5AS/L8Ru3Mu6pmkD5AGy3o JS9JRS1DzSQX4x6DhYVeCxpDhSAEJ3GwU0UFxNzw8Q== X-Google-Smtp-Source: ABdhPJzKItW2zxjyYakopacKOLluLRaphmD+h+F3U8hp/pumihFFThHBIWIre5NQ4dO/9eY4ZROsAoBBZPkw5Bk46gg= X-Received: by 2002:ac2:57d3:: with SMTP id k19mr8863904lfo.386.1604426468470; Tue, 03 Nov 2020 10:01:08 -0800 (PST) MIME-Version: 1.0 References: <159717402717.27772.14957520028083871786@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com> <20201103173405.GJ45088@hephaistos.amsuess.com> In-Reply-To: <20201103173405.GJ45088@hephaistos.amsuess.com> From: Warren Kumari Date: Tue, 3 Nov 2020 13:00:31 -0500 Message-ID: To: =?UTF-8?Q?Christian_Ams=C3=BCss?= Cc: The IESG , draft-ietf-core-resource-directory@ietf.org, jaime.jimenez@ericsson.com, core-chairs@ietf.org, core@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] Warren Kumari's No Objection on draft-ietf-core-resource-directory-25: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 03 Nov 2020 18:01:14 -0000 [ Top post...] Thank you! W On Tue, Nov 3, 2020 at 12:34 PM Christian Ams=C3=BCss wrote: > > (This is one of the point-to-point follow-up mails on the RD -25 > reviews; for the preface, please see the preceding mail on "The various > positions on draft-ietf-core-resource-directory-25" at > = ). > > > As COMMENT: > > > Comments: > > > > 1: "These CTs are thought to act on behalf of endpoints too constrained= , or > > generally unable, to present that information themselves. " > > > > This reads very oddly - "thought to act on" sounds like we've seen some= of > > these in the wild, and only have a vague idea about how they work. Does > > "These CTs act on behalf of endpoints too constrained, or generally una= ble, > > to present that information themselves. " work? > > response: > > Yes that works. (Fixed in > https://github.com/core-wg/resource-directory/pull/301). > > > 2: "From the system design point of view, the ambition is to design > > horizontal solutions that can enable utilization of machines in differ= ent > > applications depending on their current availability and capabilities a= s well > > as application requirements, thus avoiding silo like solutions" - this = is > > very buzzwordy, and I have no idea what it is actually trying to say... > > response: > > What it was trying to say was that parts of the complete system should no= t be > specific to an application. The sentence has been replaced with something= that > is less keyword oriented and more descriptive. > > (See https://github.com/core-wg/resource-directory/pull/302 for precise t= ext). > > > 3: " A (re-)starting device may want to find one or more RDs for disco= very > > purposes." > > > > Either I don't understand what this sentence is trying to say, or "for > > discovery purposes" should be dropped.... > > response: > > The intention here was to express that some host must be found before the > further URI discovery steps can take place. Enhanced in > https://github.com/core-wg/resource-directory/pull/301. > > > 4: "As some of the RD addresses obtained by the methods listed here are= just > > (more or less educated) guesses, endpoints MUST make use of any error > > messages to very strictly rate-limit requests to candidate IP addresses= that > > don't work out. " What happens if device A discovers RD X, and device B > > discovers RD Y? Surely there has to be some sort of deterministic metho= d so > > that one doesn't end up in a "split brain" type outcome? > > response: > > There are various approaches that can apply depending on the actual appli= cation: > > * In managed networks, care can be taken to not make multiple RDs discove= rable. > * In larger setups, multiple RDs may be available but set up for federati= on as > it is being explored in draft-amsuess-core-rd-replication > * RDs that are deployed without overarching coordination can opt for the > Opportunistic Resource Directory approach that is being explored in > draft-amsuess-core-resource-directory-extensions, where one RD yields t= o the > other. The error handling steps in RD make that transition smooth. > > But long story short, this draft does not attempt to solve them. > > > Nits: > > > > 1: " The input to an RD is composed of links and the output is composed= of > > links constructed from the information stored in the RD." While true, = this > > sentence doesn't actually communicate anything useful to the reader -- = I'd > > suggest removing it from the Abstract (note that this is just a nit). > > response: > > There has been repeated confusion about what an RD stores, with people > understanding it to store resources. This sentence serves to visibly emph= asise > that only links go in and out. > > > 2: "The RD is primarily a tool to make discovery operations more effici= ent > > than querying /.well-known/core on all connected devices, or across > > boundaries that would be limiting those operations." > > > > s/would be limiting those/that would limit those/ > > response: > > Fixed in https://github.com/core-wg/resource-directory/pull/253. --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Nov 4 05:27:39 2020 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 E60CC3A1223 for ; Wed, 4 Nov 2020 05:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.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 yQhUW-oyxZc6 for ; Wed, 4 Nov 2020 05:27:36 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70070.outbound.protection.outlook.com [40.107.7.70]) (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 BBE043A03F4 for ; Wed, 4 Nov 2020 05:27:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CJuvYPe1D6EPprTo/4s45FVyoZNzQxb+YwFRUx7Q+PapHJuvKyHEfyMBtqmyZNxkGL6SrdDwMWqHjwuFw1b4Z3iNereAi3Qy8oBcARSJARdk8cOlNgheu9V+yQJAcVGY0R8pQUi2oI+UMd2zWSDckQNX2M2cJyvFwglvaBf/qg8Y1RMpegXBLX4j/RReobdVOi2i8k1OT8wUfUhGYtdmbNqy4T7K0JvFBu78GDt0J5AqlG4waHJ4uEkgZ2HRciO9l3su8xmEcOqHuck7qeNKuUmZSSO47SZgdU3oxM/I7RdCvsxcP2KpZvPbiTaaK8gjA+Ha8tXWnb9bjjG3ToIXMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3FZ9KlBTcX5rdpv1RTLt/5Bp8P4Rw5MhgPHtBBPTpfg=; b=oawNFNjA7TdyJtLBzU+nri+YlpVG51ZxvgjLvBvwu081R3KVR591tq4b23PJSkDLdIybNSQ8XfVJuyVl83ZTRTD/lRZ3BphX0HflcTsxW/OXAmYlF1NqIUEjuo3X69kguaDvyRaKvEBNTzWh4eKxAyXNbos/8ozhvecuc6ktGg0FtMVM3xo3T7XuJVT01vm5r4lLwvWwuAoD2uocxv4QQ1g/JVk04WUIXM32U9zLirZoEVzzeTPfnyL0UvUDM20k9BXElT4KPpavZaQLRaIH8Rbm4hqJEWuBBw1FzCATv3lTa6Jh4i2yxlXtAsOsomxtETDoW3V5n0VfE0LX1r/phQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3FZ9KlBTcX5rdpv1RTLt/5Bp8P4Rw5MhgPHtBBPTpfg=; b=iBGRDmBxBFK7Y5cr9EwqLCg6qDSzJgwfm7shCK+xqoH5kj4RTaFaRKQ4BKRdxVY8xfOHsRqn4h2fp+noFAkCbqxJrd/58eQnd3p8AAN9G9zKXLH1PseWkGkfyGjhK5A6kp1aLcYndIPJn0NXaTeqICI0IXrxFBeJhjzAi1mpcyQ= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DBBP189MB1321.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:1f3::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.29; Wed, 4 Nov 2020 13:27:31 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd%8]) with mapi id 15.20.3499.032; Wed, 4 Nov 2020 13:27:31 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: Date: Wed, 4 Nov 2020 14:27:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="A7Pxl465lfb6JePUyw83HEEWYuLocMu31" X-Originating-IP: [185.236.42.99] X-ClientProxiedBy: HE1PR0802CA0024.eurprd08.prod.outlook.com (2603:10a6:3:bd::34) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.1.8] (185.236.42.99) by HE1PR0802CA0024.eurprd08.prod.outlook.com (2603:10a6:3:bd::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18 via Frontend Transport; Wed, 4 Nov 2020 13:27:31 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 804f8626-e453-4349-0dd0-08d880c561f9 X-MS-TrafficTypeDiagnostic: DBBP189MB1321: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: XIGAUjEPCcIrIRerjRHQUsBgjGfs3TeXwvf/WvIi9ZbgaKsKR2LZNvKTXqrxiRb9hkrMr40NxYTYqw+TuKtkiGdEKYC6KIRvWS/IJSVjDgb9JLwgSSdiKvEvxq2YEqF/LImnOV1y5CoBgjkopnBVxrHeKnvrl6+eib3s3pKoaaSpIAZm367AtFmVm1OFrtqgggre+xGpZ6W+HDXU6axOGyh2wmo4xP29W6gKy0NPNW6oQyJkKBc9IblyoiaqvrkS5qfaJqm4PP+l3orgrwjMdo03K0jdlvoKYnhuyXQsx92c68y2KdfyAxpHuD8HvwHphXmssMqWHCe2eqUT/1my+HdKZcA0zyjmFlyBzuGo1bnI8hIqlnhHg9MBcZgi/rRCP6m4YL4pJHvFglXlTYR6zOV5LwUDzoWF5uV1BBisJcrwqK3u9hnjomvX1LnLPz69tdPSBgu7B+r4TuMDPgmA7A== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(136003)(346002)(396003)(39860400002)(2906002)(966005)(6916009)(6486002)(6666004)(21480400003)(31696002)(478600001)(33964004)(316002)(235185007)(5660300002)(16799955002)(26005)(956004)(86362001)(52116002)(16526019)(83380400001)(2616005)(66946007)(36756003)(44832011)(8676002)(66556008)(66476007)(8936002)(16576012)(66574015)(186003)(31686004)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: z7VsgpRyTs4VQdumiddqSoB83XWr8EYvHwnmE8UC/KdIffRkJBELntpe6yrOJjSwH3NbnMjEYlGTzPl2r14GrajaitRpWDabUhEQWBZyPJgn/t+9shlOF4nDBKcPax7n2+dZgGl75fabuVpsvVd397Citqg4DXLXnaJODIOd26grFRphSqRssbGI/hltyq+biK2F/sP7rNOJsGnn/WhGguESxCX3Ol5zcmEca4dDJrthCd2+Fex632nfpr7D0y/OIfS8gr+Tuf289X0dE3W0PluUEI+CHGDHgrNzKqupEsBUDJ9Y+wEePa+35GGUQdf8LebcVTZoPbtv40dtUkfuOimrXU35+I7TZfTrm7Dt627taj7jacqeYVTPtgBEDEEY930pFxocu6pWXUyUcWQnxlvH/DtKmFgn6ggWjZ+ZejSvWrxanHpm++sequdzK+FuU73+OGPUY5lCVduglkB/xJv1+/xZnGzxLdKRjXIopTomP+giK1A3w3Q5IyO1VPNuhGmkhsnUZhEMewJpRZmUW71tovEJfIHWKczmndeE8riShrWpwONSqMb2y1dhPGbVDW/lDOdp0LxY2ZT2N3GG3FWXlc+qKu1sJpKnUFmgrNyS6UmVmiQe2ebjcG6vpwTn5lzaCM1cQRTMLP0HTC2bpg== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 804f8626-e453-4349-0dd0-08d880c561f9 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Nov 2020 13:27:31.7721 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: bXqdR6DByEsUMgViRNVX/j3Nh4/EXPxcgizhrqr2oEQssL7iX/3JjLMsSieie+1uGjylBAAorMZRv0rt3Oz+wQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBP189MB1321 Archived-At: Subject: [core] CoRE WG Virtual Interim 2020-11-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2020 13:27:39 -0000 --A7Pxl465lfb6JePUyw83HEEWYuLocMu31 Content-Type: multipart/mixed; boundary="uIBSeu8lSKO6eZ1P8V58QLs7tXraNnATO" --uIBSeu8lSKO6eZ1P8V58QLs7tXraNnATO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a reminder that tomorrow (Thursday) at 15:00 UTC we'll have a virtual interim via Webex. Note the UTC time --- now meaning 16:00 CET --- which for most participants should be the same local time of previous interim meetings in the series. The agenda is to check and discuss: - Remaining open points for the Stateless document. --- https://tools.ietf.org/html/draft-ietf-core-stateless-07 - Open points and way forward for the Cachable OSCORE document. --- https://tools.ietf.org/html/draft-amsuess-core-cachable-oscore-00 Please, find below the information to join the meeting. Best, Marco and Jaime =3D=3D=3D Meeting Information =3D=3D=3D Jabber: core@jabber.ietf.org Etherpad: https://codimd.ietf.org/notes-ietf-interim-2020-core-12-core?bo= th Meeting link: https://ietf.webex.com/ietf/j.php?MTID=3Dm42a6113960b3434a699fc514e176a5a= 5 Meeting number: 171 140 9229 Password: constrained More ways to join Join by video system Dial 1711409229@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join by phone 1-650-479-3208 Call-in number (US/Canada) Access code: 171 140 9229 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --uIBSeu8lSKO6eZ1P8V58QLs7tXraNnATO-- --A7Pxl465lfb6JePUyw83HEEWYuLocMu31 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl+irEEACgkQ7iZktA5Y 2kNYAggArcP/hScACsdRTo9oab3j0/cPmZMnVtdwlnEYBn+7yO8OXhOFfjDxO4WJ auKuIYj5bBS9LA9GH6lXSt8nRqcOpVm4ylRyPZ0eyis6nXjBjLClbCcN+2FdCjQT rOwi/d+nJzSDXD7mW2wJr5ZS7g/0UrQAowOUqWDmnYsFmrNi46zbz/D7ssB/3Slt EqKmtO3cypF8ohRfRS/uwjw/NyEWRRnP/jJL9Hj5tJe7KV3pighJBmyIWEUXVFZ9 UX7gHbrbzaTV2ltS/wLsFaEnv2slz1V/D6lWyVxtX1Bc8/hiprej4F7K35hKwgBM X48mEqAOgsBnDDpK8ioWDLu0PoUTxw== =46td -----END PGP SIGNATURE----- --A7Pxl465lfb6JePUyw83HEEWYuLocMu31-- From nobody Wed Nov 4 09:40:41 2020 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 9078E3A0DE2 for ; Wed, 4 Nov 2020 09:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.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 BLNYRdzULdtm for ; Wed, 4 Nov 2020 09:40:36 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2060.outbound.protection.outlook.com [40.107.20.60]) (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 9DE1D3A0DE1 for ; Wed, 4 Nov 2020 09:40:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IzqocovnAoLByh8ixawammp7BsRUTL7RQ1lUcfrSTvDxhpyMStF4A51Vpw/H1qOoh2jrYx/TosuMma7Kzm4j2xXM+7EduFQgCSbrra/ghnGsjOvEh8GEdmT3/LOsVEsWIMN7D+XVwmuoTBa549zpp4J8/O77JWP1jz3njaBpwBQBUJlECl9M5V56tN8gOTde2Ngtin4b5/JXUT5AVYar3BV56wPUB2wrLENd74RS1593P6DllIhWkFXINHGhguGArJm1RcIyaKIJhTmIPQmbosyfYGh6CrlOSUrvVjkVMTVarZU1JSlUqEtVi/176chpARFp3gs/A96kKKSCN21jZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UuSnp7D2arn/Ch3n8u6lGXL78yJz2t9Ffp9RAmJ3L0Q=; b=XG03FzTgOrHphODLjW4Pa55I+6s9A90R6OFRbE3f2wNAIzeE/E15AtOfI7nD79vbCd4S/sNVYst/925tPlTKvb+H/uJF+AOkXqF5EIJeM/mSgK4fU05gEYahw3H1Wt8iExkHF7saubLMWLqTJ+h52NuNpjgYEQElLUohIJQu7lYXczbCH/Eve5JsJ+vSK3s0XtnXLvAUCfzxlPIxpRAna4zN/SszmGHX3ikIPVGgWdI3wI7LokKC2l8nBLT05e3JRGzFv35FrgHfZCJWp8L5Trv8PIZJ8IF1h/6HJ9eg2vG924PDKjPtVAmM1YmaJN7J9xcYrStX5zQfg5OOqxZljQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UuSnp7D2arn/Ch3n8u6lGXL78yJz2t9Ffp9RAmJ3L0Q=; b=bAH9UGUhYi8nmjkOwEMbktLIfk60+dtDnqZraO+VPTgyxF57930glCGX4NZvrM7Vc3UWlxmLx3ZRxvU0eotQZTZcTsVdxXUBKyxcmVeAm5rw7bdM/A3aBbxZnBUe7LWajCYNbRTQYvexWor4eQibep24aa26wBsAA6JpVHpL6Wg= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P18901MB0199.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:27::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.19; Wed, 4 Nov 2020 17:40:33 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd%8]) with mapi id 15.20.3499.032; Wed, 4 Nov 2020 17:40:33 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <12eb3c53-43ef-8a07-39fd-c62efcd35dbf@ri.se> Date: Wed, 4 Nov 2020 18:40:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iV2p4aJyvHAWx64H1C9XwaG2zK7bw8FYp" X-Originating-IP: [185.236.42.17] X-ClientProxiedBy: HE1PR0401CA0106.eurprd04.prod.outlook.com (2603:10a6:7:54::35) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.2] (185.236.42.17) by HE1PR0401CA0106.eurprd04.prod.outlook.com (2603:10a6:7:54::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.27 via Frontend Transport; Wed, 4 Nov 2020 17:40:33 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ea9c417b-b817-4c64-03ef-08d880e8bb6b X-MS-TrafficTypeDiagnostic: DB6P18901MB0199: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ySRLTYmPFTtUT1Ijpc4Dj3cvq4JFZv7VJwRs008QitSrfPs8sITzbKPU/8xpj+lC0blKU++LwNElqjmt1uNq1Seznrp8UH8Typ70j3AzRPkoF2Q96ckMlhzZ8u9wL8tRxtEQ9aV2Jw5yig3gnY0W+xpW9LTpitUCQutJjSQ3cHebVsw3HhnO8mhDDOT8BWgaMvxkV+03TqjEckay+yRO3eqtvnBNTQfNVD6q1rddCNASZmuP/SV7Nwdus5BhgUS36ctcu54tlTW1mF/8i9MjhjSrvKoNH285XQxoFFbc44iIjnclRx254+xC3l4QsfDFG8mvyYXdwpAMAGRGuky8LjhT+hT381MXgfJZi7qwF0MC+L0Z/1WQr2OdOS9EvH+d3Bv2WVSZ6oaEfFdHbZ6Y6PrHB5V3BLpgfwWUpecu4RG1w0Dh5iHrBVxYMWtCU8AUgOZCQrQft7b+2IUyrHehpQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(136003)(39860400002)(376002)(366004)(44832011)(26005)(235185007)(186003)(66946007)(66476007)(6486002)(966005)(16526019)(66556008)(31686004)(21480400003)(31696002)(36756003)(478600001)(8676002)(5660300002)(6666004)(83380400001)(2906002)(8936002)(2616005)(6916009)(86362001)(956004)(316002)(66574015)(33964004)(52116002)(16576012)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: rBL7ztfRfXjGeWEOU366N7cJIh+IV8LA9sg1pYR6C8nivuH5+hAxTleXMNObEkciPQZUoG2935gK0fenNLbIi89WR8+hzxrOYyM0q6YEmN4PjSfponZFzan8eC8w/plGeArL4gwQ9RWjr+n/f5RhlHGkGGy5GF5hhExP5Hj4YkDT+pZVY4e9jeABAnVxj0jxUZRI0LJabCoJCAa6vrls59hVuS5z5lPIljgu80j7EaThoHWvHwQHDGIEuOhqeizE9CleEeR95XTKL1Qq6pbiDC8I1kww4gUrRMBu5Rlm5QAU4GeI4cePZyGc9lCSVJSiJDYKUiIi+HAVZyzpNkFSO59xsY5eQYn7VUGwjeEEkLt/q11sM2GqCsA33uo7toFNGCOFFdHsa6N8eDRZ/+DVWLRlOXaJ8IP6QYEPadttYuK8Dks/hJjU2A4QZQcoxD2rmVcX3imuoa1ujXmRgi0xgj/ZZPIplGbzmIw+kB6PNz5KZmrQOwy39cL7DSPtwo8LJ5gdy+DW30t2SEmwvxC6e666BxmgoziPns5x7JDcS5blJYpbz9CxcgW+z4DJY5/LxRmuq8YJgN5y1FRg68rZ5WEuICEfwNEJn6rSuBOGcEx1KFodhyTo+hsV4eW0/oDwh7HvBVeG7m1wDd/vtAeLgA== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: ea9c417b-b817-4c64-03ef-08d880e8bb6b X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Nov 2020 17:40:33.9270 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ZUczAoM+2cdcnj1e+TNq8kVslsDTCmGv+COEVS18z5qIDbtrAUQ0XA5nh8Vlm9zrTb6mFJrtYphYgYLuEpIhzQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0199 Archived-At: Subject: [core] CoRE Agenda for IETF 109 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2020 17:40:40 -0000 --iV2p4aJyvHAWx64H1C9XwaG2zK7bw8FYp Content-Type: multipart/mixed; boundary="v2GvHZ1HtojiDCRrr2tQDuR7FNnIYURlW" --v2GvHZ1HtojiDCRrr2tQDuR7FNnIYURlW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, A drafted agenda based on what has been submitted and on recently ongoing activities is available at: [Day1] https://datatracker.ietf.org/doc/agenda-109-core-sessb/ [Day2] https://datatracker.ietf.org/doc/agenda-109-core-sessa/ Those who want to run slots, please: =E2=80=94 check the objectives we have guessed, or provide alternative on= es =E2=80=94 check that the estimated time for the slot is ok =E2=80=94 confirm who should run which slot, or provide an alternative =E2=80=94 send a mail with this information to core-chairs@ietf.org Please, come back to us also if you think there should be a slot on a topic/document which is not included. Best, Marco and Jaime --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --v2GvHZ1HtojiDCRrr2tQDuR7FNnIYURlW-- --iV2p4aJyvHAWx64H1C9XwaG2zK7bw8FYp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl+i54oACgkQ7iZktA5Y 2kNPWQgAgoB/IkGbflFvUpvgIEzz4fpEhxPAUbnAlG2QjZg8VY8QWeQwJ769b0G3 OmFjGJaO0LoywOdEItIiopGwKNRq1vFgkQiH+3zsjep8WcX2wnvP+MboEGg/7rbl P4ROf4hwXU91ejqoRJgv4+5iN6FufgmsLnyXscw5tUgHlgIkoJTAu7ENZgRZ92bM k2M3prjltdts/U3oW/FQnXhzIkOUlh4SrS298LG/xaQD1HpK47DHS+5krmPtaTXP khmlaCrqqvw9xXe8boFyvx3YPLUYQbGlcfzkeV1YmleOlSWVG+vEohHWZWTSH5og 3Von0EPtTsh1MboRMTJSNINLEg5A+Q== =2YBu -----END PGP SIGNATURE----- --iV2p4aJyvHAWx64H1C9XwaG2zK7bw8FYp-- From nobody Thu Nov 5 08:16:33 2020 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 8AED93A1355; Thu, 5 Nov 2020 08:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fA-epRYf-7wm; Thu, 5 Nov 2020 08:16:25 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536863A1141; Thu, 5 Nov 2020 08:16:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id AE1BF38C7D; Thu, 5 Nov 2020 11:16:26 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZnlUryPyvjy6; Thu, 5 Nov 2020 11:16:25 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A4F3938C7B; Thu, 5 Nov 2020 11:16:25 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5C796609; Thu, 5 Nov 2020 11:16:18 -0500 (EST) To: Benjamin Kaduk , The IESG Cc: draft-ietf-core-stateless@ietf.org, core-chairs@ietf.org, core@ietf.org, Carsten Bormann References: <158741679923.20291.1071401061463555301@ietfa.amsl.com> From: Michael Richardson Message-ID: <0c186080-6ac1-2a9d-1e0a-7cf3b3667d52@sandelman.ca> Date: Thu, 5 Nov 2020 11:16:18 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <158741679923.20291.1071401061463555301@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-stateless-06: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 05 Nov 2020 16:16:28 -0000 The ID submission system is closed, but we have a -08 ready. You can view the diff against -06 at: https://ietf.org/rfcdiff?url1=draft-ietf-core-stateless-06.txt&url2=https://raw.githubusercontent.com/core-wg/stateless/master/draft-ietf-core-stateless-08.txt If you'd like to approve updating this document, the XML is at: https://raw.githubusercontent.com/core-wg/stateless/master/draft-ietf-core-stateless-08.xml The document is ready. On 2020-04-20 5:06 p.m., Benjamin Kaduk via Datatracker wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Let's discuss whether the various and sundry conditional SHOULDs in Section > 3.1 are better written as conditional MUSTs (i.e., with the listed > exclusions being the only allowed exclusion). Hi, we have left them as SHOULD. AFAIK, a SHOULD is a conditional MUST, and I agree that exclusions need to be listed. The security considerations say: It maybe that in some very specific case, as a result of a careful and detailed analysis of any potential attacks, that there may be cases where such cryptographic protections do not add value. The authors of this document have not found such a use case as yet, but this is a local decision. There are no interoperability requirements around what the token format is. I don't feel strongly one way or another but it seems like the text is already pretty clear. > Also, Appendix A.2 seems to show "Len (extended)" as just 0-2 bytes when > IIUC it is 0-4 bytes. This was fixed in the diagram. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 2.1 > > The new definition of the TKL field increases the maximum token > length that can be represented in a message to 65804 bytes. However, > the maximum token length that sender and recipient implementations > support may be shorter. For example, a constrained node of Class 1 > [RFC7228] might support extended token lengths only up to 32 bytes. > > Is there anything to say about IP MTU here? Not really. Obviously, if you can't fit the bigger token into the packet, then you can't use it. > This is a fairly subtle way of saying that core RFC 7252 > procedures/semantics are being updated; I'd suggest calling out (alongside > the other updates) the new(?) requirement for distinguishing whether an > extension is unrecognized vs. an invalid value by producing reset vs. a > distinguished error code. (I do see that the semantics for 5.03 and 4.00 > are not changing, but the use of Reset vs. error code for feature > negotiation seems important for implementors to be aware of.) This was opened as https://github.com/core-wg/stateless/issues/3 The document already Updates RFC7252. comments on Section 3.1/3.2 already applied > Section 4 > > Perhaps it's worth noting that this nesting of state will necessarily > increase the token size as it progresses along a chain of intermediaries? > > There's also some considerations relating to how the freshness window of the > client an intermediary interact, with the client effectively being limited > to the minimum of all windows in use by client and intermediate(s) on the > path. > > If the intermediary has a very long freshness window it could be tricked > into sending "replies" to addresses that it thinks are clients but may not > be any more, e.g., allowing a DoS attack to traverse a NAT or firewall. Opened as https://github.com/core-wg/stateless/issues/4 closed as wontfix after some discussion in the issue and on the list > Section 4.3 > > RFC 7252 doesn't really suggest that there's a protocol element that would > be set to "infinite" here; perhaps we should just say that "in this case, > the gateway cannot return such a response and as such cannot implement such > a timeout". Text updated as suggested. > Section 5 > > With no integrity protection on the rejection of trial-and-error (section > 2.2.2) it's susceptible to downgrade, IIUC even by an off-path attacker. > (I did not think too hard about whether OSCORE could protect the Resets in > question or not, though.) It seems like such forced downgrade would have > second-order effects in causing clients to use more local state and thus be > more readily susceptible to other DoS vecros. > > Also, when integrity protection is not in use, the client is susceptible to > spoofed responses that had no corresponding request -- only a very limited > subset of request/response pairs are safe to convert to "unauthenticated > server push", as that would effectivley do, and we should probably mention > that explicitly. > > I'd also suggest noting that a self-encrypted state token bears significant > resemblance to a TLS self-encrypted session ticket, and reference the RFC > 5077 security considerations. (Yes, I know that RFC 8446 Obsoletes RFC > 5077; it would be an informational reference only.) > > This could also lead to some discussion about having in general an > appropriate amount of sanity checks on the returned token that may or may > not reflect serialized state, to limit the scope of various attacks even in > the absence of cryptographic protections. open as issue: https://github.com/core-wg/stateless/issues/5 Text updated as per: https://github.com/core-wg/stateless/commit/83535c69958467099cd20ca49d9bbb8e8cc03068 and https://github.com/core-wg/stateless/commit/83535c69958467099cd20ca49d9bbb8e8cc03068 > Section 5.1 > > size that need to be mitigated. A node in the server role supporting > extended token lengths may be vulnerable to a denial-of-service when > an attacker (either on-path or a malicious client) sends large tokens > to fill up the memory of the node. Implementations need to be > prepared to handle such messages. > > This seems particularly problematic given that we disallow sending Reset in > response to too-large tokens and instead imply that it should echo the large > token in a 4.00 response. I guess technically this is a SHOULD and not a > MUST, so there is some leeway to do something else, but what would that > "something else" be in this case? It seems like we have a hard requirement > to do something sane with a token as large as 65804 bytes. opened as https://github.com/core-wg/stateless/issues/6 Discussion is that in order to receive such a large token, you have to receive it. If you can receive such a large packet, then you can answer it. As the token is never stored, there is no exhaustion attack possible. closed as wontfix > Section 5.2 > > The use of encryption, integrity protection, and replay protection of > serialized state is recommended, unless a careful analysis of any > potential attacks to security and privacy is performed. [...] > > I suggest an alternative wording: > > % It is generally expected that the use of encryption, integrity protection, > % and replay protection for serialized state is appropriate. However, a > % careful analysis of any potential attacks to the security and privacy > % properties of the system might reveal that there are cases where such > % cryptographic protections do not add value in a specific case. Text used as part of rewrite. > > a 64 bit tag is recommended, combined with a sequence number and a > replay window. Where encryption is not needed, HMAC-SHA-256, > combined with a sequence number and a replay window, may be used. > > Can we give guidance on sizing the replay window? > Should the HMAC-SHA-256 output be truncated akin to the truncated CCM tag? > In what cases would one want to use an absolute timestamp instead of/in > addition to a sequence-based replay window? issue opened as: https://github.com/core-wg/stateless/issues/7 Replay recommendation/analysis is at: https://github.com/core-wg/stateless/commit/b019c61e2b44757a4427956af95e99fbec15180e updated by: https://github.com/core-wg/stateless/commit/a7157fea61c3948899ded7311b5b0920cbd1b1c2 and then today by: https://github.com/core-wg/stateless/pull/15 > guarantees are voided. Devices with low-entropy sources -- as is > typical with constrained devices, which incidentally happen to be a > natural candidate for the stateless mechanism described in this > > nit: "low-entropy sources" is a weird phrasing; "low-quality entropy > sources" would feel more natural to me. > Also, draft-irtf-cfrg-randomness-improvements may be of interest to at least > some such devices. suggested text adopted. > > provides the above uniqueness guarantee. Additionally, since it can > be difficult to use AES-CCM securely when using statically configured > keys, implementations should use automated key management [RFC4107]. > > This is BCP 107, so I think we could use stronger language than "should > use". Also we should cite it as the BCP. open as https://github.com/core-wg/stateless/issues/8 We removed the reference to RFC4107. There is no reason to cite RFC4107, there is no key agreement needed. The key is entirely a local manner, and a few pull requests referenced in this ticket rewrite that text. > Section 6.1 > > Should the table formatting be consistent between here and Section 2.2.1? The tables look similar now. From nobody Fri Nov 6 00:12:01 2020 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 8049D3A0E84 for ; Fri, 6 Nov 2020 00:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.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 bdhmoTTfQRN6 for ; Fri, 6 Nov 2020 00:11:56 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10076.outbound.protection.outlook.com [40.107.1.76]) (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 B08343A0E82 for ; Fri, 6 Nov 2020 00:11:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aStFFrXK0TDgOb2hOJSNZx0t+HdYVUZOLEr4j3INnJcKnQWxgG4eUcdhEJtxoZCf+z3mV2QQyzr5SVEUw9W+uG5Zduk6gm4tpGlYbXW0NznTMrpnJuMC8IAZy35vtH5PBCBvc1/rNFP2GY7XoYzmLLcnrX8u2KTCYVTonHBC/LnEaJg2lEoZsOWHiFmPgbyfhS+j1JLP8BktMF2M3YqRP/bgS3uxEFnG7p6w+T06g8SjE7KCIci7pvt0FUO9TGm6x1Siz92nNJdgjNNwzjmMuQBVUdx/3+qhCcFL8wMkSySu9Ciyg4+v71r8S+pBdupVY0ceZUzAqHFFA9RE95cjpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QTiKXOLLqN0pgYRMMMFWTRvD4cxLfbImEGDqkvC5M3U=; b=ZdZ9mXhkWDNDKxPouau28E9opwnswD7kTY0Xn98utwNmgOWkw9JrAHRr8hkIPj5ThB1Ve4H3cYNAEZy9IfG/8lUfoylbgUudAobO20CEXUZ6m/3SIhrZYcg23o0nngkmPb18UbJBgGhu5HVTTK31p9BxjqJMYqi8/Ndrm7QwYabToYQH3xY4xMK5HRi5UyRA2sQdfzTwJGguOK0GNYYvBX4r/vbNDW8EyZ55gimdRaKiN40w1aQvdEtftmTTC4ElCnpQW23uoBCLDL+gP6w+EAEShU88+O/gwm989YtGlAPAQ5911eWPJBuw4oOCSVGZYKR07I6tO71cbdNU74H7kw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QTiKXOLLqN0pgYRMMMFWTRvD4cxLfbImEGDqkvC5M3U=; b=HohhBCf8KERme56BNgkRqXB97G7AYkDo2enKDkMvymrXdYxsqd91Gioutifc7EbEHlrv7TdltY75CNJFVAgmsh61X5NUNUXMAg+EW6CfxK9lf0K4wEfqIGOkDs0ZGfsyfyKonhK9y50+WHxTbCaC2tesdCarQ84poOZyPaUeN+s= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB1047.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:14b::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Fri, 6 Nov 2020 08:11:51 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd%9]) with mapi id 15.20.3541.022; Fri, 6 Nov 2020 08:11:51 +0000 References: <160433936958.7373.304916730547208520@ietfa.amsl.com> To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== X-Forwarded-Message-Id: <160433936958.7373.304916730547208520@ietfa.amsl.com> Message-ID: <58182f8c-eee7-b7e7-ff9b-e594cefbd1a8@ri.se> Date: Fri, 6 Nov 2020 09:11:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <160433936958.7373.304916730547208520@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8VIaFSqqGdEbRh9j3B9K5HcAUDAgAXUfR" X-Originating-IP: [45.12.220.244] X-ClientProxiedBy: HE1PR1001CA0018.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:3:f7::28) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.1.4] (45.12.220.244) by HE1PR1001CA0018.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:3:f7::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21 via Frontend Transport; Fri, 6 Nov 2020 08:11:50 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a17eebba-ac6d-4899-5a29-08d8822b9d8a X-MS-TrafficTypeDiagnostic: DB8P189MB1047: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: GXyqX+IY+GFF9Zl64R/nwbv2UL7xN5a4hz/WTf9kq+keGP4TdJcPnqQ1IjcyrEvrIs2gZ8OQkAuiW+cHDwLvkhmDyzBryWUaq+VrVvlhC1CCLZc1JY/Gep4rB6fDN5Zex9C1ubwEYEZV/zEUgO21r4Ts2ddolihEi6wAlpMGaPLS+ERvx2PTPRs/UUva6qSVIRp3lzc8+Y5Spu7mesjNewZYpX9J7j6WfqrFRihJwj0yRKvMDIUQKPGUMSKrX3ofVHPZn0YOYSmAWu23fEdE6DwtVfq2Gt7bbPz4L2dkUA+69+XA0vDzBBBaLIOPofmXo92ukf2mWJQArZniv5rf54U3Beh7s5slhBwmoCXPnXfUMLNNzm3bXmtj6cEn8pScs/QGgUR7VfQuD13sofTHMY8KKoyBCr+jKUQ2aVgcRgy9rlmxLOs9NJbKehqNejpAgIwGjysf9dL1Zty6GHPckw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(39850400004)(136003)(396003)(346002)(376002)(16576012)(44832011)(6916009)(966005)(45080400002)(316002)(86362001)(8676002)(2616005)(956004)(52116002)(478600001)(33964004)(31696002)(26005)(83380400001)(21480400003)(8936002)(66946007)(66556008)(66476007)(166002)(15650500001)(66574015)(6486002)(186003)(36756003)(5660300002)(235185007)(2906002)(16526019)(31686004)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: w4dYTv8Av3PBXwEbPyfc4fSTINmJMLtUjlAZgmLcE8IUYARqTdmjLuQ/J85j7Fl6sQvf0scLbIlSzlqNe1JmKTSrKVFdmRj7cVjl0OhKtqtBiQs5prYTGL/IcHxsjoBJKF9f9JBlmC9+GBJyrh5RTbkAOzRxoY7GrIDLH79dPhEG0FW+37wfEkFDppIiQhF0mQzLFVXm/TepmJcgbnHjQwHpGrq2l5fYuXJNic46MMLuUcaHxm2K4CNu5Xq5bh5/8n3y1MQPSiXa7r1q9xta3a9z7KrwmtaSti3rBc24OuTFGf1Ls/dJ6Xj5ZHxiuJW+uEtxZkdtKW2aJVGW5Putz13IDzPSSkjYGgmS+FYJnR5cW+kPpt8mpK92ecH8CTNxkJnTbfCHV99Re9INvrnLJBINdj+/+SDp4EH/eI/HSNqC/BnXvJ4BrrVoByzCEHC5DXZmmlzUhFL0FLU0m2Aj75W0NeAh3doIKrWNgTEhsUlT9Hqy9h5RtJhRb6vrJQtFJhVAHCEKwBa2wAWraQUwd5Ri6YnbwWjaCbEF+44W6AJQv4RkLOAsJGSFV+B+eeMypKuzgmzVUOXDIHrQW/RtjY//QPjZvlHHELIiNdIE8rRk3U5t0RTCpQ+TtUQXr+AYkUlTmJPAuBiYlxjxH34u2QwnuVkCUzXby0nPN1fHb5FEkoORuXCtCaXYu3yblJ0P9U1rd3GUrpyxjLKkt96iKpyIQomZmGQZBESjXtd+Hc+qLkY/WzfscNCAXwhWxMKiQUc/6THsmR4srAb4mUgTRJKcpAv7MGuvcDmVOYvqdv4ZhB1/6giQbYS16Px8tQb3XcPZ+vbpOFJXExk1Q9miZ60jmMQueymDDYjedo0vn/ccQBOFbVeF2ZXhZDSGmUMsCpTKaPqRIbNv8FJ2Tjns5g== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: a17eebba-ac6d-4899-5a29-08d8822b9d8a X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Nov 2020 08:11:51.3848 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: EU577dpzD7gF3efoRLanu9lTXapch6ZXHrY1GAX2SPIzjYLDRJSLXNXQq/mY63M1LaBn8yOBFCUlcN3xCPn3kw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB1047 Archived-At: Subject: [core] Fwd: New Version Notification for draft-tiloca-core-groupcomm-proxy-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 06 Nov 2020 08:12:00 -0000 --8VIaFSqqGdEbRh9j3B9K5HcAUDAgAXUfR Content-Type: multipart/mixed; boundary="oILxo7nxFszkrgZ87CetB4BK6HDY8pV1U" --oILxo7nxFszkrgZ87CetB4BK6HDY8pV1U Content-Type: multipart/alternative; boundary="------------55F9F3D2093C46BD2A737040" Content-Language: en-US This is a multi-part message in MIME format. --------------55F9F3D2093C46BD2A737040 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello CoRE, We have recently submitted an update for the draft "Proxy Operations for CoAP Group Communication". https://tools.ietf.org/html/draft-tiloca-core-groupcomm-proxy-02 The document details the operations of forward-proxies supporting CoAP group communication and addresses the issues identified in [1]. In particular, a client can send a unicast CoAP group request to the proxy including a new Option to indicate to the proxy the time period to collect responses. Also a new Option is included in the servers' responses, to enable the client to distinguish the multiple responses it receives via the proxy, as well as the different servers originating them= =2E This update is especially about: 1) Improved usage and encoding of the two new CoAP options. 2) Support for Observation discussed as dedicated sub-sections. 3) Support for a chain of proxies between the client and the origin serve= rs. 4) Updated security considerations. Comments are very welcome! Best, /Marco [1] https://tools.ietf.org/html/draft-ietf-core-groupcomm-bis-02#section-2.3.= 3 -------- Forwarded Message -------- Subject: New Version Notification for draft-tiloca-core-groupcomm-proxy-02.txt Date: Mon, 02 Nov 2020 09:49:29 -0800 From: internet-drafts@ietf.org To: Esko Dijk , Marco Tiloca A new version of I-D, draft-tiloca-core-groupcomm-proxy-02.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-tiloca-core-groupcomm-proxy Revision: 02 Title: Proxy Operations for CoAP Group Communication Document date: 2020-11-02 Group: Individual Submission Pages: 24 URL: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Farchive%2Fid%2Fdraft-tiloca-core-groupcomm-proxy-02.txt&dat= a=3D04%7C01%7Cmarco.tiloca%40ri.se%7C88c6b686855b4a9ded0208d87f57a859%7C5= a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637399362375415962%7CUnknown%7C= TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M= n0%3D%7C2000&sdata=3DUxxnkPWRFrLTygOS3q%2FrzbcTmBnnFUvqGk2JGuoDPTI%3D= &reserved=3D0 Status: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fdraft-tiloca-core-groupcomm-proxy%2F&data=3D0= 4%7C01%7Cmarco.tiloca%40ri.se%7C88c6b686855b4a9ded0208d87f57a859%7C5a9809= cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637399362375415962%7CUnknown%7CTWFpb= GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D= %7C2000&sdata=3DRcNUCfM1%2Fpf6MKrLxu46lcJ8j6QPCAt6uqJxugjSWwI%3D&= reserved=3D0 Htmlized: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tiloca-core-groupcomm-proxy&data= =3D04%7C01%7Cmarco.tiloca%40ri.se%7C88c6b686855b4a9ded0208d87f57a859%7C5a= 9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637399362375415962%7CUnknown%7CT= WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn= 0%3D%7C2000&sdata=3DtI%2Bm1RzI3NAqL0YBpxiJnMarAF%2Fha6PSEBd3aBnithU%3= D&reserved=3D0 Htmlized: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= =2Eietf.org%2Fhtml%2Fdraft-tiloca-core-groupcomm-proxy-02&data=3D04%7= C01%7Cmarco.tiloca%40ri.se%7C88c6b686855b4a9ded0208d87f57a859%7C5a9809cf0= bcb413a838a09ecc40cc9e8%7C0%7C0%7C637399362375415962%7CUnknown%7CTWFpbGZs= b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C= 2000&sdata=3D9%2Fj8ggK%2FQ7Yc4RD2PP2%2BIhjnJJVLpx1nFsishYmsIWY%3D&= ;reserved=3D0 Diff: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Frfcdiff%3Furl2%3Ddraft-tiloca-core-groupcomm-proxy-02&data=3D= 04%7C01%7Cmarco.tiloca%40ri.se%7C88c6b686855b4a9ded0208d87f57a859%7C5a980= 9cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637399362375415962%7CUnknown%7CTWFp= bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3= D%7C2000&sdata=3DRnWhDzdryPIPGv5y8Jw5u3%2F8wgQQqNLxb8lfX14WOmQ%3D&= ;reserved=3D0 Abstract: This document specifies the operations performed by a forward-proxy, when using the Constrained Application Protocol (CoAP) in group communication scenarios. Proxy operations involve the processing of individual responses from servers, as reply to a single request sent by the client over unicast to the proxy, and then distributed by the proxy over IP multicast to the servers. When receiving the different responses via the proxy, the client is able to distinguish them and their origin servers, by acquiring their addressing information. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------55F9F3D2093C46BD2A737040 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello CoRE,

We have recently submitted an update for the draft "Proxy Operations for CoAP Group Communication".

https://tools.ietf.org/html/draft= -tiloca-core-groupcomm-proxy-02

The document details the operations of forward-proxies supporting CoAP group communication and addresses the issues identified in [1].<= br>
In particular, a client can send a unicast CoAP group request to the proxy including a new Option to indicate to the proxy the time period to collect responses. Also a new Option is included in the servers' responses, to enable the client to distinguish the multiple responses it receives via the proxy, as well as the different servers originating them.

This update is especially about:

1) Improved usage and encoding of the two new CoAP options.

2) Support for Observation discussed as dedicated sub-sections.

3) Support for a chain of proxies between the client and the origin servers.

4) Updated security considerations.


Comments are very welcome!

Best,
/Marco

[1] https://tools.ietf.org/html= /draft-ietf-core-groupcomm-bis-02#section-2.3.3


-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-tiloca-core-groupcomm-proxy-02.txt
Dat= e: Mon, 02 Nov 2020 09:49:29 -0800
Fro= m: internet-drafts@ietf.org
To:= Esko Dijk <esko.dijk@iotconsultancy.nl>, = Marco Tiloca <marco.tiloca@ri.se>



A new version of I-D, draft-tiloca-core-groupcomm-proxy-02.txt
has been successfully submitted by Marco Tiloca and posted to the IETF repository.

Name: draft-tiloca-core-groupcomm-proxy
Revision: 02
Title: Proxy Operations for CoAP Group Communication
Document date: 2020-11-02
Group: Individual Submission
Pages: 24
URL: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= ietf.org%2Farchive%2Fid%2Fdraft-tiloca-core-groupcomm-proxy-02.txt&am= p;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C88c6b686855b4a9ded0208d87f57a85= 9%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637399362375415962%7CUnkno= wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX= VCI6Mn0%3D%7C2000&amp;sdata=3DUxxnkPWRFrLTygOS3q%2FrzbcTmBnnFUvqGk2JG= uoDPTI%3D&amp;reserved=3D0
Status: ht= tps://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-tiloca-core-groupcomm-proxy%2F&amp;data=3D= 04%7C01%7Cmarco.tiloca%40ri.se%7C88c6b686855b4a9ded0208d87f57a859%7C5a980= 9cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637399362375415962%7CUnknown%7CTWFp= bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3= D%7C2000&amp;sdata=3DRcNUCfM1%2Fpf6MKrLxu46lcJ8j6QPCAt6uqJxugjSWwI%3D= &amp;reserved=3D0
Htmlized: = https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tiloca-core-groupcomm-proxy&amp;= data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C88c6b686855b4a9ded0208d87f57a859%= 7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637399362375415962%7CUnknown= %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC= I6Mn0%3D%7C2000&amp;sdata=3DtI%2Bm1RzI3NAqL0YBpxiJnMarAF%2Fha6PSEBd3a= BnithU%3D&amp;reserved=3D0
Htmlized: https= ://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf= =2Eorg%2Fhtml%2Fdraft-tiloca-core-groupcomm-proxy-02&amp;data=3D04%7C= 01%7Cmarco.tiloca%40ri.se%7C88c6b686855b4a9ded0208d87f57a859%7C5a9809cf0b= cb413a838a09ecc40cc9e8%7C0%7C0%7C637399362375415962%7CUnknown%7CTWFpbGZsb= 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2= 000&amp;sdata=3D9%2Fj8ggK%2FQ7Yc4RD2PP2%2BIhjnJJVLpx1nFsishYmsIWY%3D&= amp;amp;reserved=3D0
Diff: ht= tps://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Frfcdiff%3Furl2%3Ddraft-tiloca-core-groupcomm-proxy-02&amp;dat= a=3D04%7C01%7Cmarco.tiloca%40ri.se%7C88c6b686855b4a9ded0208d87f57a859%7C5= a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637399362375415962%7CUnknown%7C= TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M= n0%3D%7C2000&amp;sdata=3DRnWhDzdryPIPGv5y8Jw5u3%2F8wgQQqNLxb8lfX14WOm= Q%3D&amp;reserved=3D0

Abstract:
This document specifies the operations performed by a forward-proxy,
when using the Constrained Application Protocol (CoAP) in group
= communication scenarios. Proxy operations involve the processing of
individual responses from servers, as reply to a single request sent
by the client over unicast to the proxy, and then distributed by the
proxy over IP multicast to the servers. When receiving the different
responses via the proxy, the client is able to distinguish them and
their origin servers, by acquiring their addressing information.


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


--------------55F9F3D2093C46BD2A737040-- --oILxo7nxFszkrgZ87CetB4BK6HDY8pV1U-- --8VIaFSqqGdEbRh9j3B9K5HcAUDAgAXUfR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl+lBUUACgkQ7iZktA5Y 2kNW6Qf+OTCWxiLtfDatIrOIaw2szr0zMgxGYz1YbM6f6YPzJeyh2NUv7CQT61KI sN+SuksGssik5RyZ2/oxziSshhP6cvfQdZjFuzQyMATDy+XFX7C2M6smiUDm34iG Z2svjELd8lMSRU+/zU3TnKFGR9BUu/FSaMNfu6okiXDFux6Eim4O0WsKFolYV5Qi 2tTl7cgjUTwQyze1R19TfmOhAqm4V07Ez8wYBssXMhtfSUkRbUORxd+VHPgPNXcG Vpw34iNBP8B772Jy2b1etzV6+Dp80Bc5Sdlnt8GWjTe3aqazLxT5WUHIoVHtZikB j5qEGmrrcGM1MbJbVDCOiaXfDQ0qwg== =p18e -----END PGP SIGNATURE----- --8VIaFSqqGdEbRh9j3B9K5HcAUDAgAXUfR-- From nobody Fri Nov 6 00:14:27 2020 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 B949B3A0E8F for ; Fri, 6 Nov 2020 00:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.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 Gp-6Bfha8WeC for ; Fri, 6 Nov 2020 00:14:22 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130079.outbound.protection.outlook.com [40.107.13.79]) (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 4BBBD3A0E8A for ; Fri, 6 Nov 2020 00:14:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SRnJzuEY4x7YL4daaJjeU3Nyw4x2VzPCvaeJsFaqX92wqCAQ5SEl2QnUIXyH0eOyihFItP5sMLjG4ealcQVncp75q2hJg5f4khWhRq3qbPdvC5mp58pkllD1TiIocr6hG8vlLo2mrB05EQSD18ffFq5zyP0EPnAVVUnUPP4NNouj9RGJDbqp2b/MzDP7ty8U4CmxiElcEtPuWw+eeirgKmoHMQB/XQ7O2JCMfqARPdZ6zZYJ82kYhegkOA5t/Lpxf0zyzSriheXa9wyfKysL6BsRCwF7X0l/dYT1kvWag+1KvzNDXu+RCLuVPFtXuMzYVpqIo73wvIz2yYJXomY1eQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VlGHCkx8x6JNL/jAizQldRyxNrJPgRV11uw2zFUj4Z8=; b=l+t3cDQ0IQXgpXaUk5/xKip0aFzr75bzHm/trV5uEA9IhF3qfiSFiH2WFfBQFualYPxgl3kixYle+PRk45HPxWC0VSjNN16Dhh4ehPF1F0Od8iEgtjFi/tBgGD1vd/IzUikQjWHj8jusLWyDeryR7nPPq/3jGPaPQABeu5qAOGQaszz60v1D++fmSD5Cx+nPVRaK8TbtZfuyjpBjEppHvtq1RvNDK3RpZy2IIGZz1uDc2KhlRTEDjrvOuWsEYKRK2H2cVzGDUXPxagitT5XFL5U0BmfELqkFXwDPs3chsFrLFcPL9Hb4nCAeWR1m9Ur/XJh4RLjTKa+nuWzmW2YEgg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VlGHCkx8x6JNL/jAizQldRyxNrJPgRV11uw2zFUj4Z8=; b=cH8gc6V6MRHdtspmdzAezim2awBDrl90S4VwlyvlDvZg1uxV3M5OckPggvxtk2oXxRK8Bam5q85EQCXWIV54ri+g/utzPG8Agcp0QoA0ED55awD4LaQVyvxwOdtvEigi3n+ZjsFNSUU0QfcFJZTxY6sj47Vlwmdu09zmkx021bM= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P189MB0472.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:3c::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Fri, 6 Nov 2020 08:14:18 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd%9]) with mapi id 15.20.3541.022; Fri, 6 Nov 2020 08:14:17 +0000 References: <160433995411.13058.8602924640651441526@ietfa.amsl.com> To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== X-Forwarded-Message-Id: <160433995411.13058.8602924640651441526@ietfa.amsl.com> Message-ID: <25f5ea9d-da98-2a4a-9712-22233266453d@ri.se> Date: Fri, 6 Nov 2020 09:14:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <160433995411.13058.8602924640651441526@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PiXQ3BFDtd7Ulangj2AZ3aWpjyBXUq1bw" X-Originating-IP: [45.12.220.244] X-ClientProxiedBy: HE1P192CA0001.EURP192.PROD.OUTLOOK.COM (2603:10a6:3:fe::11) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.1.4] (45.12.220.244) by HE1P192CA0001.EURP192.PROD.OUTLOOK.COM (2603:10a6:3:fe::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21 via Frontend Transport; Fri, 6 Nov 2020 08:14:16 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8f04b001-60b4-439b-b521-08d8822bf450 X-MS-TrafficTypeDiagnostic: DB6P189MB0472: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: PWrHxphTUhxbM6i/GMX2OM8Stmx1ZYZevFftxbHehP/0Fw0NDAMP5DN9nnDMH1hLVkITdR+xhajCbc6WNaTdVVi+8oCqpATt7+7/fU+p/oN3iReiRSocyrtZLMGo34YdzsWS3GIQhvD4h/6oMO1nfViSXDgBuLkpDtfOqRTa9IdBLK7tDDuFqH7T4iemhc5dUWjnfkss1eH5fY0e9U+4Mfe/4VVQjllrc4/StGkTpuzQGdLf1vQc9WZMQ5p0jNrDU6onvU/GlIyPaqs5L1ZSpBv7aDD6QgZL3L0ZURpgxzSJCKyGRiU0IlUGJh2s90/c6ZIg9+JemKzjRoJpVVui0lM2GVeUmIqGFb/ZWXIh+J6iMB/TPjwHinzGqFcFMT0e3al9cFpDD0thTxIc3/bPAV4sqlmaCFpaM0eHCfkJVoEV9tEqByUrLGq2A8GuzGQXafunzFt3QvjG3OcuVrCm3g== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(39850400004)(376002)(136003)(396003)(366004)(33964004)(66946007)(15650500001)(21480400003)(66476007)(66556008)(66574015)(86362001)(83380400001)(52116002)(30864003)(6486002)(26005)(31696002)(235185007)(2616005)(6916009)(8936002)(45080400002)(16526019)(316002)(478600001)(44832011)(966005)(956004)(2906002)(5660300002)(36756003)(186003)(166002)(31686004)(8676002)(16576012)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: hIww/urX7KllqTX7lyN70MovVUwUB9i3YCQfjltFyC1ViiolCJPbpfsM/bINL50a+9BTQBAPhSjeXMwrV0/qbZtP7JFtTLIZDhhFvbVegElHfkPOfLfb9n2fUkCZ/Npw7v4zN1eytwQdYXuQ79Hbyse8M1OtqafHSziRlSLWBjmJqROvYkcdz9WnaCrMIkoxrIcCUidb+aTCMIkNztvOw5Au7RErxFeUY2lfn4tmInWzXnaqNiL4EE6390EEsYlPHKtn6GZAHynMRtoGP8uaPuvjZFKooe0ou7CaYnOYF38UdoAE+7Rlri/RnRzhpcY5ULbCvKXUy8AS76AmgpuKpWlWmJERBoXK14xr4SYW78y7NQheKgZdBD4SPNsVNoPU2H2tMy8oJJkJGQU7oGJ1YSq9pcedWsKGkIB2ml76CAirt4+lY4UDiG/mfBb0hXGGyWWiDzvoYFYtrL6kMaZK+0ah+zCRzW96PyVdELaPayUDO6Llm0PUyo2Dq/KFh1odf6RTPkWeM3SqjTNceF7+glrbPkcUMVSfThiTFULo1u2hfe/xrIB1LSdHHlQ/n2Nib1ggxIkjF14sQ//1GBTk3fVcBeGL73KGile06zMQjOo79/KptQx+CfgHJ56PywCggd/kgVSynWs81R6Zbd3Uz8cWrOTYqF1tpUbAOlJvX/Cbh1uPdMOtIWww7HjjyaQ+k3Rz93Bu11EILcaZfjozPUovUq5RiMmRAMlTCUv+R6kZBzcMs6UPE2EmYBB2NPyM2WPdtTX1gVGq/4OPNZ7mYod15ldq65WAu0KZnbLuKCmOnUQfFVNbRRbL60p1+eXQASbUHh0Yz5vPzm9vTHBdNZJKN3m7z+nP3Gn8SAzy3qKgc+dHnbeeaPPt3Xgn68HkiBEILze1oji3rrKNYG8eEg== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 8f04b001-60b4-439b-b521-08d8822bf450 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Nov 2020 08:14:16.8951 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: bcyZbVEFNGIDC0y1hJUlgCZV5Gw8CSetwTr8TR3RmlAIrSF0oBOUoqxYRLOa1H8CAggMPaLeExjw5KH3gC4F8Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P189MB0472 Archived-At: Subject: [core] Fwd: New Version Notification for draft-tiloca-core-oscore-discovery-07.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 06 Nov 2020 08:14:26 -0000 --PiXQ3BFDtd7Ulangj2AZ3aWpjyBXUq1bw Content-Type: multipart/mixed; boundary="ohJW5ENIykA6is6v88TJPsvl3FrVz0Mn7" --ohJW5ENIykA6is6v88TJPsvl3FrVz0Mn7 Content-Type: multipart/alternative; boundary="------------9E0E2E47D649B3706FCAB743" Content-Language: en-US This is a multi-part message in MIME format. --------------9E0E2E47D649B3706FCAB743 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello CoRE, We have recently submitted an updated version of draft-tiloca-core-oscore-discovery https://tools.ietf.org/html/draft-tiloca-core-oscore-discovery-07 The document describes how to use the CoRE Resource Directory for discovering OSCORE groups and retrieving information to join them through their Group Manager. This update is especially about: 1) Addressing the remaining points from the review of version -05 at [1] and the latest review of version -06 at [2]. 2) Clarifying how the Group Manager is aware of the names of application groups, as specified when creating the security groups (see [3]). 3) Clarifications about a same application group using multiple security groups. 4) Minor improvements to the examples. 5) The definition of a new Resource Type moved to [4]. Comments are very welcome! Best, /Marco [1] https://mailarchive.ietf.org/arch/msg/core/h62d2c2mYmG43ykz52KvbbEpgD= c/ [2] https://mailarchive.ietf.org/arch/msg/core/3M-ASJxDvrMrSi26-Jk4tI3cmO= s/ [3] https://tools.ietf.org/html/draft-ietf-ace-oscore-gm-admin [4] https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore -------- Forwarded Message -------- Subject: New Version Notification for draft-tiloca-core-oscore-discovery-07.txt Date: Mon, 02 Nov 2020 09:59:14 -0800 From: internet-drafts@ietf.org To: Christian Amsuess , Marco Tiloca , Peter van der Stok A new version of I-D, draft-tiloca-core-oscore-discovery-07.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-tiloca-core-oscore-discovery Revision: 07 Title: Discovery of OSCORE Groups with the CoRE Resource Directory Document date: 2020-11-02 Group: Individual Submission Pages: 32 URL: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Farchive%2Fid%2Fdraft-tiloca-core-oscore-discovery-07.txt&da= ta=3D04%7C01%7Cmarco.tiloca%40ri.se%7C54b8fc1935cd4d693ade08d87f590cef%7C= 5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637399368342544345%7CUnknown%7= CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6= Mn0%3D%7C2000&sdata=3Dqqd6ZLRahFh%2F0nXdOL%2BGWrWfbJRjoL9FararDFfppnk= %3D&reserved=3D0 Status: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fdraft-tiloca-core-oscore-discovery%2F&data=3D= 04%7C01%7Cmarco.tiloca%40ri.se%7C54b8fc1935cd4d693ade08d87f590cef%7C5a980= 9cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637399368342544345%7CUnknown%7CTWFp= bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3= D%7C2000&sdata=3DjNccuwXZhfatemCfBWOVzatxXB8aVIWu3ONVczw7eNA%3D&r= eserved=3D0 Htmlized: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tiloca-core-oscore-discovery&dat= a=3D04%7C01%7Cmarco.tiloca%40ri.se%7C54b8fc1935cd4d693ade08d87f590cef%7C5= a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637399368342544345%7CUnknown%7C= TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M= n0%3D%7C2000&sdata=3DmhfTFe7gFaDs2kenVw33gK%2FyzOOmh%2FMdvV5hShi0KpE%= 3D&reserved=3D0 Htmlized: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= =2Eietf.org%2Fhtml%2Fdraft-tiloca-core-oscore-discovery-07&data=3D04%= 7C01%7Cmarco.tiloca%40ri.se%7C54b8fc1935cd4d693ade08d87f590cef%7C5a9809cf= 0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637399368342544345%7CUnknown%7CTWFpbGZ= sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7= C2000&sdata=3DoTOUkqWyspoYws3ehHhcS87eZQ2g6oKoWtPxuo4UDpE%3D&rese= rved=3D0 Diff: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Frfcdiff%3Furl2%3Ddraft-tiloca-core-oscore-discovery-07&data= =3D04%7C01%7Cmarco.tiloca%40ri.se%7C54b8fc1935cd4d693ade08d87f590cef%7C5a= 9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637399368342554305%7CUnknown%7CT= WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn= 0%3D%7C2000&sdata=3D0LUPHmkOjjpNz3aY%2FBBEPQ3CQJHMjOdvA0PkiVC7rKo%3D&= amp;reserved=3D0 Abstract: Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices may not know the exact security groups to join, the respective Group Manager, or other information required to perform the joining process. This document describes how a CoAP endpoint can use descriptions and links of resources registered at the CoRE Resource Directory to discover security groups and to acquire information for joining them through the respective Group Manager. A given security group may protect multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------9E0E2E47D649B3706FCAB743 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello CoRE,

We have recently submitted an updated version of draft-tiloca-core-oscore-discovery

https://tools.ietf.org/html/draf= t-tiloca-core-oscore-discovery-07

The document describes how to use the CoRE Resource Directory for discovering OSCORE groups and retrieving information to join them through their Group Manager.

This update is especially about:

1) Addressing the remaining points from the review of version -05 at [1] and the latest review of version -06 at [2].

2) Clarifying how the Group Manager is aware of the names of application groups, as specified when creating the security groups (see [3]).

3) Clarifications about a same application group using multiple security groups.

4) Minor improvements to the examples.

5) The definition of a new Resource Type moved to [4].


Comments are very welcome!

Best,
/Marco

[1] https://mailarchive.ietf.o= rg/arch/msg/core/h62d2c2mYmG43ykz52KvbbEpgDc/
[2] https://mailarchive.ietf.o= rg/arch/msg/core/3M-ASJxDvrMrSi26-Jk4tI3cmOs/
[3] https://tools.ietf.org/html/draft-i= etf-ace-oscore-gm-admin
[4] https://tools.ietf.org/html/dr= aft-ietf-ace-key-groupcomm-oscore


-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-tiloca-core-oscore-discovery-07.txt
Dat= e: Mon, 02 Nov 2020 09:59:14 -0800
Fro= m: internet-drafts@ietf.org
To:= Christian Amsuess <christian@amsuess.com>, Marc= o Tiloca <marco.tiloca@ri.se>, Peter van der Stok <consultancy@vanderstok.org>



A new version of I-D, draft-tiloca-core-oscore-discovery-07.txt
= has been successfully submitted by Marco Tiloca and posted to the IETF repository.

Name: draft-tiloca-core-oscore-discovery
Revision: 07
Title: Discovery of OSCORE Groups with the CoRE Resource Directory<= br> Document date: 2020-11-02
Group: Individual Submission
Pages: 32
URL: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww= w.ietf.org%2Farchive%2Fid%2Fdraft-tiloca-core-oscore-discovery-07.txt&= ;amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C54b8fc1935cd4d693ade08d87f59= 0cef%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637399368342544345%7CUn= known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL= CJXVCI6Mn0%3D%7C2000&amp;sdata=3Dqqd6ZLRahFh%2F0nXdOL%2BGWrWfbJRjoL9F= ararDFfppnk%3D&amp;reserved=3D0
Status: https= ://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatracke= r.ietf.org%2Fdoc%2Fdraft-tiloca-core-oscore-discovery%2F&amp;data=3D0= 4%7C01%7Cmarco.tiloca%40ri.se%7C54b8fc1935cd4d693ade08d87f590cef%7C5a9809= cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637399368342544345%7CUnknown%7CTWFpb= GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D= %7C2000&amp;sdata=3DjNccuwXZhfatemCfBWOVzatxXB8aVIWu3ONVczw7eNA%3D&am= p;amp;reserved=3D0
Htmlized: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fda= tatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tiloca-core-oscore-discovery&= amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C54b8fc1935cd4d693ade08d87f590= cef%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637399368342544345%7CUnk= nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC= JXVCI6Mn0%3D%7C2000&amp;sdata=3DmhfTFe7gFaDs2kenVw33gK%2FyzOOmh%2FMdv= V5hShi0KpE%3D&amp;reserved=3D0
Htmlized: https://eu= r02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%= 2Fhtml%2Fdraft-tiloca-core-oscore-discovery-07&amp;data=3D04%7C01%7Cm= arco.tiloca%40ri.se%7C54b8fc1935cd4d693ade08d87f590cef%7C5a9809cf0bcb413a= 838a09ecc40cc9e8%7C0%7C0%7C637399368342544345%7CUnknown%7CTWFpbGZsb3d8eyJ= WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&am= p;amp;sdata=3DoTOUkqWyspoYws3ehHhcS87eZQ2g6oKoWtPxuo4UDpE%3D&amp;rese= rved=3D0
Diff: ht= tps://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Frfcdiff%3Furl2%3Ddraft-tiloca-core-oscore-discovery-07&amp;da= ta=3D04%7C01%7Cmarco.tiloca%40ri.se%7C54b8fc1935cd4d693ade08d87f590cef%7C= 5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637399368342554305%7CUnknown%7= CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6= Mn0%3D%7C2000&amp;sdata=3D0LUPHmkOjjpNz3aY%2FBBEPQ3CQJHMjOdvA0PkiVC7r= Ko%3D&amp;reserved=3D0

Abstract:
Group communication over the Constrained Application Protocol (CoAP)
can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices may
not know the exact security groups to join, the respective Group Manager, or other information required to perform the joining
process. This document describes how a CoAP endpoint can use
descriptions and links of resources registered at the CoRE Resource
Directory to discover security groups and to acquire information for
joining them through the respective Group Manager. A given security
group may protect multiple application groups, which are separately
announced in the Resource Directory as sets of endpoints sharing a<= br> pool of resources. This approach is consistent with, but not limited
to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments.



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


--------------9E0E2E47D649B3706FCAB743-- --ohJW5ENIykA6is6v88TJPsvl3FrVz0Mn7-- --PiXQ3BFDtd7Ulangj2AZ3aWpjyBXUq1bw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl+lBdYACgkQ7iZktA5Y 2kP6KQf+NR4JJLlvdva7Usqr5gu52lod/ge2qG6+Hx4qrJh8iN+itz8Z3BNQi1Cg ZOfuT3PRPzR7hotdgrMYGYgEdhuYNF6F6xWcCPqhMj2pZzFMbhGzHTICRh+m7+Wa n56GZBV+ihBEL2MMztPnvvdlALek/uaHYOcNbBaVJEw8Y7SXcLslCY99kg0srrdG CNAQzC3whI+lCEcVgj0f39jbROorv9XDpIC2m/PsJW8I2y5XU9WGYUQjVQbRgFYW /ucyuPyDGHgbaYQUbBho3k0lZW+aETY+36kmpWXJVrnpF1fSV/hs/DcdkGikqCe/ KI5XBxjDyP1canC/Jrx5NZooqDn7hQ== =ubp4 -----END PGP SIGNATURE----- --PiXQ3BFDtd7Ulangj2AZ3aWpjyBXUq1bw-- From nobody Fri Nov 6 00:15:22 2020 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 5AEC23A0E93 for ; Fri, 6 Nov 2020 00:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.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 LtLK0pRnLlLT for ; Fri, 6 Nov 2020 00:15:19 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2053.outbound.protection.outlook.com [40.107.20.53]) (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 8FABF3A0E92 for ; Fri, 6 Nov 2020 00:15:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OSh7/qobeUQElwXKgvgUhDKEny8Hxyh8FUKS1KC267Gfh+sOwBKAnzLCsyT/yxj0U6tkO7djh3YxwYStu/BrG+09JItzOE+8qei+5nfM/rJ4418ehgXUAZFQjjFSnJfJrJK+meNvg8dB9KXwpGNjOVbDvucGhPrxytnr3rGfOI9HZ6UWSARmZcwFq8ITrAzlqWZdswTmjI8dbfflSBFmwttJsqrXGi2tukJXOE05c5bidX5Tp//3Ye8VKWAuhXD23DF7dS4j2MmXYwcgljKJgSbxuacLuBgTpLdfBI1mY9v8hkLdabsQlnRPZTmBh9kul86nIg8/mPK1ZgqCwdLuxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AOpqgh+P+BzfhlZX8INWbNzFkvjz0HFJISD17JPQSQ8=; b=Nqz74YlXBpZPYPwkxzzTNSBWysEvv4h61tDqbenbkMlqt7eEVd+u09vfQ79JvAxENGiEHNrfDAWQxnocPnreAqF6Xm/w4PGfRrBWTH0CrboX7nV2inIKnsRuKFJEFPJP/r6xLvWwLBB0Jqp3jfVZgQdS2CEIhXoZk1+JitJvt21q0hUbmuTiTFt114Fzyc7Zt4LYnaUM7kmqUft1qfwYt1I7dYVhUp6UrQD0eVjVOWZEpxTmKvfH8uDeH2oPY8YTmOpawZ7vXY79Nb6QjJxEjlea3BLndgkajhToEtg7UIwEEYM1Ky3QgMpBOhSOpaTOR+C6oCMG4Qi09LJ4mn43xw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AOpqgh+P+BzfhlZX8INWbNzFkvjz0HFJISD17JPQSQ8=; b=AW+WyQJDrEEt95XEvphvsK74qbUeHcyKtDgGwLzQ6DXCmQwOxY/yyD1eaRgTdUp+1ZPvSAfz6f5EMJqLPiLd9JdYrmPCSVnZEDQVhCisUPEqYNxskgmRWy9jiMYfXy7UDgx8FzRb+ELhV9EHqXGmsiou+1ezENgfjzMWM+9Pjq8= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P189MB0472.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:3c::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Fri, 6 Nov 2020 08:15:16 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd%9]) with mapi id 15.20.3541.022; Fri, 6 Nov 2020 08:15:16 +0000 References: <160433969066.13331.8640949031776916845@ietfa.amsl.com> To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== X-Forwarded-Message-Id: <160433969066.13331.8640949031776916845@ietfa.amsl.com> Message-ID: <86118a71-bf14-b8c4-13b9-470b4a356385@ri.se> Date: Fri, 6 Nov 2020 09:15:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <160433969066.13331.8640949031776916845@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="C89sxDhwakc8icZUiMPjDzvUU8y1DChIg" X-Originating-IP: [45.12.220.244] X-ClientProxiedBy: HE1P192CA0006.EURP192.PROD.OUTLOOK.COM (2603:10a6:3:fe::16) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.1.4] (45.12.220.244) by HE1P192CA0006.EURP192.PROD.OUTLOOK.COM (2603:10a6:3:fe::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21 via Frontend Transport; Fri, 6 Nov 2020 08:15:15 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d3bd4a4b-f456-4867-dde7-08d8822c17b8 X-MS-TrafficTypeDiagnostic: DB6P189MB0472: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: TDUBVps6sCLsQttWR8G1hNc+cNxLF9fwqcDAAMVZFxDhEhuawFnZTiYwmdIoE4CfNjXDXcuM2efWGJMbaY/6YDRCdUPB3mEJmRSypFY7SdGSE3uHKvOhg784/woN85R8rHyMUxHhHhayDcr7MHxXjxYueSqiuMk18OivViyOhQwEoqVP18RJgw2ph9/yCUBqYd+f22locEmHyQ4hBdMBkIoMHwQOBJqxoQNQLwkVC/VrJSvple5yIKTsSp8efPlMjPG6Edocq7lF3s9TT6CYwfZa7LUF4G0Q2aFFDfNKjb6758C+X8Q7j0WHIV6ZfBqskJMbsTXSi8fY4oRQfW/0oj6cDVH3qFQ94WP8g645aZ7BFflwqR1KTq6hj7xeCNKr0ZjB5/AihN3rZSRt4rPwY4zKE3Fcgfsfz9skP+2TwvqCG3RqIKQlLxIRPRltu2t4ALGIVWtWf+ftEgxISSykpQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(39850400004)(376002)(136003)(396003)(366004)(33964004)(66946007)(15650500001)(21480400003)(66476007)(66556008)(66574015)(86362001)(83380400001)(52116002)(30864003)(6486002)(26005)(31696002)(235185007)(2616005)(6916009)(8936002)(45080400002)(16526019)(316002)(478600001)(44832011)(966005)(956004)(2906002)(5660300002)(36756003)(186003)(166002)(31686004)(8676002)(16576012)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: 5nHWlpLvCGGVG5HFRlbRqKa5ZLxFf5Sq3JglbJKzG2Afic7mJrdValsIfo3lsfLmu2Dh9eOyKXwb0v1W0dVWlmb9Yq7kZuyncCSx6N44rlpXw0YTUnR+VcANozSJfZakoQb5DsgFrHsQSDmcapC8tTC3Mix+8NfL28+2QXCc1DfHLbra6XtZxh6D0S4GLpdGbpiIMhdskK+XkVKE0NIXfW0m2vqdcw6tTrLRYytZiCdJSup1gUw5eoR5MNGggHgiP2IgKc3PaS33Vue7J945tu0v+iyNvjTaMNH6U4F6pxLxo20uhguH5s/md9f4t1tE7qDZ8dtidsVpe7PXQeEeViGOlqQp8izSQDCK24+KFvfmUkd4bloNVsukmUzUmEbKg9ZXJp9obgrx7SqBl9CbTBkI+AUp9Uuu7uM1qn6JLLFVyfIK8mAcHx6cJ8iNqMWiujAUpEDwQjaq19Ph5vmZxNR7cegY+gBKXqX2O4YW+W/ixUTY2g6ELwz+T8x/hE7KG8oOJVU8SWXut2kLv8WmEUm7E/oHv4aivyBoonQhpX11F4R45R8piMBL2OFYEt1twXrSai1kQhWBnie/3VQkR7dF9V9EiSrmkjP4b5chBtrNO75Gvc+m40yc+9vuw8l7GDElFccZHGCroxuQrRnI0WlnqBR70Br9rVs1H28beX6rPHE5JQxSwso0shhjNhXnJAihExsMSESdsqdAgKi2g5whHctjKwUGv2Hlj1oV66BOyAr44CUBs6d74mSdXBy6FZhVhI74q/J2GtYqAP4Chdcxmd3rMMCKiQDpkn2TgR4u3c8JhAOuhyVccymDgBi44rY/vEqQSf7MUDJ2qrXkhch8XeTuEHazlvT39KWRC6YvvbeDi/TtSlcOQ7AYi/ncU+AZS3mxhi0s4W+PSFDCkA== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: d3bd4a4b-f456-4867-dde7-08d8822c17b8 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Nov 2020 08:15:16.2950 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: UAf22VLFN6qMdYngEJfAZp8TNDWEncfK2K2Sftcukoj8gtvGejOQjM5IqyhyAPVDSYIcI94LbWmxIX6hnEvdog== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P189MB0472 Archived-At: Subject: [core] Fwd: New Version Notification for draft-tiloca-core-observe-multicast-notifications-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 06 Nov 2020 08:15:21 -0000 --C89sxDhwakc8icZUiMPjDzvUU8y1DChIg Content-Type: multipart/mixed; boundary="KvhxWEn6UCL3yeVk1fQv8bFFpBx2vuCCp" --KvhxWEn6UCL3yeVk1fQv8bFFpBx2vuCCp Content-Type: multipart/alternative; boundary="------------41E766F8DA6996D8DD3782F2" Content-Language: en-US This is a multi-part message in MIME format. --------------41E766F8DA6996D8DD3782F2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello CoRE, We have recently submitted an update for the draft "Observe Notifications as CoAP Multicast Responses". https://tools.ietf.org/html/draft-tiloca-core-observe-multicast-notificat= ions-04 The document describes how a CoAP server can send Observe notifications over multicast, and how Group OSCORE can be used to protect such notifications. The proposed approach is especially relevant for, but not limited to, the "Pub-Sub and Multicast" use case elaborated during the Hallway Discussion at IETF 104. This update especially includes: 1) Improved and extensible encoding of the phantom request within the informative response, now split into transport-independent and transport-specific information. 2) Improved and optimized mechanism for the rough counting of alive clients, with additional pseudo-code provided in Appendix B. 3) Support for intermediaries, with or without end-to-end security, including interaction examples in Appendix C and Appendix D. 4) Editorial improvements and section reorganization. Comments are very welcome! Best, /Marco -------- Forwarded Message -------- Subject: New Version Notification for draft-tiloca-core-observe-multicast-notifications-04.txt Date: Mon, 02 Nov 2020 09:54:50 -0800 From: internet-drafts@ietf.org To: Christian Amsuess , Francesca Palombini , Rikard Hoeglund , Marco Tiloca A new version of I-D, draft-tiloca-core-observe-multicast-notifications-04.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-tiloca-core-observe-multicast-notifications Revision: 04 Title: Observe Notifications as CoAP Multicast Responses Document date: 2020-11-02 Group: Individual Submission Pages: 62 URL: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Farchive%2Fid%2Fdraft-tiloca-core-observe-multicast-notification= s-04.txt&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C44e2df4907354f99dba4= 08d87f586675%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637399365531329= 608%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I= k1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3D0sdhsg2lYVgptARxqJAZ9o5O9b3amXwS= BPFNNnEn5rg%3D&reserved=3D0 Status: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fdraft-tiloca-core-observe-multicast-notifications= %2F&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C44e2df4907354f99dba408d87= f586675%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637399365531329608%7= CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW= wiLCJXVCI6Mn0%3D%7C2000&sdata=3D9DSC4vYR0stOduVyFM3%2B%2Fhuc5cF7mofbZ= Q3BKZ%2FcwzM%3D&reserved=3D0 Htmlized: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tiloca-core-observe-multicast-notifi= cations&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C44e2df4907354f99dba40= 8d87f586675%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6373993655313296= 08%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik= 1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DfnTVRhJcbiLGHNj6wy8PK1jZBSz1vxPSc= EVhdNdD6ls%3D&reserved=3D0 Htmlized: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= =2Eietf.org%2Fhtml%2Fdraft-tiloca-core-observe-multicast-notifications-04= &data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C44e2df4907354f99dba408d87f58= 6675%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637399365531329608%7CUn= known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL= CJXVCI6Mn0%3D%7C2000&sdata=3DoaFVdZeL4aKM1158lr0ffOZKFOnKF%2B5S81tI60= xOSWw%3D&reserved=3D0 Diff: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Frfcdiff%3Furl2%3Ddraft-tiloca-core-observe-multicast-notificati= ons-04&data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C44e2df4907354f99dba408= d87f586675%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63739936553132960= 8%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1= haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3DOHfBx3enju2akgqf4r2WuYlPtLbUKD%2Fx= %2B5ds7K1KNJo%3D&reserved=3D0 Abstract: The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server, and receive notifications as unicast responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the server to send a single notification to all the clients observing a same target resource. This document defines how a CoAP server sends observe notifications as response messages over multicast, by synchronizing all the observers of a same resource on a same shared Token value. Besides, this document defines how Group OSCORE can be used to protect multicast notifications end-to-end from the CoAP server to the multiple observer clients. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------41E766F8DA6996D8DD3782F2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello CoRE,

We have recently submitted an update for the draft "Observe Notifications as CoAP Multicast Responses".

https://tools.ietf.or= g/html/draft-tiloca-core-observe-multicast-notifications-04

The document describes how a CoAP server can send Observe notifications over multicast, and how Group OSCORE can be used to protect such notifications. The proposed approach is especially relevant for, but not limited to, the "Pub-Sub and Multicast" use case elaborated during the Hallway Discussion at IETF 104.

This update especially includes:

1) Improved and extensible encoding of the phantom request within the informative response, now split into transport-independent and transport-specific information.

2) Improved and optimized mechanism for the rough counting of alive clients, with additional pseudo-code provided in Appendix B.

3) Support for intermediaries, with or without end-to-end security, including interaction examples in Appendix C and Appendix D.

4) Editorial improvements and section reorganization.


Comments are very welcome!

Best,
/Marco


-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-tiloca-core-observe-multicast-notifications-04.txt
Dat= e: Mon, 02 Nov 2020 09:54:50 -0800
Fro= m: internet-drafts@ietf.org
To:= Christian Amsuess <christian@amsuess.com>, Francesca Palombini <francesca.palombini@ericsson.com>, = Rikard Hoeglund <rikard.hoglund@ri.se>, Marco Tiloca <marco.tiloca@ri.se>



A new version of I-D, draft-tiloca-core-observe-multicast-notifications-04.txt
has been successfully submitted by Marco Tiloca and posted to the IETF repository.

Name: draft-tiloca-core-observe-multicast-notifications
Revision: 04
Title: Observe Notifications as CoAP Multicast Responses
Document date: 2020-11-02
Group: Individual Submission
Pages: 62
URL: https://eur02.safelinks.protection.outlook.com/?url=3Dhttp= s%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-tiloca-core-observe-multica= st-notifications-04.txt&amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C4= 4e2df4907354f99dba408d87f586675%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C= 0%7C637399365531329608%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj= oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=3D0sdhsg2lY= VgptARxqJAZ9o5O9b3amXwSBPFNNnEn5rg%3D&amp;reserved=3D0
Status: https://eur02.safelinks.protection.outlook.com/?url=3Dhtt= ps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tiloca-core-observe-multica= st-notifications%2F&amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C44e2d= f4907354f99dba408d87f586675%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C= 637399365531329608%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2= luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=3D9DSC4vYR0stOd= uVyFM3%2B%2Fhuc5cF7mofbZQ3BKZ%2FcwzM%3D&amp;reserved=3D0
Htmlized: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tiloca-core-observe-mu= lticast-notifications&amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C44e= 2df4907354f99dba408d87f586675%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%= 7C637399365531329608%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi= V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=3DfnTVRhJcbiL= GHNj6wy8PK1jZBSz1vxPScEVhdNdD6ls%3D&amp;reserved=3D0
Htmlized: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Ftools.ietf.org%2Fhtml%2Fdraft-tiloca-core-observe-multicast-notificatio= ns-04&amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C44e2df4907354f99dba= 408d87f586675%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63739936553132= 9608%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6= Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=3DoaFVdZeL4aKM1158lr0ffOZKFOn= KF%2B5S81tI60xOSWw%3D&amp;reserved=3D0
Diff: https://eur02.safelinks.protection.outlook.com/?url=3Dht= tps%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-tiloca-core-observe-mul= ticast-notifications-04&amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C4= 4e2df4907354f99dba408d87f586675%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C= 0%7C637399365531329608%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj= oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=3DOHfBx3enj= u2akgqf4r2WuYlPtLbUKD%2Fx%2B5ds7K1KNJo%3D&amp;reserved=3D0

Abstract:
The Constrained Application Protocol (CoAP) allows clients to
"observe" resources at a server, and receive notifications as unicast
responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the<= br> server to send a single notification to all the clients observing a
same target resource. This document defines how a CoAP server sends
observe notifications as response messages over multicast, by
synchronizing all the observers of a same resource on a same shared
Token value. Besides, this document defines how Group OSCORE can be
used to protect multicast notifications end-to-end from the CoAP server to the multiple observer clients.



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


--------------41E766F8DA6996D8DD3782F2-- --KvhxWEn6UCL3yeVk1fQv8bFFpBx2vuCCp-- --C89sxDhwakc8icZUiMPjDzvUU8y1DChIg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl+lBhEACgkQ7iZktA5Y 2kNTgwf+PdZ1dpDS9HcbsEwHVKIN5Gi5nuDTgfP1CTr6yA2UfKsdlv5bWLT53eyV QW4YOwagHSYpi4MBz38eukGghOZXn6ATab2Ma1COlP00mw87aXGSoIObkIfVBelm DWofWSLQBGaq00I5JvsC/P89ApSRiuniUzFDzN11TlIpOsWz0uGFq/vzliEoDrCH lAmopQFVBW0UgRscfy86NZaI70FkSM8joYlBlJqrzJhpM4XbSsd2SZKqgFCG94Bj tdx2h+NcxYjLyu4Eb7BT8McXvaIibP09okm/0ktBcvWS294WrXDnCGraj846pEIN R47M5C6JuYjiPnt5K21+YP5QA7Drkg== =TSJm -----END PGP SIGNATURE----- --C89sxDhwakc8icZUiMPjDzvUU8y1DChIg-- From nobody Mon Nov 9 06:41:53 2020 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 51B733A0DDF for ; Mon, 9 Nov 2020 06:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 nGVmO-rTK5ay for ; Mon, 9 Nov 2020 06:41:50 -0800 (PST) Received: from forward4-smtp.messagingengine.com (forward4-smtp.messagingengine.com [66.111.4.238]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2F23A0DA4 for ; Mon, 9 Nov 2020 06:41:49 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.nyi.internal (Postfix) with ESMTP id E7F0C1943CA4; Mon, 9 Nov 2020 09:41:48 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 09 Nov 2020 09:41:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=ERE2Z6Fo6IRt7wclh34SxX8Hp73BJ PG48OfH6FFzsi0=; b=gr9B5R8FQqrwdyO7u3ciVD8lJYMZcxVD4FKcam8YwaFMj +B2xRG9HVl8PLyLZrx/IMACQ8Ne+tgEAssd5aqsv+4gsQYx0aj7JM0ATL+4IdXOC z8tiPvZOg7wr1xpip11XdM9o1fnHfAYKG/JtJa4hj938Leuf2zE93pdzKjnZSfXN 1AVRyc6hjJimPAk1DLd7tBphyWB+JJziVbmeK8Kr9uDb+erF7R7Ss1qv+2k0TMMd LlZO9T8Rfat1VtxC9NKhHLLlY/21mYjMce8MFbxOYj/pdAt5s6j3xZrrv4DwO2PF NzbPYCkZFeUXzUqrSO/PsuI0j3mUwJ4f8gEVcpikA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudduhedgieelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggusehttdertddttdejnecuhfhrohhmpeflrghimhgvucfl ihhmrohnvgiiuceojhgrihhmvgesihhkihdrfhhiqeenucggtffrrghtthgvrhhnpefgke duuddvteetveefffevgefhjedvueethfejjedtvdehteekhfdtfeffhfeifeenucffohhm rghinhepihgrnhgrrdhorhhgpdhtuhhrsghiughithihrdhmghenucfkphepkedvrddvtd efrddvvdejrdduvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehjrghimhgvsehikhhirdhfih X-ME-Proxy: Received: from EMB-918HFH01 (82-203-227-12.bb.dnainternet.fi [82.203.227.12]) by mail.messagingengine.com (Postfix) with ESMTPA id 49E33328005A; Mon, 9 Nov 2020 09:41:47 -0500 (EST) Date: Mon, 9 Nov 2020 16:41:45 +0200 From: =?utf-8?Q?Jaime=20Jim=C3=A9nez?= To: CoRE WG Message-ID: <20201109144145.nzp2oqiam7bdlqed@EMB-918HFH01> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Archived-At: Subject: [core] Proposed new SenML Units X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 09 Nov 2020 14:41:52 -0000 Dear CoRE and SeNML experts, the IPSO WG has some new objects being registered that contain units that are not currently present in the IANA SenML registry ( https://www.iana.org/assignments/senml/senml.xhtml ) nor derived from it. We would like to discuss the addition of the units below: +===========+================================+=======+ | Symbol | Description | Type | +===========+================================+=======+ | NTU | Nephelometric Turbidity Unit | Float | +-----------+--------------------------------+-------+ | mg/l | milligrams per liter | Float | +-----------+--------------------------------+-------+ NTU is the most common way to measure turbidity. mg/l is used to measure concentration, possibly g/l should also be added as shown in the table below. On the secondary units table we would have the units below. +=========+======================+======+==========+======+ |Secondary| Description |SenML | Scale |Offset| | Unit | |Unit | | | +=========+======================+======+==========+======+ | ppb | parts per billion | / | 1e-9 | 0 | +---------+----------------------+------+----------+------+ | ppt | parts per trillion | / | 1e-12 | 0 | +---------+----------------------+------+----------+------+ | KB | Kilobytes | B | 1000 | 0 | +---------+----------------------+------+----------+------+ | VAh | Volt Ampere x Hour | kVAh | 1/1000 | 0 | +---------+----------------------+------+----------+------+ | g/l | grams per liter | mg/l | 1000 | 0 | +---------+----------------------+------+----------+------+ As to the KB addition, the reason is that many are still confused as to whether KB is 1000 or 1024 bytes. If we are taking KB as 1000 bytes, then having an entry in the table would be a good clarification to avoid ambiguity. ppt could be confused with parts per thousand by some, so I would like to clarify in this email that "parts per thousand" would be the "/1000" or "permille" entry in the secondary units registry. Please confirm this as well. I believe the scale of ppb and ppt is correct, please double check just in case. Thanks! -- Jaime From nobody Mon Nov 9 07:13:06 2020 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 30D123A1118 for ; Mon, 9 Nov 2020 07:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08CIIlHwHjxP for ; Mon, 9 Nov 2020 07:13:00 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02D73A1116 for ; Mon, 9 Nov 2020 07:13:00 -0800 (PST) Received: from client-pool2-341.vpn.uni-bremen.de (client-pool2-341.vpn.uni-bremen.de [134.102.49.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4CVDyL3DWjzyV4; Mon, 9 Nov 2020 16:12:58 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <20201109144145.nzp2oqiam7bdlqed@EMB-918HFH01> Date: Mon, 9 Nov 2020 16:12:58 +0100 Cc: CoRE WG X-Mao-Original-Outgoing-Id: 626627577.9350311-8b1cef00544d01342c5497f4efc248e9 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20201109144145.nzp2oqiam7bdlqed@EMB-918HFH01> To: =?utf-8?Q?Jaime_Jim=C3=A9nez?= X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] Proposed new SenML Units X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 09 Nov 2020 15:13:04 -0000 Hi Jaime, > On 2020-11-09, at 15:41, Jaime Jim=C3=A9nez wrote: >=20 >=20 > Dear CoRE and SeNML experts, >=20 > the IPSO WG has some new objects being registered that contain units > that are not currently present in the IANA SenML registry ( > https://www.iana.org/assignments/senml/senml.xhtml ) nor derived > from it. We would like to discuss the addition of the units below: >=20 > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D= =3D+ > | Symbol | Description | Type | > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D= =3D+ > | NTU | Nephelometric Turbidity Unit | Float | > +-----------+--------------------------------+-------+ > | mg/l | milligrams per liter | Float | > +-----------+--------------------------------+-------+ > NTU is the most common way to measure turbidity. This one is interesting. There are several Turbidity units, which are = not in a simple linear relationship, so I would like to get some input = from domain experts which ones we should have (and which are more of a = historical interest). > mg/l is used to measure > concentration, possibly g/l should also be added as shown in the table > below.=20 We already have =20 kg/m3 kilogram per cubic meter (mass density, mass concentration) = float [RFC8798] One mg/l is 1/1000 kg/m3, so that would go into table 2. > On the secondary units table we would have the units below.=20 > +=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D= =3D=3D=3D=3D=3D+ > |Secondary| Description |SenML | Scale |Offset| | Unit = | |Unit | | | > +=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D= =3D=3D=3D=3D=3D+ > | ppb | parts per billion | / | 1e-9 | 0 | > +---------+----------------------+------+----------+------+ > | ppt | parts per trillion | / | 1e-12 | 0 | > +---------+----------------------+------+----------+------+ > | KB | Kilobytes | B | 1000 | 0 | > +---------+----------------------+------+----------+------+ > | VAh | Volt Ampere x Hour | kVAh | 1/1000 | 0 | > +---------+----------------------+------+----------+------+ > | g/l | grams per liter | mg/l | 1000 | 0 | > +---------+----------------------+------+----------+------+ VAh should be on the SI base unit, i.e.: VAh volt-ampere-hour VAs 3600 0 g/l is a synonym for kg/m3 (i.e. scale=3D1); that is not strictly needed = but could be added if the g/l people can=E2=80=99t adjust to kg/m3. > As to the KB addition, the reason is that many are still confused as = to > whether KB is 1000 or 1024 bytes. KB =3D Kelvin-Byte, pretty much nonsensical. kB is 1000 B, which is not very widely used. KiB is 1024 B, which we already have. > If we are taking KB as 1000 bytes, KB is like kph, it=E2=80=99s not properly defined and should not be = added. > then having an entry in the table would be a good clarification to = avoid > ambiguity. >=20 > ppt could be confused with parts per thousand by some, so I would like > to clarify in this email that "parts per thousand" would be the = "/1000" > or "permille" entry in the secondary units registry. Please confirm = this > as well.=20 Yes. So, after adding ppb and ppt, we=E2=80=99ll have / /100 /1000 ppm ppb ppt 1 0.01 1e-3 1e-6 1e-9 1e-12 > I believe the scale of ppb and ppt is correct, please double check = just > in case.=20 Yes. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Nov 9 07:43:49 2020 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 D30753A1143 for ; Mon, 9 Nov 2020 07:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 3mqImLrMVveN for ; Mon, 9 Nov 2020 07:43:46 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 7F4FF3A113C for ; Mon, 9 Nov 2020 07:43:46 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id 10so8530195pfp.5 for ; Mon, 09 Nov 2020 07:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Q9iTDFKYmNdXFaVqKnjP7fyzwzuflHCgkXl5a2DjQeo=; b=NLTr1PNbhyPRT/dgi5CLXYD+ncbRuz7IjQmMrn+04P6+jXRJG7apbM7oncJ41wXIi0 PJ18ZGjdAOFOi2uJyWFHAJ+rLLEoBjE1axcRX9InenvZFYBGXnEZDXDw8xXMg/C88t61 bZt4k0M70bG7XHyIiuepvZfzVO4WCNA6YboezsVY3pDtn9+E8DWiEasrFmfgvFWlk+QR vDjEATRDDGeXzdqkIeOAQ8q5gB2DX37MxCtkxgCRM4aUrHx7Z23QzgmcnyDhVJb4WlA8 Am2dp1dFFD5/kwbjtW74ah4dl9n+V5zEvnJLuO3gUZB3S2mkmkTk1/lFdOPvoyah8Sfb YFtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Q9iTDFKYmNdXFaVqKnjP7fyzwzuflHCgkXl5a2DjQeo=; b=DfY0vemWFiVtXERt+UWY5f3GDaEYdQ2gTy7R53r9J99s1fCSl6JSA/NQUVVB830e4j Ndg25TIUZsQwFxeYtJ26LFIRB9kWtHl7klluTDuHr0kGfezdgnks0txA3poBIvvYYd+W FwyR47qCsMp378YAsi5WRZav61as6mvtTdS5i4ILK7qNslpUWUzwCxEtfTUVn+Kkk/EP aNTZn3sFTFkudGuPecKlpyG0Se0JZs0ZczLHQIkD/80eSm3Ud+qK8u7qcBz0FhyE/OAu N5nm8xS0jzxlttDgwt003va8G05KUh6txARRNi08UWm3WFDZ7sT+tko10WSGnibC/wnq BlHg== X-Gm-Message-State: AOAM531SPdx3tuvCaRWJrrc7I+TGzkr5HcN86eI69SksMx6moC9LkzWm 642L6EhHbeOsbNkeeSfbdFA= X-Google-Smtp-Source: ABdhPJynHNgeBQdTqd7thx6eImWcbObRBKnG4CWOTafgOYFkr8Ye4A43FV7/InKyfKADY/AiTZ4Pdw== X-Received: by 2002:a17:90a:4814:: with SMTP id a20mr13566810pjh.163.1604936626026; Mon, 09 Nov 2020 07:43:46 -0800 (PST) Received: from [172.16.0.11] (c-71-202-145-92.hsd1.ca.comcast.net. [71.202.145.92]) by smtp.gmail.com with ESMTPSA id x26sm11359646pfn.178.2020.11.09.07.43.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Nov 2020 07:43:45 -0800 (PST) From: Michael Koster Message-Id: <041E8922-F467-430B-957C-6BB193D8352F@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7E1AE1A0-2DF2-4BAE-A259-7A77D2D85014" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 9 Nov 2020 07:43:42 -0800 In-Reply-To: Cc: =?utf-8?Q?Jaime_Jim=C3=A9nez?= , CoRE WG To: Carsten Bormann References: <20201109144145.nzp2oqiam7bdlqed@EMB-918HFH01> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Proposed new SenML Units X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 09 Nov 2020 15:43:48 -0000 --Apple-Mail=_7E1AE1A0-2DF2-4BAE-A259-7A77D2D85014 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 9, 2020, at 7:12 AM, Carsten Bormann wrote: >=20 >>=20 >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D+ >> | Symbol | Description | Type | >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D+ >> | NTU | Nephelometric Turbidity Unit | Float | >> +-----------+--------------------------------+-------+ >> | mg/l | milligrams per liter | Float | >> +-----------+--------------------------------+-------+ >=20 >=20 >> NTU is the most common way to measure turbidity. >=20 > This one is interesting. There are several Turbidity units, which are = not in a simple linear relationship, so I would like to get some input = from domain experts which ones we should have (and which are more of a = historical interest). >=20 >=20 FWIW While I'm not specifically a domain expert, I do have experience in a = water turbidity measurement program. I was responsible for process control and measurement systems in a large = number of oil & gas installations in Alaska in the 1980s (please no = "historical interest jokes...) One of the installations was a water injection facility that needed to = be accountable for the purity of the water injected into the ground over = a period of decades. We maintained a fleet of "Surface-Scatter = Turbidimeters" which measured turbidity in NTU. I was responsible for = calibration of the machines and "certification" of the measurement = record. Turbidity is an indirect measure of suspended solids in water or other = fluid, measured according of the amout of light blocked from = transmission through the fluid. The Surface-Scatter Turbidimeter, or = Nephelometer, measures the diffraction of light from surface roughness = caused by the suspended solids. Standard solutions or cards (for field = calibration) are used to calibrate the measurements. A quick check on Wikipedia and discussion with an acquaintance who is a = (retired) water treatment consultant (chemical salesman) confirms that = NTU is still the metric of choice, though some facilities that know what = their contaminants are can convert it to a concentration unit like ug/l = for "internal" use. Best regards, Michael= --Apple-Mail=_7E1AE1A0-2DF2-4BAE-A259-7A77D2D85014 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Nov 9, 2020, at 7:12 AM, Carsten Bormann <cabo@tzi.org> = wrote:


+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D= =3D=3D=3D=3D+
| Symbol    | Description =             &n= bsp;      | Type  |
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D= =3D=3D=3D=3D+
| NTU       | = Nephelometric Turbidity Unit   | Float |
+-----------+--------------------------------+-------+
| mg/l      | milligrams per liter =           | Float |
+-----------+--------------------------------+-------+


NTU is the most common way = to measure turbidity.

This one is interesting. =  There are several Turbidity units, which are not in a simple = linear relationship, so I would like to get some input from domain = experts which ones we should have (and which are more of a historical = interest).



FWIW

While I'm not specifically a domain = expert, I do have experience in a water turbidity measurement = program.

I was = responsible for process control and measurement systems in a large = number of oil & gas installations in Alaska in the 1980s (please no = "historical interest jokes...)

One of the installations was a water = injection facility that needed to be accountable for the purity of the = water injected into the ground over a period of decades. We maintained a = fleet of "Surface-Scatter Turbidimeters" which measured turbidity in = NTU. I was responsible for calibration of the machines and = "certification" of the measurement record.

Turbidity is an indirect measure of = suspended solids in water or other fluid, measured according of the = amout of light blocked from transmission through the fluid. The = Surface-Scatter Turbidimeter, or Nephelometer, measures the diffraction = of light from surface roughness caused by the suspended solids. Standard = solutions or cards (for field calibration) are used to calibrate the = measurements.

A = quick check on Wikipedia and discussion with an acquaintance who is a = (retired) water treatment consultant (chemical salesman) confirms that = NTU is still the metric of choice, though some facilities that know what = their contaminants are can convert it to a concentration unit like ug/l = for "internal" use.

Best regards,

Michael
= --Apple-Mail=_7E1AE1A0-2DF2-4BAE-A259-7A77D2D85014-- From nobody Tue Nov 10 09:16:29 2020 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 60EF93A09DA for ; Tue, 10 Nov 2020 09:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 pS6sWXlctkTM for ; Tue, 10 Nov 2020 09:16:24 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08DA43A0D20 for ; Tue, 10 Nov 2020 09:15:35 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 5538E40835 for ; Tue, 10 Nov 2020 18:15:33 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 9B4ABAB for ; Tue, 10 Nov 2020 18:15:31 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:7908:6ab4:a9d3:2528]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 18A2F34 for ; Tue, 10 Nov 2020 18:15:31 +0100 (CET) Received: (nullmailer pid 1383528 invoked by uid 1000); Tue, 10 Nov 2020 17:15:30 -0000 Date: Tue, 10 Nov 2020 18:15:30 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Message-ID: <20201110171530.GA1301772@hephaistos.amsuess.com> References: <160433906029.4820.14907779807204481594@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: <160433906029.4820.14907779807204481594@ietfa.amsl.com> Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-oscore-groupcomm-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 10 Nov 2020 17:16:27 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello OSCORE-groupcomm authors, thanks for incorporating my earlier comments. While reading -10 for the purpose of implementing it, a few more points came up (in linear order of the document): * "Furthermore, sufficiently large replay windows should be considered,": This paragraph reads as if a server receiving a high sequence number gets completely out of sync (to the point where it needs to recover), when actually the only ill-effect of a, say, a jump from 1000 to 1100 with a 32bit replay window is that a delayed message with sequence number 1002 will be rejected. The next message at 1101 will still be accepted. Recovery *will* be necessary if the server has, in the mean time, evicted the client's replay window out of its list of available windows. So maybe the recommendation should rather be to not have overly long replay windows (or to suggest the replay windows may be truncated when unused), as that'd allow the server to keep more clients' replay windows around. (Or I just misread the paragraph). * It felt like there are different ways for the sender sequence number to go back to 0. (Search for " to 0", first three occurrences). What's really the case is that the first two *trigger* the third, but the repetition around there made them read like separate things. * "and SHOULD preserve the current value of the Sender ID of each group member.": Why bother? It's not like anything can be reused after the master secret changed. ("bother", because the GM may want to hand out KIDs sequentially rather than tracking a bitfield). * Oh, I see -- later on it says that KIDs can never be reused, even when master parameters change. Doesn't that lead to irrecoverably large KIDs over time? (Ie. they're shiny short first, but after a few joinings, group leaves, device restarts and other fluctuation, they wind up in the >=3D4-byte range). This also reads a bit controversially -- it says "Even if Gid and Master Secret are renewed as described in this section, the Group Manager MUST NOT reassign", which sounds like "never ever", but misses the master salt from the line above. And it refers to 2.4.3.1, where it only talks about KID reuse ~"if none of the master parameters change". 3.2 item 5 reads like "never ever" again, so this needs clarification first and then editing. * "The value of the 'kid' parameter in the 'unprotected' field of response messages MUST be set to the Sender ID of the endpoint transmitting the message." Is this the case even when requests were made in pairwise mode? (For comparison, the section above (4.1) is explicitly "for group mode only", and 4.3 says "in group and pairwise mode".) * Does it make sense to use the 4.3 extended parameters (with the new algorithm data and the added group ID) in pairwise mode? After all, everything else in there (including the group mode bit) is really just vanilla OSCORE. Or are observations in pairwise-pairwise mode supposed to survive rekeying? (If that's the case, the question may arise whether anyone might be tempted to use pairwise-pairwise in a 1:1 setting just to use that property). * external_aad: Why is countersign_key_type_capab in there twice? * "The new element 'request_kid_context' contains the value of" could use some explaining why this now is in here. AFAIR, it is to allow observations to extend over rekeyings. (Shouldn't also, due to this, KIDs be reusable once the KID-Context is changed?) Same for the OSCORE_option being present in the signature external_aad. (A forward reference to 10.6.2 may do). * Examples in Group Mode: I think it's easier to grasp if rather than using the value "COUNTERSIGN", a signature value a la "de 9e ... f1" / 0xde9e...f1 (depending on the representation) were used; the COUNTERSIGN value reads too much like a constant in the before-compression COSE object ("What's that, a numeric, a tagged value?"). * "Note that, if the Group Flag is set to 0, and the recipient endpoint retrieves a Security Context which is valid to process the message but is not associated to an OSCORE group," I don't have a fleshed-out proposal here, but we may manage to use the same bit for other purposes in non-group-OSCORE messages. As the introduction to that section states, the receiver MUST be able to distinguish from the KID context and KID whether it's from a Group OSCORE or a different context. For Group OSCORE, that bit distinguishes between group and pairwise. For other, that other may use that bit. (I know that this is contradicting the previous suggestion that led to this bit being flipped in -09; recent discussions about flag bit usage indicate to me that other ways of getting OSCORE keys may have different varieties as well, and this would align well then). * "For each ongoing observation, the server MUST include in the first notification": This may get sucked up by a proxy that doesn't forward until a following notification arrives. Moreover, it may be unnecessary if the rekeying fits snugly between notifications. Suggested alternative: The server can help the client synchronize by sending the Gid as the ID Context for notifcations following a rekeying. If there is a known upper limit to the duration of a full rekeying, it SHOULD set the Gid during that time. Otherwise, it SHOULD set it until the Max-Age of the last notification before the rekeying has expired. * "Senders MUST NOT use the pairwise mode to protect a message intended for multiple recipients.": That's a factual and not an interoperability statement. It can not. If that's meant to rule out a pairwise request to the broadcast address (hoping that the right node will answer), it should say "protect a message sent to multiple recipients". (But probably that's not what's meant, given 9.1 proposes an address discovery resource, and for accessing that by a single KID the pairwise mode would make a good choice). * Sections 9.2ff are described as a delta to 8.1ff. Given the external_aad and key choices are already in the section 9 header, would there be any per-step delta left to explain at all if they were instead relative to RFC8613 Section 8? That'd make Section 9 a lot slimmer. * I'm still not fully sold on why the Object-Security option needs to be in the external_aad -- but having two versions of the external_aad seems extraneous to me. If the option needs to be in there, I think it'd be easier to have it in the external_aad for all purposes right away. Also, was treating the OSCORE option as Class I considered? That doesn't solve the problem of having many different external_aad constructions, but it'd be using existing mechanism. (Although implementors may curse if they didn't do Class I yet). I'll come back to that once I've actually implemented it. * "Unless exchanges in a group rely only on unicast messages": I think that's only understandable for readers that have an active memory of Section 7.4 of RFC8613; it'd need either more context or slimming down, maybe like this? "As multicast usually involves unreliable transports, the simplification of the replay window to a size of 1 that's suggested in RFC8613 Section 7.4 is not viable with Group OSCORE." * Summarizing the KID-reuse questions, I think a diagram of the componetns may help, like: =E2=86=90--=E2=86=92 KID Secret =E2=86=90--=E2=86=92 Group ID =E2=86=90--=E2=86=92 KID =E2=86=90--=E2=86=92 KID =E2=86=91 Change in =E2=86=91 =E2=86=91-- Group ID changes allow old K= IDs to be reused lockstep | (but KIDs usually stay the same for efficien= t rollout) --- KID changes don't necessitate a Group ID change (are there any other components that can chagnge?) In that context: Can an ancient group ID be reused? * E.1 and E.2 Best Effort Synchronization / Baseline Synchronization A server doing any of these needs to use own Partial IVs all the time. It may be acceptable in a scenario to eat the replays, but it's almost certainly not acceptable to commit nonce reuse (which *can* happen with Best Effort Synchronization). * E.3 Challenge-Response Synchronization: "The server MUST NOT set the Echo Option to a value which is both predictable and reusable." While this is technically correct, it's hard to evaluate as a reader. How about "The Echo option value SHOULD not be reused, and when it is MUST be highly unlikely to have been used with this client recently."? * "sends a request as a unicast message addressed to the same server": That should indicate pairwise mode. There's later paragraphs on this where 10.7 is mentioned, but given how widely this open things up, pairwise mode should be mandatory on Echo recovery. * "The server either delivers the request to the application if it is an actual retransmission of the original one, or discards it otherwise": For that the server would need to remember. Ther *is* somethign to take care of, though: Only the first time the Echo request arrives it can be processed, otherwise it may reset an already good replay window. Suggesting to replace the paragraph with: "If the verification is successful and the replay window has not been set yet, the server updates its Replay Window to mark the current sequence number as seen (but all newer ones as new), and forwards the message as fresh to the application. Otherwise, it discards the verification result and treats the message as fresh or replay according to the existing replay window." "(believed to be) lost" How is that not a binary thing? (May relate to the first question). Either there is a replay window, in which case it can be used (and it does get fast-forwarded in need be), or not and it needs to be recovered. The following paragraphs elaborate on what a loss would mean, but don't explain why it would be relevant. Something like this would be applicable if we only ever transported the last bits of the sequence numbers in a sliding-window fashion, but that's not what happens in OSCORE. KR Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+qyq4ACgkQOY0REtOk veGGEA/+JjHwxTSL77sClOm4LCgmz8DJWD/sI1mswsIuFFkE74y8/stp/G+78Sap CrmtwASTtRoL3xGzFXZC4y1POcO3hRciQCr5qtH78WF/KDAfrGyqjvrnOQA5V27O UbqvLpJR3X16172kuBcpbsWUgoLwGMz+azkSmP3W/oWX5dGgb55/R/eYabw6K7WX NZFCodJ+KPgZbMnoKWUoqH6a6a4dYh15Hg7tYmGy17Wn5D+G78T5RSy3tTyZ1hVw mFDrVw7l+GdWAGY+CvaR1eQpxCm67t6O5ft41Tl9MF6na05yRyUBwVwp8I/2BkjM phKHUfP85UBOw/hR55BlxFQIr9CbBYNPSZpOq3BwJTmvoDoA/cCQ4QMBmGh5M4XB uA9VzbbAJPMg00tNE8eqq2u0ZMgaAV/piMhMv/sopnSl97MFveBcsJsnZ8E8vLaA z+d899MWjlbyU6N0M+8rf54IRB99s2YxKK4F5w3jjuVehC4TwDeVsRDQyRxWbQGp eCTnHRwdA6GicIk/whGE8kZPOsQO+2BblxK8aSPa2u7BDnjV2iIV9YAHBy2jQIos OBjcIeCE4qlGBJfaflKkVYxH0Yf9DoudzSNKFdCRygu9iw2fZfxUDiTeqaJyKRhA QQ1J5K411ohe63DE5/1PqDkz/Dr7W2Z+ASCtEVc3o9FkHGr0nS0= =vMbL -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- From nobody Tue Nov 10 09:16:43 2020 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 7FE603A0D38 for ; Tue, 10 Nov 2020 09:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 bxsyGHPH-kvf for ; Tue, 10 Nov 2020 09:16:39 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20078.outbound.protection.outlook.com [40.107.2.78]) (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 6359F3A0D67 for ; Tue, 10 Nov 2020 09:16:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bmqYc4Y0ihTCca3oIet4kNSM2oyM3ly0HeQNWi4AZXPwU8P2ykraODDcdBWcg3OnNEYVfPjlx2zhp2peGA8VsiLe8p+im/Wsb8eLKaPuoQKsTlc5Y3XRFDQrco/BdMVkGX8BuGASzddk8FKjO++jSB5f3xMNxozA6mvlG207OfbPJNSS630YR8DuEgwTpJZJ3ilPBKxIoCf7IiqTADIgmY1daC/hX0NutJQJHX8aQWNsSs+4EQ+OIcWr5mpSNxcqitQV0iqKyHqCt7fXSunPoXr9Zy52FErebkeR7hxPYBXu7fIZRKMSMLgrDLDycRQclW/DlpgBnO1sY1sAcUUBwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5mZ3qDI4dRgFBBCkdfsa3YgeNUspT5LBimNR8K4bSz8=; b=lqYq9bFMphdikAPLesMQnn4vhN6Pqlbs3k15WH4G/cC+lIiHo/pksArYvb8ExHbNMq2xFZnfZU2PXwsKJB5PNRGsmpf1sOs+Ss9AVJzb75DlpbEwK1b9KXsKOsmBA5RS5ZtubK/QTJrD0bZn9LaBSflxR1sAC5Pht7r2ym2x/F3HKSZv7j44ir98cB+JVTSjpCWQoKQ3I6Ph9fmMp8cBHsdz5PuVU6YUFnWTDDRFa6s5qKWoJGVPfuAcocNFj1Xo7Mknwl11DDncy3lj1bKYJZWOzDxF934aVXBLwtRBFJ7w0334nAC7nbxX6Ry50pVAgMdiUBbDy7tDNjyiBdy56w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5mZ3qDI4dRgFBBCkdfsa3YgeNUspT5LBimNR8K4bSz8=; b=fonQcMI7mALGaKbeqVt9+ww+hs6oLNQ5dJ+0pVuD2qp4RAWj+6yaFAg27m+u4BTH6NgPIA5YfmTf3NaENQ1yWxvtY+OqP9bec+RXYysLxf3DvjofjIyGwrcCdji9kB9gX8M9/bd81vm/gC0/zjvTfiBfiU1Lg0VeO0xuomv08t0= Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com (2603:10a6:7:82::14) by HE1PR07MB4268.eurprd07.prod.outlook.com (2603:10a6:7:9b::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.18; Tue, 10 Nov 2020 17:16:30 +0000 Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::c99c:9978:10bb:e231]) by HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::c99c:9978:10bb:e231%3]) with mapi id 15.20.3541.015; Tue, 10 Nov 2020 17:16:30 +0000 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: "core@ietf.org" Thread-Topic: Rekeying of OSCORE Thread-Index: AQHWt4FYPBPhelkGJU+APZ3wAykSEg== Date: Tue, 10 Nov 2020 17:16:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [83.251.145.232] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f2b82a19-6276-4c15-c376-08d8859c5dbd x-ms-traffictypediagnostic: HE1PR07MB4268: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GFiYQI/CRHuJGgxwsHzD5ccbGZJHoAVyRjKe67Qp4vhAQdYH23W4ue+x3LbBuGuoNJfJ25XKs2gftMORjh6U1Z5tQxDu6FQ+mFpcN2UxYi5mMpdi3DVgiK+/R1/smOqiIq3appfDDD21pATuvaQSmW+Sv/u4s/kKCGDXfwZ0cl2APcI20oI0ZjmRb2j7UhdzuISjEFd1eYPwUxNZbBRHFvbmn2yrvC1hGqfib1h9Eft2u5JEQ3oVoi5w/IjyiPk32ljfhHP7Fz5L4rKKpejWUGC00gj2sPjC/d/3ierW3gON4uP1qITsA/c12Lf9eaExFElaHzQ8PuBxywAyt6vZX/ECTCoTrjNKyzuc5yMaXEZQvji0PrCXRXWwiafPihvLB8hk97Tjlqm38g2MrW3gFg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3674.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(7116003)(71200400001)(55016002)(5660300002)(166002)(9686003)(8936002)(6506007)(966005)(52536014)(498600001)(26005)(66476007)(64756008)(66446008)(186003)(33656002)(6916009)(2906002)(66556008)(66946007)(7696005)(86362001)(83380400001)(76116006)(3480700007)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 0c0fFN5Lo626doebSzlfzj9+9XM09onFxQDqoPEimdoUmLH5efJlZFKYorBOA2LMJDfJqF2Ckl5IfrahIKyvLWEj6lINu5+9lCjWSUkgmCabmL6ttOM1UrEWC3zh/kgGTbZppvj/q9w1KpghYKwXC5Pkx2ROv4QlOxVi6PX/0Bb3v5SBi/EziiMEoNzuys+czOQmamjeqDaxfEpv+8jw06yedUycBg5hDEUncXKuTitYS5fMqSTsao88sy/uMALLvP2q+VR73tdBKEsxMUY9ICwnBs4CQ/8+Yhq3dSD3ErKFtikqyQTmWAM6yeIJfsFCV1h8cmn7tGwQtN7WiKQC8Z2EQkaiHg9NrYuRguIa+dhQb2os2gHWp9nGJVEWiza2X6UL8bQ2oWomVf6n37zhrlq8czXFn5EYBR4ib0quASSGAX0lmF1gZFmAmehuNeOkShdtBFh2bFWGPClCgkW+wmL5q7gPn3CQ/60vl+LrhJQ7IrvT/mBLnJ65nsBgi4x8ZOqcxvGgSwTYO340CboK4pFT94SqOxlMT5WwUjeY0jBF97S0X42aRORZJZwf2j+3A5XEAYQvdFiy8GSlt82Hi0RCq+fEezelrGz0vr71j7xvrRlUdLVDP6JJlkuTAGD9Ry07SJ/Jb+5fzsaM3O1EMBMdpWqi/qquCEsThaaWukvLynAEb1bJ9XgMuwIJET09FlPIZaUUuLmTJEz7C0bWbvokzDylkROYYd+NrmspxPIK3sipBnDe8tBvD5gOVLhAmsrn77Q3ft2nBYhcGZoZyGPpEas+dlkAUbihkytQ0KTobzdKb44AFcw3l5sQ1axhGPVh+gs89InI01kZxgteLCFlyPUheuu9hlKuupQM/7FYCvJMKBkfp0YWmQDzph3os/074XlpyYCANIzLzxiaPQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1PR0702MB367468727A5B2C33F3C1ECC9F4E90HE1PR0702MB3674_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3674.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f2b82a19-6276-4c15-c376-08d8859c5dbd X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2020 17:16:30.5715 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4N+KmX138HoDmA3bKIl+vdV1/TdYfA2sWm2Mik1e39x3RN2CWB8FGPtwDA2J/4ndV4t4VADb4yFPtXyDdbly8Xl0MhJrub1ELebCC/+ohTo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4268 Archived-At: Subject: [core] Rekeying of OSCORE X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 10 Nov 2020 17:16:42 -0000 --_000_HE1PR0702MB367468727A5B2C33F3C1ECC9F4E90HE1PR0702MB3674_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, There is ongoing work in CFRG on usage limits of AEAD algorithms [1]. Thoma= s already raised the question what is the impact on OSCORE [2]. A related d= iscussion has now started om the LAKE GIthub [3]. There are at least two different aspects: 1. What is the acceptable probability for IoT? This relates to adapt the= assumptions of the CFRG document to the IoT setting. There is to my knowle= dge no activity on this aspect. 1. How can we do this rekeying for OSCORE? As discussed in [3] there may= be advantages making additions to OSCORE (rather than EDHOC) to allow reke= ying as part of OSCORE processing. Should we allocate a little time at IETF= 109 to discuss this? (Items 1 & 2 are independent. With a solution to 2, this may be used with t= he bounds of [1], potentially leading to too frequent rekeying but on the s= afe side.) G=F6ran [1] https://tools.ietf.org/html/draft-irtf-cfrg-aead-limits [2] https://mailarchive.ietf.org/arch/msg/core/rK96-Dsyhl4EmtJpOriYEENLs0g/ [3] https://github.com/lake-wg/edhoc/issues/20 --_000_HE1PR0702MB367468727A5B2C33F3C1ECC9F4E90HE1PR0702MB3674_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

All,

 

There is ongoing work in CFRG o= n usage limits of AEAD algorithms [1]. Thomas already raised the question w= hat is the impact on OSCORE [2]. A related discussion has now started om th= e LAKE GIthub [3].

 

There are at least two differen= t aspects:

  1. What is the acceptable pro= bability for IoT? This relates to adapt the assumptions of the CF= RG document to the IoT setting. There is to my knowledge no activity on thi= s aspect.<= o:p>

 

  1. How can we do this rekeying for OSCORE? As discuss= ed in [3] there may be advantages making additions to OSCORE (rather than E= DHOC) to allow rekeying as part of OSCORE processing. Should we allocate a = little time at IETF 109 to discuss this?

 =

(Items 1 & 2 are independen= t. With a solution to 2, this may be used with the bounds of [1], potential= ly leading to too frequent rekeying but on the safe side.)

 =

G=F6ran

 

 

[1] https://tools.ietf.org/html= /draft-irtf-cfrg-aead-limits

[2] https://mailarchive.ietf.org/arch/msg/core/rK96-Dsyhl4EmtJpOriYEENLs0g/=

[3] https://github.com/lake-wg/edhoc/issues/20

 

--_000_HE1PR0702MB367468727A5B2C33F3C1ECC9F4E90HE1PR0702MB3674_-- From nobody Tue Nov 10 22:58:24 2020 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 633B33A0965 for ; Tue, 10 Nov 2020 22:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.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 Vji3JfAtRjID for ; Tue, 10 Nov 2020 22:58:19 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2065.outbound.protection.outlook.com [40.107.21.65]) (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 A282B3A0964 for ; Tue, 10 Nov 2020 22:58:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c3TfMFMND3wSUKcUuuivLoXnIu1f1qooZhB+b66p+t8xcOVL0RNaxvgOBkjym8ZleOP7PggTERE4uaZUgekbmZlumb/VCuNSsSCdjmADq2p9iXwy+cMFuYOE/TMYXgPV+hekGqTEJvR5LhvvpHht+cKbAz6qUBytFqswsL8huEFK2qmlZ08dbhXNFOB+RgqoMmkQXshmPgJGCSsOhHPdEq0U3p6xY4GNf1yrWi9jBEO1GH2VaTz1O70QO406iSUfeRv3kytZqeQ32TLitoNJNa2Uk/7bbKC9t+Nc/d0f7Lo8MH/NPBIrcO/8320fiNi2kyidEBkIyViYFjkcZsRNJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L/Hac0hoyIJKnCBmXVhFsjSES87JfKmOMRw71lZhiRo=; b=gjwNEhZWOhYdXI9LMmKAR8Ah7q5wN6HskRzjomnVhrXBVC8tiEFGhRJ4PCtpYTJt9enlZJoLJ7aPrmUbNBi/KN29oxXzr+C7rIEqGGKbm8vf2glMLbxatEubEdxVReRHRvaD57gmnrDS8CQJxLOwfICxqV/J+In6ksnYo+gwKii4YchslX4uWmUvUFE5r5W4ODtBGRN7NStXe2NkUqk1nn00K1ijCXWEaZLqmOhLJlD6QxkZjY9+yMCqQBQbZdhJhhU0bmgHSAdRVS6sqwF//Ug+qPQR7/CzKBt7pYJaaQ88t3c9YIwLbGKM+9ZCH6hS1CKGza1RQ+hXAY6cUi8OrA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L/Hac0hoyIJKnCBmXVhFsjSES87JfKmOMRw71lZhiRo=; b=WZg0cGZaYqNZupP/Skjb+zNRAFz9QYqF///1MvcwoJOA2G7JJ2sj7iaUjIobIeHC2T5piwIEIlZ0I465iPruhK3fVpztrfJ7BC8h9yfdsm0GsvqP4hrUU1Fs5cMcDH923Xf+Opn6JVDmC2NIMnRLMKrAnI/FC/S0t9/mLj7f9+M= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB0668.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:fd::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Wed, 11 Nov 2020 06:58:15 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd%9]) with mapi id 15.20.3541.025; Wed, 11 Nov 2020 06:58:15 +0000 References: To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== X-Forwarded-Message-Id: Message-ID: <1394e7da-457d-8bd6-964c-b86fcc7de7de@ri.se> Date: Wed, 11 Nov 2020 07:58:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YP9Ly0DxbFN6Cklfq6TIJKAZWbnvMJin8" X-Originating-IP: [91.132.138.156] X-ClientProxiedBy: HE1PR0701CA0044.eurprd07.prod.outlook.com (2603:10a6:3:9e::12) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.1.6] (91.132.138.156) by HE1PR0701CA0044.eurprd07.prod.outlook.com (2603:10a6:3:9e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.13 via Frontend Transport; Wed, 11 Nov 2020 06:58:14 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c127d151-7599-468c-0e03-08d8860f297b X-MS-TrafficTypeDiagnostic: DB8P189MB0668: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 7gJr7o86+kKJ0f5gzD1O7natzJAPf+9EV9NWHMDt8f1Xr97ZoGhNh0N5sBiMEr83KJniYn3DHcGkRe5gcjlKvgIXYo+wnY+FZlDSnVYEa6KvecUpQTIuvc7fvxru/TJO7aSL5DKYhsJLKKuvvSGH0KWIsKCmrqzkjhRg8OrG1Pl9oY2tS7crbg7zUBYvckNNGDH5BmI0OXxC3wmmDOlyf+A2xYaaghCF7Wpp1ssdqsl8BHFMs7s3gnP1Gn5cJLziRJ12c2TjV+0pP/jrBVHLmIPYtVWvllRZYTocasOhgxYHmwo8dzHfNYE5dhsattqTLKCKNjWf8v9lBSama6ek75MuOUphIVlUta28vWVgaxIBmdA0fd+R0WXdeiHqKR/cH+rXEN4mnt9WOvv/GRmMLRezWgzHEKYyFBCXpR0IhoMRuA4l4X8Yp/kN4VLGCcjApoyRkFHtQtq/BnukgpbO+g== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(39850400004)(136003)(346002)(376002)(8676002)(31696002)(66556008)(45080400002)(86362001)(7116003)(16576012)(235185007)(5660300002)(36756003)(31686004)(6916009)(83380400001)(2906002)(966005)(478600001)(66946007)(186003)(316002)(66476007)(16526019)(21480400003)(52116002)(956004)(26005)(2616005)(8936002)(6486002)(44832011)(166002)(33964004)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: RYlICs7AsmxVLeAZdfvvFiwE5iLn4r8AeJH7FY+LIFJyelhZI6Pl3Xbv+sxa0i8RmTNubHE3LDwBu4OaWt/SKTt+rxFJeStEz7GFRPW7VPHClbzA2dvXaGSN6naEHwzW+GnpJIV9OVHiFuHb4WX3HZ4p2T6X07E70bvXHvxoSm+6p3P5US+fTZKqsykN1BgjxkmlPM2dv4OAnVVrwCFF6w+VfDVmsJhro5vsWvF/CiOjw7L1pHM/tje+vdvhrE2BUipdUefVnF5mu6ouyqQ9xc5N5j6FBUiWcCDtktXE3Sf0FlvlmRvGnpUb3DKs8FisvLiBVg4pjm2xksfsUiCxl3CVRKmaPkSPBwdtRTkMhlb1Orh5/yGXvZ9fj2W5Q8bcw9ueHnMuBfrUB0cMcFYuE191Hm53mZ+gucHCJ7p8UfZc+F0ftL1x5A9h/Pv/LnHPra11S8/FcS69Gi6IQ3T7Aog+USYB8o27dA82Qr99HWHXuSY2Kw/nY0L2MzxmtmeYPUOApUKJKxbRkpdUD74y6MYhhUJbv3T2BPjajU1mj0FuwJ/CpEYfZ+/F8NnrIQy0aiUaV4bd/wPAERftfelw5m0LJgK4P5FiaMB69kHF1c7WozCFzUeJehR2IVJ4vztBl/x0H4jOWQWBq0jFKqDDVPFK28fG0ZUFXaqb+DDjqZuT7SYBnEJe0jvkUkG2iNgx4hqdlDGKAPqTBjReqIJy5aHgrD9B5cRn7qHTGzylMabsDdm2MRKx5eLKSw7gwXnZvO5G31M9uD6oXwbn4Qz0G6XSlavFUESK5jmvQqEO8c3mHrRLO5nc3VlOEXILSMuChUqnRJbLoLXxo6lAHPCrQgPyVa9KqlUeNqnh+2sy5LUuJxVTFYyoRV9d5nisO/Atx76Kzn2uZpZ761WhmBSfYA== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: c127d151-7599-468c-0e03-08d8860f297b X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Nov 2020 06:58:15.4712 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: tjSVU4bFKUewxaHQOuxX9K/bPKoyu+1D5FHIX1E1ZEtOX+BmHuV/zjdF5I7oqNmeEqT5bQvtaymAP6u1EyOFpQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0668 Archived-At: Subject: [core] Fwd: Requesting NomCom feedback X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 11 Nov 2020 06:58:23 -0000 --YP9Ly0DxbFN6Cklfq6TIJKAZWbnvMJin8 Content-Type: multipart/mixed; boundary="cLXQPkzt5sG8AQ7w3vwqO7h4ArJXJkRAw" --cLXQPkzt5sG8AQ7w3vwqO7h4ArJXJkRAw Content-Type: multipart/alternative; boundary="------------AAEF8EDF4EE0A2A71C17355B" Content-Language: en-US This is a multi-part message in MIME format. --------------AAEF8EDF4EE0A2A71C17355B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all, Please consider to provide your feedback to NomCom. Best, /Marco -------- Forwarded Message -------- Subject: Requesting NomCom feedback Date: Wed, 11 Nov 2020 00:12:06 +0000 From: STARK, BARBARA H To: 'WG Chairs' Hi WG Chairs, First: Thanks for your help in getting volunteers for NomCom and getting nominees. Your emails to your WGs have been priceless for making the NomCom process work. My last request of you is for help with getting feedback. We've heard from the usual suspects. I really want to hear from more of the community, and the ietf and Announcement lists just don't seem to reach enough people. Below is the text I just sent out to the Announcement and ietf lists. Feel free to use this or invent your own shorter version. Thx, Barbara ---------------------------- NomCom is considering nominees for AD positions, IETF Chair, IAB, LLC Board, and IETF Trust. We need more input from the community both on specific nominees and on over-arching topics regarding what the community wants from these specific groups and wants from its leadership in general. We need *your* input. ** Deadline for community feedback is Friday November 20. ** We've paid attention to discussions on the ietf list. Issues raised there have been brought up in interviews. We've also asked questions of nominees based on feedback received, and based on the "Topics" that people said were important. We're listening to you. But most of the input to date has come from a few consistently vocal people. We need to hear from more of you. I scheduled our office hours during the 2 weeks before next week's IETF, because IETF week is so busy. We have one more left (18:00-19:00 UTC November 11). No-one but NomCom members showed up for our first 3. =E2=98= =B9 If there is demand for more office hours, I'll schedule them; but this really doesn't seem to be the preferred format for input. Most input is coming in as either - email to nomcom20@ietf.org - feedback on https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fnomcom%2F2020%2Ffeedback%2F&data=3D04%7C01%7Cmarco.= tiloca%40ri.se%7C2339c02241bb4709e36308d885d6a912%7C5a9809cf0bcb413a838a0= 9ecc40cc9e8%7C0%7C0%7C637406504295335864%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi= MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sda= ta=3Dpwso8JsorJYhAQjdOJXRDBQb63gl5DqzTF2CO5wY7Rg%3D&reserved=3D0 On the feedback page, the specific nominees are all listed at the top. General Topics are at the bottom. We pay attention to all the comments we get through these channels. I'll also try to hang out in Gather.Town during IETF breaks next week. I'm not going to have a specific NomCom area in Gather.Town, because it was really lonely hanging out there during IETF 108. But please feel free to hunt me down and bend my ear -- on NomCom issues or just to chat. I miss seeing all of y'all! Barbara Barbara Stark NomCom 2020 Chair --------------AAEF8EDF4EE0A2A71C17355B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all,

Please consider to provide your feedback to NomCom.

Best,
/Marco


-------- Forwarded Message --------
Sub= ject: Requesting NomCom feedback
Dat= e: Wed, 11 Nov 2020 00:12:06 +0000
Fro= m: STARK, BARBARA H <bs7652@att.com>
To:= 'WG Chairs' <wgchairs@ietf.org>


Hi WG Chairs,
First: Thanks for your help in getting volunteers for NomCom and getting nominees. Your emails to your WGs have been priceless for making the NomCom process work. My last request of you is for help with getting feedback. We've heard from the usual suspects. I really want to hear from more of the community, and the ietf and Announcement lists just don't seem to reach enough people.

Below is the text I just sent out to the Announcement and ietf lists. Feel free to use this or invent your own shorter version. Thx,
Barbara
----------------------------
NomCom is considering nominees for AD positions, IETF Chair, IAB, LLC Board, and IETF Trust. We need more input from the community both on specific nominees and on over-arching topics regarding what the community wants from these specific groups and wants from its leadership in general. We need *your* input.

** Deadline for community feedback is Friday November 20. **

We've paid attention to discussions on the ietf list. Issues raised there have been brought up in interviews.

We've also asked questions of nominees based on feedback received, and based on the "Topics" that people said were important.
We're listening to you.
But most of the input to date has come from a few consistently vocal people. We need to hear from more of you.

I scheduled our office hours during the 2 weeks before next week's IETF, because IETF week is so busy. We have one more left (18:00-19:00 UTC November 11). No-one but NomCom members showed up for our first 3. =E2=98=B9 If there is demand for more office hours= , I'll schedule them; but this really doesn't seem to be the preferred format for input.

Most input is coming in as either - email to nomcom20@ietf.org - feedback on https://eur02.safelin= ks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fnom= com%2F2020%2Ffeedback%2F&amp;data=3D04%7C01%7Cmarco.tiloca%40ri.se%7C= 2339c02241bb4709e36308d885d6a912%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7= C0%7C637406504295335864%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI= joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3Dpwso8Jso= rJYhAQjdOJXRDBQb63gl5DqzTF2CO5wY7Rg%3D&amp;reserved=3D0
On the feedback page, the specific nominees are all listed at the top. General Topics are at the bottom.
We pay attention to all the comments we get through these channels.

I'll also try to hang out in Gather.Town during IETF breaks next week. I'm not going to have a specific NomCom area in Gather.Town, because it was really lonely hanging out there during IETF 108.
= But please feel free to hunt me down and bend my ear -- on NomCom issues or just to chat.
I miss seeing all of y'all!
Barbara

Barbara Stark
NomCom 2020 Chair




--------------AAEF8EDF4EE0A2A71C17355B-- --cLXQPkzt5sG8AQ7w3vwqO7h4ArJXJkRAw-- --YP9Ly0DxbFN6Cklfq6TIJKAZWbnvMJin8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl+ri4UACgkQ7iZktA5Y 2kPU9gf/ZthOu+IwUqA+arC20eNuOyI0GF/8xtGmR8gHgPjqZ+qlkmAcLGnbFudC Qe9pTLRtozkSbxz9D4FBvZsl614dT9dSDfTchHfbqr1xsb+iRlJ1JKRlyGq2Y9DD Cq9ImfjxcAp48RovpGhXMNvKWhriEVmP90MjSXu+JFHj3pQeZsjgdYqnxKxd8ati s14FgUGn/GniAfRtWihWAd4tf56WC+S/SB9MR7bYp8+gLU1scdS1hQMIViikYbOe rbQJrZ/qJs8NUHI07G0xwtl0M7fRP0/lruZEE2QpusREpvNmvkadilGLL+g39Xau vN5paIwJhHAz7Cciwb2cQ+ypZDNn2w== =v0Lr -----END PGP SIGNATURE----- --YP9Ly0DxbFN6Cklfq6TIJKAZWbnvMJin8-- From nobody Wed Nov 11 06:28:44 2020 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 973B93A0E1A for ; Wed, 11 Nov 2020 06:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.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 ShqId2Rre1_X for ; Wed, 11 Nov 2020 06:28:39 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2052.outbound.protection.outlook.com [40.107.22.52]) (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 333FD3A0E12 for ; Wed, 11 Nov 2020 06:28:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B2cnCd9I2OjFbiqHza9TAJKAH/7LCGHsm9tjeUDBbt7Atd2jlMllsU18ljRgJ+jRg+eyUlKtnuSO9CdPJtw2QaJ874Lgn5XARQ4tt1XRDPlV5Y8sY8TDB8ZVirnctkXxXQz7DUQLb+sfI6Ferv/7aK0s5CEHjO1xB+6KfXXDpO8OQ6PeJZo/b4GQc3W08o/gpwlKdj6tvUFJrk4MV13Ld/OUKWn1H6KfhVPw+GFmFFsP2y+ez7A2h5vgajK+g5f1Se5uSfjpZkEqkHVcMWrFIsm4zZV/7BPaEYei6koyNEbTTycJch3y5DogiV3KpmOs8RtbnBrz4Wvp9IvPF0X31Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k3yICBxGPH1h8k0wWGLp4tm0fOUyctY2qJkLjuAyBTg=; b=VzNhIc0qzZO0QUwftKqAGcvll54EJEfg4uQfnWV+rUz5kiwL0i9IB0BycxuGHXaIIHKFbemCoOuMe7kL/11/0/ys7ggKqEi3am5fms9iSGogUz+9EiJfxkYtdmxkgUJtYDQNKHPgvuiqMCHjgpqUhw4EC05effx6/rkvaCge9qIeM8dBUMv1YTrKQYQXNlOuFNZxYqluWzuXSlxFKEsNrcBq+VW2pxyovat83fJNWLHKF7aenurlziHP9J//QIR7A+X+MOt//ETAnArpiVhCvuDsdtWJvKrgBg8rnbzu+l8nVW7o/nGjv1F1K/nCWz4JK2N41v5LZRw3QglHnHgqmA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k3yICBxGPH1h8k0wWGLp4tm0fOUyctY2qJkLjuAyBTg=; b=Sv3dyMmXzhKKsv9VFcOCNGYdmMVOPPXViavs7X+30Yl9Zn9UAFWpUWviVXG6os7BJP5dsSHXR+8izIlvSIvlv5WLbyg2NEhFaT2ap8iDeCNbkrMUyldnx7Ex06802Px3zGUqOgyZTG6S4xvD06mOPGHE/bJshkA7fkX0MpLtw6w= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB0716.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:12f::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Wed, 11 Nov 2020 14:28:33 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd%9]) with mapi id 15.20.3541.025; Wed, 11 Nov 2020 14:28:33 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: <12eb3c53-43ef-8a07-39fd-c62efcd35dbf@ri.se> Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: Date: Wed, 11 Nov 2020 15:28:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <12eb3c53-43ef-8a07-39fd-c62efcd35dbf@ri.se> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ewi3iNoc0xa8D5MB4LIqBSKFYFSbq2vfA" X-Originating-IP: [91.132.138.156] X-ClientProxiedBy: HE1P190CA0036.EURP190.PROD.OUTLOOK.COM (2603:10a6:7:52::25) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.1.6] (91.132.138.156) by HE1P190CA0036.EURP190.PROD.OUTLOOK.COM (2603:10a6:7:52::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21 via Frontend Transport; Wed, 11 Nov 2020 14:28:33 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a309188f-d908-411a-e5be-08d8864e11a3 X-MS-TrafficTypeDiagnostic: DB8P189MB0716: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: HVd0MWAMJr8vBxQ0pVkrBCUpXGOv0sp2O4oxAY/99EzpkRyiG1rXAOng2tE4Ub5amBUuc+1d7eXoS/dqX9pmAMoNzMQuxQQ2llnY3vvmM9DSBtvJUjobAQq+t7+PE+jvlz3cgry+POe0Zj2PsC3CCID/ZFBfCDShn8O8IUnln9WlNqTrseMl0KyOx7Wv3QmHkfcxBhDd7ORm+Gi88MGqCj0YX0dYbH5vHcNfbO9IRmJ6vZoaqywWDumt7TjFwwv/vSkedFaIxlEEioKj515boqQUKdubN/fsBBQwU6j/NIfUsy0Kml9EUu4ljq6zlWPwy0VUqkLfKgzuqJc5wRH+/jKmCDiyA76dBk82GR07OMtCBTZopPM+/Q6aRUYkmXV+FwfNHUI7xckI/Hwz/cyerxCl4uNiroP9VjgYS52jivs0avo4bW5o0eBK45FtrRxTk/SOIYkcrND/1PKHLwLz+g== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(39860400002)(366004)(136003)(396003)(376002)(83380400001)(31686004)(6916009)(44832011)(6486002)(66574015)(478600001)(5660300002)(186003)(16526019)(26005)(33964004)(53546011)(52116002)(2616005)(956004)(8676002)(966005)(66556008)(66476007)(66946007)(8936002)(316002)(2906002)(36756003)(16576012)(235185007)(6666004)(86362001)(31696002)(21480400003)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: eJBcQshvzwcNdZgp7ydHDVIgTl58rp3SeLbClDJPpCM1wViLPIZTRSHEe8nsXHrvMxXaGZzLbPLckErss+HvsIrwB6fYlNwqAzsSIAxFAt5X49Jghapomzyg4aRn6EwVbI2b8PkkJr3zbjS7pmxdpFLsOY+YuwbqikUtFDT30b6iwTa00MR7e3v9z1VmYcPDHWEhC8R+R/y6rugj5pmyTDocePW0LGff6yTVrLNNrSqFxHowF8qonDPGCEwALUzQvVVL2hcnTbreh2712cQ7Kw/bhdvmdAbMuwxjGjtxKUgHGHeXDYVcSwNkFlZrxInoDiW4VSjeBL+Hb6HiCJI9aR1Tsv7HG2gQuwf3Yh/tidx+NA7Q7GhSt5TkWievArxl6v+x3vabUqJrJTYUnOs/HBbUm82KzJmzEP5A8nkEaWknHx1hEy/rRd1FKGETbIXmcS3S1CbXAiWqgN26iaxC/74uw6dAALxLh9oe9zOgGGIqmEVjgKLgtUhfg4kx7MKCzOEu3lX+DHzlc2JJLbLIrNP4po6uUVkJ7idzqTISjTjUxzea4/zCpi2jVVd+5HIG8XkHtyfhwnp5dhKKQHOQAZVMqSjszGIvL0X2lL7yU6in+VuEmpEKAAE6vJNLEgOu7VDdKKYEWxvtKjbIHlbhbyzLrU7VcbdHDUiAT8RT65vOLdpN4nnRuet3cCofCxtd73SdJ7KO6D0EFmVxoJ4t6rkuHHjrlda6dEG7P/hg1gAeok0RCqLeFt/52TArgB0lc154a52I2IxlDBV20H9uY3KsMM4CKgAyNeIppbcvxhnSX41vhgk64zOeU8d1UuPpIXMFUQGQXkqGxZqeCHLgnXLRrPGaZNPRiqcUKCPh+GmiCaKDpohMV/h3ai7Y3r1CeWQQrRBxKxMVSqfiajyxFA== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: a309188f-d908-411a-e5be-08d8864e11a3 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Nov 2020 14:28:33.5923 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: aupzUXSrBzH/WMXEFkNUB4PJ/SzhXnEdi9RMJx0aGzGqBiKeE/c7VDjeGu8ADovXec06d/y0Txozhyww6Rgg1Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0716 Archived-At: Subject: Re: [core] CoRE Agenda for IETF 109 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 11 Nov 2020 14:28:43 -0000 --ewi3iNoc0xa8D5MB4LIqBSKFYFSbq2vfA Content-Type: multipart/mixed; boundary="S5lRrtf4eJkGIUr8ccUsb3LNeFFJ6kfGk" --S5lRrtf4eJkGIUr8ccUsb3LNeFFJ6kfGk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Some more information for the presenters. Please, upload your presentations on the datatracker [1], no later than: * Monday, 16th of November at 12:00 UTC --- For the Tuesday session * Thursday, 19th of November at 12:00 UTC --- For the Friday session As announced before, the agenda for the two sessions is available at [1].= Thanks, Marco and Jaime [1] https://datatracker.ietf.org/meeting/109/session/core On 2020-11-04 18:40, Marco Tiloca wrote: > Dear all, > > A drafted agenda based on what has been submitted and on recently > ongoing activities is available at: > > [Day1] > https://datatracker.ietf.org/doc/agenda-109-core-sessb/ > > [Day2] > https://datatracker.ietf.org/doc/agenda-109-core-sessa/ > > > Those who want to run slots, please: > > =E2=80=94 check the objectives we have guessed, or provide alternative = ones > =E2=80=94 check that the estimated time for the slot is ok > =E2=80=94 confirm who should run which slot, or provide an alternative > =E2=80=94 send a mail with this information to core-chairs@ietf.org > > Please, come back to us also if you think there should be a slot on a > topic/document which is not included. > > Best, > Marco and Jaime > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --S5lRrtf4eJkGIUr8ccUsb3LNeFFJ6kfGk-- --ewi3iNoc0xa8D5MB4LIqBSKFYFSbq2vfA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl+r9QoACgkQ7iZktA5Y 2kOVYQgAp/jRrKRrH+LCS7xaiQCcUFo1jJ9Ix3AqcjW8TjTfYcRM7vzGrWOww7Wg 69bCBy6iW7yJoEzRZjE9dsSQ43z8/oCUG5uuje+aMGzVy47leCPT3gi36V1QKxLV GTeQRorUnZmzOV8j+qemvivNFZb1MzVrwnetq9T/fdkFeGGQs+4WAZD3UrrKiRH3 XC5kP6PIjjhTtrnxBs7BJ+nI/+uNIWlGtktxj3oURXR+UnQx9yUS3K1S0KuhuU+s s4MLb3pFQjeLcKZ7cabo2XR5D5Lb/Fn3msTLeGxnoAzN0H3YlF0xed6/ssEn4rNx UvJgJ0IpZRRd1aF+Ra7Spvn9gZR44w== =buHe -----END PGP SIGNATURE----- --ewi3iNoc0xa8D5MB4LIqBSKFYFSbq2vfA-- From nobody Wed Nov 11 06:37:38 2020 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 B9D223A07F9; Wed, 11 Nov 2020 06:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.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 CxrFVNzOt4GM; Wed, 11 Nov 2020 06:37:34 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2043.outbound.protection.outlook.com [40.107.22.43]) (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 A75E93A0BAD; Wed, 11 Nov 2020 06:37:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mqCqaY6ciEzGQ7vDfZeRazBALFIm4wNTjq7LtR9fU5Hly7KUGMTMf0WP2siazxd59N0pTI+cD/L7oq6mHMo5uEGfoBmpl2n9rW/aAf+NzD86byo8lcmmBprRhgaBWK/Q0alobbuutjsEGAk/nmc3qj3IOqGE2ZezheWFzv1t6u8ll0yG9ZWGtRmjkzPkgDMHyecTnM+G9DTrYeND7U9Js/MY5sTXNXTFAGuHx8GBO0sOBYKAIJvuwMk9SFmFg/yn3LYT6RjBFNWA0sMceB5oWpltX1LUrmxWyTy/yF5KfVsz+MT9lG3uPZExQ03D5DmLKKePDrwoQxv95MUiE1ngVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uFihGqX3Ispm+F+nBmZwW4QRPC56pE5NK/4mlysG/nI=; b=WwWyNWDtTZol0y7uEHq0qGokUuuKY4tOaWcpkc4FmvnNlgeKyo37l45BAkRexiZkgO5f81hw0+PaTOuFP9aAXnuWhuIAq7eXWQUEp2gKzkXaVL+fROPVYjtjv4cRMOm8DzIvg6ORxvSZ9B3kmfbVSUcC++zDP9FvgJjxgr02FCi6CxWmmzwFM0akRuENYABRcQgqM70vynLZ5zl4WsTA4CiUv46tPjaYTFIezsHlDkmJ6vciHAZpzNpwAALbnt97Z02FAcgXb4ujSBenVZUUMTFKvPT8mcuJhxtdc2gFHYeaT5HqgIA78N3Jq7r34QazfUgBcUj7W3rJMeN5tW11Tg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uFihGqX3Ispm+F+nBmZwW4QRPC56pE5NK/4mlysG/nI=; b=PnsjkLPpbhc9suJMA6FanxcU7OgI71eEW/mk/FZXWGzjDIarmeZ3ianKMs9LfvZhHc4KkMG4GRW6LyeDhDmAILmI0Xg6bePKtbpZ7mnF1qyE+tF4U+hccAJ/lVSBG33bRnhCirKvdrMea3Y3kn4ihjEir6RstHXWLzH7NoXpD9w= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB0951.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:164::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Wed, 11 Nov 2020 14:37:31 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd%9]) with mapi id 15.20.3541.025; Wed, 11 Nov 2020 14:37:31 +0000 To: "core@ietf.org WG (core@ietf.org)" Cc: "core-chairs@ietf.org" From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: Date: Wed, 11 Nov 2020 15:37:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="eeAXnjqrIvuuLyf4MKaWUK6ZMqxZPZGE2" X-Originating-IP: [91.132.138.156] X-ClientProxiedBy: HE1PR09CA0055.eurprd09.prod.outlook.com (2603:10a6:7:3c::23) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.1.6] (91.132.138.156) by HE1PR09CA0055.eurprd09.prod.outlook.com (2603:10a6:7:3c::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21 via Frontend Transport; Wed, 11 Nov 2020 14:37:30 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ee95584e-c061-4066-461b-08d8864f5202 X-MS-TrafficTypeDiagnostic: DB8P189MB0951: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 0YPWRa3nJxHKwwP5d5+9so73HBOFHgTuGjPRRfJOGQlJk8YWLfPKr1xbUiodxCj0P3SEhCHRrovl7Kn2RIEXVsVkdm1bklDMS/5RtJdXMkh+8PTDCW5vT5LiFELT1OcdVL+5SvLyAAFluw3JNvztO9D7DQ3UmG+MvBxwKmt+doihnhJfSCvQjIt6s7lWvtYxpTSXvazoSm49eGcBn68aDoTDWFS9g78wX1tYiwFOYzlV6YFbFvEmpu3oGkzxuAC59iJ7zzrfJPquH2gz+IwJfg3QbkI1yX/D8vG94NoHpEO8b8QOcDn7+7iDwgWaOTzN2Ig8KkG0nlcuAwuSPZps5hcfVy7/2/8DPmyJMH4uGEBPysD2+30G1zuYqqS1R74USP3/FLWj9fn1hqs7T37905chE4GYYCvGv53OhjnwR/KJWXqkfyczrqUuSOWlyFOFg890BhbBkeBlHC28kZ6qFA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(39860400002)(136003)(366004)(346002)(396003)(33964004)(52116002)(8936002)(83380400001)(6916009)(26005)(5660300002)(16576012)(956004)(2616005)(16526019)(8676002)(31686004)(66574015)(966005)(36756003)(235185007)(86362001)(6486002)(450100002)(66476007)(2906002)(21480400003)(66556008)(31696002)(478600001)(66946007)(44832011)(4326008)(186003)(316002)(6666004)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: osN9aTFJnkyMW1wWgXkE2QDpZHZkaLD246B11zCJ2141KFim0KkUmLMQZl/JKhykE85IcDScBh1hYdgen7Hvv1kLTFZ1E2DuP4HleB1tSXF6Ou2CES1VLREDuvoBmlSPZhbwJQqQd16R3Gp50Aw5J4txq3KECKkSzkFe8G2R0mTUQZdIVqVOw9NlYn3SL7+psqPbkqBMg3HIsOoJHRKOOE+ferPKPhvXFeuAVvV3yg8amtvcEVX3Qd9yetssUAhTgzWXVfLmQEvyPem3OeAyin2AD7Rxm5r1vI3N7WwEXx6KKA+dbLM1NMxeNDleQUB1Xrm7Q9Cjwi+WrxCxdMzdPR32qNaI/RBOMffJn07FoovnnV3mr5RS/bLXnc9WSL7MEPMa4UzzxQIh2nw6x4+dsCvZbGlprUlDFbITvINwGRgPmvH+lS4gCQWOaecE0RHVb4Ghi0JcN33xS9NBipEYo7qzyjNLwHUcqc4w/e0nnDVLOqP5NLKV6vYtvKkaaHrP365YrbMsgR/oY3WmQOj+0Jz04qho7eRnnffDy9T+h2wz5r5D1jsjBhZfYAxbT7ABOApeIUD/W7I6CB3OsJM7lM0+uId2sIHt8S1dyXpZ5ywaadrA2cg7CmX94Nkm6tU8UZ/H5JdspWYy8xBoTD9g3TfwezlhA+uFDLxjMeb/1qFRmWVmVr1L6l2YSCPUThO9KTliwMSW77QLfHXpk2j4GZX2x/hFI6L6oIcNOn3YX5NfZ6XzGRewo9V9DrNycuzLiDiJlUdXfD2LX5cx3H+AlQsO5C+UjYxVIWNjweuQVUslhgfaiXP81Ybz1q3pUpFVQYruFrWzA9N1m+VLaSkav4S3+M1kZHp8H0+RPQj/QAM6N3ZHTBHYdd/eeQZDwrx0wu3CA0TyDs/nA4zEwzpeXw== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: ee95584e-c061-4066-461b-08d8864f5202 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Nov 2020 14:37:31.0130 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: B/YAcSZvFqbedLMrj/FBnjXtmwRny9r193VojqUVWWB1mh/3vs3WhFg53ASR91opdhorKN312r1pKoOCJI/F0w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0951 Archived-At: Subject: [core] IETF 109 - Minute takers and Jabber scribe X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 11 Nov 2020 14:37:37 -0000 --eeAXnjqrIvuuLyf4MKaWUK6ZMqxZPZGE2 Content-Type: multipart/mixed; boundary="PX6KtqfuxRXemMO9IgmRcCK1uI77I0v0l" --PX6KtqfuxRXemMO9IgmRcCK1uI77I0v0l Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, This is a call for volunteers to help taking minutes and be Jabber scribe during the CoRE sessions on Tuesday [1] and Friday [2] next week. If you would like to volunteer, please send a mail to core-chairs@ietf.org (in CC). Thank you so much in advance! Best, Marco and Jaime [1] https://datatracker.ietf.org/doc/agenda-109-core-sessb/ [2] https://datatracker.ietf.org/doc/agenda-109-core-sessa/ --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --PX6KtqfuxRXemMO9IgmRcCK1uI77I0v0l-- --eeAXnjqrIvuuLyf4MKaWUK6ZMqxZPZGE2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl+r9yMACgkQ7iZktA5Y 2kPyjAf/YudKVr/9iuNLlb1/nhHEJLNikfXzDEIjUY+8G179dO2bqvOQ6m8lg1GG /6tQ34zxHVT0ath1lFUO5xp4bAiyE6w3Ten6OGW0BCxKdIHlV5nisrcPbilcjanH MB0O3LsADpK9uPcfpDPvayRwgqPUbxbiNSM85+Zr10aoonEObKe3AiQMIVQaSeTc jDHxi6BpxITh6E5o+Ef7i/Nh4sQaJGy5hQrda1+uhYcScmgqlabbvcHM4VC7B8QT 5EsoAonwGuEkklRAf8BaP6p+v8NeVuCqH3Hh/IPLNvmwnwRbugRDnp78y9PLaA6f gr5Jqs7OxNqKa4tfMUn2UHb2iyvUmQ== =urEi -----END PGP SIGNATURE----- --eeAXnjqrIvuuLyf4MKaWUK6ZMqxZPZGE2-- From nobody Thu Nov 12 07:57:19 2020 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 CBDBF3A1152 for ; Thu, 12 Nov 2020 07:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=landisgyr.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 Gh4cOWlkXOGj for ; Thu, 12 Nov 2020 07:57:16 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40091.outbound.protection.outlook.com [40.107.4.91]) (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 38DF53A1361 for ; Thu, 12 Nov 2020 07:57:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FUdfGAIYrbeQxXgPRbKYiNc9J9HAxqE0jxMhu8dRHfQvV/bTFhf2ca/wCWRownHXm0bD2ffVBX4jlOnjlu3aJxMslegEuPiWj6QyOAx+f07g+0bW3WEKRPj2DdXUhDMfieLbwD8uY0v6J8WYJdcy4Fa6rtzTzBeeyjRv5EuhfCFULR/rTz7CjTenR/x/212uFe50NdSRsbBFgAXwtYB9rsKRLd0l48/rhy8vgQqsCrVNtwCj0GqYLu4qlREd1RFgZzO+lQBDZN8O7t8yw+TiZv7LeMK4gDw8dZIS6Fctvpre7Q7wWsvEUvwY+ichxDakYdMNaKfyzKXZg04OZCYvoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U70+QWMuUMPPrvDHSENlKO96HSes4NQeYgmdIXqN7Tg=; b=YpfmA9EO5eAxcyVZ/R7BDWEHHkou5+URGvq6mCky+YmFA7Gx4zXTxehyuK523AjhOxrDY+vThsPUKdhJ4L55hbRscZDIc0WeDl3zA3evhEbJBgBIFV0DzUFln004mX4R4I7xUOkj16vo9tCqT7JcG47a1JTwQONyksdxDaAagknjvZp6cHaxFusJsIrMSx6mZ5hPl7HWqO+TeWCGrnMILC8qClSCndkjTOHt4b9eZkIwo5055BnLcLq5oXPYBOWaE9T4ve6E2rjVelShmbj3ue+BkMIKxO3wmCu2xzvlNkzCCeRfd/y5tGfO20xbb1a/JHdMarPHXFj1JpUPYLY9/g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=landisgyr.com; dmarc=pass action=none header.from=landisgyr.com; dkim=pass header.d=landisgyr.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=landisgyr.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U70+QWMuUMPPrvDHSENlKO96HSes4NQeYgmdIXqN7Tg=; b=qbZdywrq2e7Hjgc5Tk4VofUHWkJaaHjakzOLK6ZK6wRGyCueF8RlGuje+gTHhxj7tHiQ7lKx2iV9sHZMoKzjvOuSWCi1d1dq7/ZvIyguFk2l5y5/jSOmowsbnsx4N1hk7uVfjMUQwQAbU9QF7lf/xxC8Eb9O6+lrXW8L5tLXNu4= Received: from AM6PR0102MB3494.eurprd01.prod.exchangelabs.com (2603:10a6:209:26::26) by AM6PR01MB4438.eurprd01.prod.exchangelabs.com (2603:10a6:20b:3f::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.27; Thu, 12 Nov 2020 15:57:13 +0000 Received: from AM6PR0102MB3494.eurprd01.prod.exchangelabs.com ([fe80::e123:c5a0:c836:519f]) by AM6PR0102MB3494.eurprd01.prod.exchangelabs.com ([fe80::e123:c5a0:c836:519f%5]) with mapi id 15.20.3499.032; Thu, 12 Nov 2020 15:57:13 +0000 From: "Turner, Randy" To: "core@ietf.org WG" Thread-Topic: CoAP - HTTP proxies Thread-Index: Ada5CpldoJFysbEKQ4GMv/OUtyIXsw== Date: Thu, 12 Nov 2020 15:57:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_ActionId=5f3fde0f-7e7a-4960-bcfa-c30f3a5935bd; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_ContentBits=0; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_Enabled=true; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_Method=Standard; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_Name=724d29b2-602f-4b77-ba15-b7b42511c7c5; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_SetDate=2020-11-12T15:43:21Z; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_SiteId=ee2cd48b-958f-4be4-9852-b8f104c001b9; authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=landisgyr.com; x-originating-ip: [24.98.201.185] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 787811b6-a93d-443c-8d43-08d887239f2e x-ms-traffictypediagnostic: AM6PR01MB4438: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2803; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /ytgxp6Kzcst6oCXhQcz4bj/Yf/vNskS4zCxio19fspVd627R1LGOUX/T51zC4P7+dfUEXFM2CYdi0dPcn0b7+TdWDNUJoCXqDEnWaqCRMEfGs6JOQUebib1yoZiEFhtd2y2Q2leOCveKTXSSQ05ykehyXmM8NuAkqyupoiyaTIOkf7BNdk4S7OoF2GHrXYLRGA4Mf64IFfI60y3tfYUZg4vR5UauX/KcYwnbfegK/WiQOV9GpV9CfRv2s2+nadZbYTLpUycxYguxA4lCXiFlIyTFvUUyg7TOAf026KRkLLdBv/Z/YpxrS3b5iGCbndcYSXawMtv41XSvyfI+tfigQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR0102MB3494.eurprd01.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(346002)(136003)(396003)(39850400004)(55016002)(478600001)(66446008)(8676002)(52536014)(86362001)(6916009)(66476007)(66556008)(66946007)(71200400001)(6506007)(5660300002)(4744005)(64756008)(9686003)(26005)(33656002)(7696005)(316002)(2906002)(8936002)(76116006)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: Ce34VdUwuRBx0DAQ1bmIsL8B4IgbzEiZ1JqCid6K/eA7+WhQmPYW8AY7uzObPdYLJI9iSa7hTtuouIvXu7BK3ge8ss7s5dy14+1TSkPZFDB6url6Tw0MAeXnvqKLgB+n9OlK5/mxl1bvWLOuKiKWlleESlVF2Ke3OpCei4WKZJWQ77oBS3xty4PeM7AGUDQRg0X9V+AiBIRanCCPnBgVXFhJOVggsy3lLUUCJvFwJOh3DaZQeNu/VBZX6Jk9geBKuvG8YbzksRkMjnxnYrxMXatknGFIvMsiMD4vdc5/G/ksNZV4Rpb/h2A7gzOPgWEASgyvwfn9e7DdXqCNDRkfQeBCCzm6fRZxK9fWNcb0SxcmeMZHzl70BpnNpM5jGISr4STcRPaEVa3ez6bW5c6uTpkBp+HdSSwFHkebWPm/YIKjpAmDR5ILfkEBL5UIjGlpiu0yVhVUK/fOOmYOPsX5JeS+ubxh/qGBvOB+lq9H4Z+kgjKhtjkWyvPrum0yLNOuNioiFxtEBMyjfWrVxieH28BXsX8WXaMLNA0BqDlaPRjPmXm75cIUHB/AKxMt6rjadztcW3Cj26N/KPXMUbzgM6b2fT3j6o0bL6FNY8R1k4X7T9hbUPgMqSV9K0I13CQeY2XRANJgNrMoKsV0kZCijA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR0102MB3494682CA394C6212C00561F80E70AM6PR0102MB3494_" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM6PR0102MB3494.eurprd01.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 787811b6-a93d-443c-8d43-08d887239f2e X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2020 15:57:13.6250 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Nn/wzD7SmbWln+oe3ta3UlHIae4isdE1JC90tyS1yoCkUdPfV5jq5JZGlIhW0BMH918m8KzugteBRsP6a7jtwjtr4Ca6/SU49oDycvB12as= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR01MB4438 Archived-At: Subject: [core] CoAP - HTTP proxies X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 12 Nov 2020 15:57:18 -0000 --_000_AM6PR0102MB3494682CA394C6212C00561F80E70AM6PR0102MB3494_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI All, RFC 7252 provides a good description regarding CoAP-to-HTTP proxy (forward,= reverse) operation and other documents detail some guidelines for doing th= is in an actual deployment. In reading the EST-over-COAP(s) document, the text talks about a "registrar= " (section 6) that performs proxy-like operations. However, section 6 refr= ains from mentioning anything regarding the proxy operation described in RF= C 7252. Does this imply that if I want to deploy a generic CoAP-to-HTTP proxy betwe= en my constrained and non-constrained networks, AND I want to support an ES= T-over-CoAP registrar, that I actually need "2" proxies ? Or can I use my = generic CoAP to HTTP proxy to solve both generic CoAP to HTTP proxy and EST= -over-CoAP(s) registrar functions ? Understanding that if I want "1" proxy= to do both, I may have to have special case code in my generic proxy to ha= ndle EST-over-COAP(s) specific behavior Thanks, Randy --_000_AM6PR0102MB3494682CA394C6212C00561F80E70AM6PR0102MB3494_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HI All,

 

RFC 7252 provides a good description regarding CoAP-= to-HTTP proxy (forward, reverse) operation and other documents detail some = guidelines for doing this in an actual deployment.

 

In reading the EST-over-COAP(s) document, the text t= alks about a “registrar” (section 6) that performs proxy-like o= perations.  However, section 6 refrains from mentioning anything regar= ding the proxy operation described in RFC 7252.

 

Does this imply that if I want to deploy a generic C= oAP-to-HTTP proxy between my constrained and non-constrained networks, AND = I want to support an EST-over-CoAP registrar, that I actually need “2= ” proxies ?  Or can I use my generic CoAP to HTTP proxy to solve both generic CoAP to HTTP proxy and EST-over-CoAP(s= ) registrar functions ?  Understanding that if I want “1” = proxy to do both, I may have to have special case code in my generic proxy = to handle EST-over-COAP(s) specific behavior

 

Thanks,

Randy

--_000_AM6PR0102MB3494682CA394C6212C00561F80E70AM6PR0102MB3494_-- From nobody Sun Nov 15 08:49:17 2020 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 0C38A3A091C; Sun, 15 Nov 2020 08:49:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.22.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <160545895600.10530.12578951934053263693@ietfa.amsl.com> Date: Sun, 15 Nov 2020 08:49:16 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-versions-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 16:49:16 -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 WG of the IETF. Title : SenML Features and Versions Author : Carsten Bormann Filename : draft-ietf-core-senml-versions-01.txt Pages : 6 Date : 2020-11-15 Abstract: This short document updates RFC 8428, Sensor Measurement Lists (SenML), by specifying the use of independently selectable "SenML Features" and mapping them to SenML version numbers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-senml-versions-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-versions-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 15 08:53:16 2020 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 E3BED3A097F for ; Sun, 15 Nov 2020 08:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYn0lYvzeagZ for ; Sun, 15 Nov 2020 08:53:13 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62FCC3A0977 for ; Sun, 15 Nov 2020 08:53:13 -0800 (PST) Received: from [192.168.217.120] (p548dcc60.dip0.t-ipconnect.de [84.141.204.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4CYyvB565XzyYN; Sun, 15 Nov 2020 17:53:10 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <160545895600.10530.12578951934053263693@ietfa.amsl.com> Date: Sun, 15 Nov 2020 17:53:10 +0100 X-Mao-Original-Outgoing-Id: 627151990.232716-f601cad3a628c1ae700947d4b71fd565 Content-Transfer-Encoding: quoted-printable Message-Id: <92A6FBB5-1534-48D2-BDEC-C1F08EDFC238@tzi.org> References: <160545895600.10530.12578951934053263693@ietfa.amsl.com> To: CoRE WG X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-senml-versions-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 15 Nov 2020 16:53:16 -0000 I mostly updated the references (RFC8798 is now published) and started = to use RFCXMLv3 superscript notation for exponentiation (which is = bungled in plaintext, for which I added a note). Next week we should = discuss whether this needs any further work. Gr=C3=BC=C3=9Fe, Carsten > On 2020-11-15, at 17:49, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Constrained RESTful Environments WG = of the IETF. >=20 > Title : SenML Features and Versions > Author : Carsten Bormann > Filename : draft-ietf-core-senml-versions-01.txt > Pages : 6 > Date : 2020-11-15 >=20 > Abstract: > This short document updates RFC 8428, Sensor Measurement Lists > (SenML), by specifying the use of independently selectable "SenML > Features" and mapping them to SenML version numbers. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/ >=20 > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-core-senml-versions-01.html >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-senml-versions-01 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Sun Nov 15 16:21:45 2020 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 5A6233A091C; Sun, 15 Nov 2020 16:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 3wW3C0L-LABQ; Sun, 15 Nov 2020 16:21:40 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 7BB6D3A091B; Sun, 15 Nov 2020 16:21:40 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 0AG0L5Y4013523; Sun, 15 Nov 2020 19:21:05 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 0AG0L5Y4013523 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1605486066; bh=OfIvFnzIZN2+yTHs4wp8z1GW1Luiz9UCqYcicCyp0yw=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=s0OPPDSoVlKpuKH3EM5nD1UFSEyuh2BOjrulK/eIniYTmSaZCs6ZxIuYGCkILmgXr /369SCYoxn8gm7ytQ6NjAxgVoP3b1ngIS887Eix8RTMoQXu5zBWEuVVpW/IMJ3JiLi /Exvi3CHIdH6FKY1mqP5bgmHD8OanMZbBS5rWPqc= Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 0AG0L36Y030588; Sun, 15 Nov 2020 19:21:03 -0500 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Sun, 15 Nov 2020 19:21:02 -0500 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Sun, 15 Nov 2020 19:21:02 -0500 From: Roman Danyliw To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= CC: "draft-ietf-core-resource-directory@ietf.org" , "jaime.jimenez@ericsson.com" , "core-chairs@ietf.org" , The IESG , "core@ietf.org" Thread-Topic: [core] Roman Danyliw's Discuss on draft-ietf-core-resource-directory-25: (with DISCUSS and COMMENT) Thread-Index: AQHWsgZQDQzppA+LnE+qtnaWZMMLc6nJ+FnQ Date: Mon, 16 Nov 2020 00:21:01 +0000 Message-ID: References: <159720107494.28255.1546033232009788973@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com> <20201103172506.GD45088@hephaistos.amsuess.com> In-Reply-To: <20201103172506.GD45088@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.48] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [core] Roman Danyliw's Discuss on draft-ietf-core-resource-directory-25: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 16 Nov 2020 00:21:43 -0000 SGkgQ2hyaXN0aWFuIQ0KDQpUaGFua3MgZm9yIHRoZXNlIHB1bGwgcmVxdWVzdHMgKG5vdyBpbiAt MjYpIGFuZCB0aGUgYWRkaXRpb25hbCBleHBsYW5hdGlvbnMgYmVsb3cuICBUaGV5IGFkZHJlc3Nl ZCBteSBESVNDVVNTIGFuZCBDT01NRU5UIGZlZWRiYWNrLiAgSSB3aWxsIGNsZWFyIG15IGJhbGxv dC4NCg0KUmVnYXJkcywNClJvbWFuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogaWVzZyA8aWVzZy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQ2hyaXN0aWFu IEFtc8O8c3MNCj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMywgMjAyMCAxMjoyNSBQTQ0KPiBU bzogUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPg0KPiBDYzogZHJhZnQtaWV0Zi1jb3JlLXJl c291cmNlLWRpcmVjdG9yeUBpZXRmLm9yZzsgamFpbWUuamltZW5lekBlcmljc3Nvbi5jb207DQo+ IGNvcmUtY2hhaXJzQGlldGYub3JnOyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IGNvcmVAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtjb3JlXSBSb21hbiBEYW55bGl3J3MgRGlzY3VzcyBvbiBk cmFmdC1pZXRmLWNvcmUtcmVzb3VyY2UtDQo+IGRpcmVjdG9yeS0yNTogKHdpdGggRElTQ1VTUyBh bmQgQ09NTUVOVCkNCj4gDQo+IChUaGlzIGlzIG9uZSBvZiB0aGUgcG9pbnQtdG8tcG9pbnQgZm9s bG93LXVwIG1haWxzIG9uIHRoZSBSRCAtMjUgcmV2aWV3czsgZm9yIHRoZQ0KPiBwcmVmYWNlLCBw bGVhc2Ugc2VlIHRoZSBwcmVjZWRpbmcgbWFpbCBvbiAiVGhlIHZhcmlvdXMgcG9zaXRpb25zIG9u IGRyYWZ0LWlldGYtDQo+IGNvcmUtcmVzb3VyY2UtZGlyZWN0b3J5LTI1IiBhdA0KPiA8aHR0cHM6 Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9jb3JlL3hXTG9td3dob3ZrVS0NCj4gQ1BH TnhudnM0MEJoYU0vPikuDQo+IA0KPiBBcyBESVNDVVNTOg0KPiANCj4gPiBUaGVyZSBhcHBlYXIg dG8gYmUgYSBmZXcgYXJlYXMgb2Ygc3RyYWlnaHRmb3J3YXJkLCB1bmRlci1zcGVjaWZpZWQNCj4g PiBlbGVtZW50cyBvZiB0aGUgYXV0aG9yaXphdGlvbiBtb2RlbC4NCj4gPg0KPiA+IC0tIEhvdyBk b2VzIHRoZSBSRCBrbm93IHRoYXQgYSBub2RlIGNsYWltaW5nIHRvIGJlIGEgQ1QgaXMgaW4gZmFj dCBhDQo+ID4gQ1QgYW5kIGlzIHBlcm1pdHRlZCB0byByZWdpc3RlciBvbiBiZWhhbGYgb2YgZW5k LXBvaW50cz8gIEl0IHNlZW1zDQo+ID4gbGlrZSB0aGVyZSBpcyBhIG1pc3NpbmcsIHNpbXBsZSBz dGF0ZW1lbnQgdG8gbWFrZSB0aGF0IHRoaXMgaXMgY29uZmlndXJlZCBvdXQgb2YNCj4gYmFuZCB3 aXRoDQo+ID4gdGhlIFJEPyAgT3IgaXMgdGhhdCBjYXJyaWVyIHNvbWVob3cgaW4gYSBhdXRoZW50 aWNhdGlvbiBjcmVkZW50aWFscz8NCj4gDQo+IHJlc3BvbnNlOg0KPiANCj4gVGhlIFJEIGRvZXMg bm90IGRpc3Rpbmd1aXNoIGJldHdlZW4gZW5kcG9pbnRzIGFuZCBDVHM7IGJvdGggYXJlIGp1c3Qg Q29BUA0KPiBjbGllbnRzIHRoYXQgaGF2ZSB0byBwcmVzZW50IHN1aXRhYmxlIGNyZWRlbnRpYWxz Lg0KPiANCj4gVGhlIGZpcnN0IG1lbnRpb24gb2YgQ1RzIGluIHRoZSBzZWN1cml0eSBwb2xpY2ll cyBoYXMgc29tZSB0ZXh0IHRvIHRoYXQuDQo+IA0KPiA+IC0tIElzIHRoZXJlIGFyZSByZWFzb24g d2h5IHRoZXJlIGlzIG5vdCBub3JtYXRpdmUgZ3VpZGFuY2UgcmVxdWlyaW5nDQo+ID4gdGhlIFJE IHRvIGNoZWNrIHdoZXRoZXIgYXV0aGVudGljYXRpb24gY2xpZW50cyBhcmUgYXV0aG9yaXplZCB0 bw0KPiA+IHJlZ2lzdGVyIHBhcnRpY3VsYXIgcmVzb3VyY2VzPyAgU2VjdGlvbiA3LjEgY292ZXJz IHRoZSBpc3N1ZSwgYnV0IGFsbA0KPiA+IG9mIFNlY3Rpb24gNy4qIGlzIGV4cGxpY2l0bHkgbm90 ZWQgYXMgaW5mb3JtYXRpdmUuICBTZWN0aW9uIDguMS4gc2F5cw0KPiA+IOKAnEVuZHBvaW50IGF1 dGhlbnRpY2F0aW9uIG5lZWRzIHRvIGJlIGNoZWNrZWQgaW5kZXBlbmRlbnRseSBvZiB3aGV0aGVy DQo+ID4gdGhlcmUgYXJlIGNvbmZpZ3VyZWQgcmVxdWlyZW1lbnRzIG9uIHRoZSBjcmVkZW50aWFs cyBmb3IgYSBnaXZlbg0KPiA+IGVuZHBvaW50IG5hbWUgKFNlY3Rpb24gNy4xKSBvciB3aGV0aGVy IGFyYml0cmFyeSBuYW1lcyBhcmUgYWNjZXB0ZWQNCj4gPiAoU2VjdGlvbiA3LjEuMSnigJ0gYnV0 IHRoaXMgdGV4dCBzZWVtcyB0byBmcmFtZSBpdCBhcyBhdXRoZW50aWNhdGlvbg0KPiA+IGlzc3Vl LiAgU2VjdGlvbiA4LjIgc2VlbXMgdG8gc3RyZXNzIG9ubHkgdGhlIGRpc3RpbmN0aW9uIGJldHdl ZW4gdGhlDQo+IHJlZ2lzdHJhdGlvbiBhbmQgbG9va3VwIEFQSS4NCj4gDQo+IHJlc3BvbnNlOg0K PiANCj4gVGhlICJhdXRoZW50aWNhdGlvbiIgaGVyZSBpcyBhIHBsYWluIGVycm9yIC0tIGl0IGlz IHRoZSBhdXRob3JpemF0aW9uIHRoYXQgbmVlZHMgdG8NCj4gYmUgY2hlY2tlZC4gKEZpeGVkIGlu IGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL3Jlc291cmNlLWRpcmVjdG9yeS9wdWxsLzI3MSku DQo+IA0KPiBUaGUgRmlyc3QtQ29tZS1GaXJzdC1SZW1lbWJlcmVkIHBvbGljeSB0aGF0IGlzIG5v dyBwcm92aWRlZCBzaG91bGQgaGVscCB0aGUNCj4gcmVhZGVyIHRvIHVuZGVyc3RhbmQgaG93IGEg cG9saWN5IGNhbiBjb21lIHRvIGFuIGF1dGhvcml6YXRpb24gZGVjaXNpb24gZXZlbg0KPiB3aXRo IGFyYml0cmFyeSBlbmRwb2ludCBuYW1lcyAoc2VlIGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdn L3Jlc291cmNlLQ0KPiBkaXJlY3RvcnkvcHVsbC8yNTgpLg0KPiANCj4gPiAtLSBTZWN0aW9uIDgu MS4gIFBlciDigJxJZiB0aGUgc2VydmVyIGRvZXMgbm90IGNoZWNrIHdoZXRoZXIgdGhlDQo+ID4g aWRlbnRpZmllciBwcm92aWRlZCBpbiB0aGUgRFRMUyBoYW5kc2hha2UgbWF0Y2hlcyB0aGUgaWRl bnRpZmllciB1c2VkDQo+ID4gYXQgdGhlIENvQVAgbGF5ZXIgdGhlbiBpdCBtYXkgYmUgaW5jbGlu ZWQgdG8gdXNlIHRoZSBlbmRwb2ludCBuYW1lIGZvcg0KPiA+IGxvb2tpbmcgdXAgd2hhdCBpbmZv cm1hdGlvbiB0byBwcm92aXNpb24gdG8gdGhlIG1hbGljaW91cyBkZXZpY2Uu4oCdLA0KPiA+IHRo aXMgaXMgZ29vZCBhZHZpY2UuICBJZiBEVExTIFBTSyBhbmQgUlBLIGFyZSB1c2VkLCB3aGF0IGlk ZW50aWZpZXJzDQo+ID4gZG9lcyB0aGUgUkQgaGF2ZSB0byBjaGVjayB0byBlbnN1cmUgdGhlIERU TFMgYW5kIENvQVAgbGF5ZXJzIG1hdGNoPw0KPiA+IFBlciA5LjEuMy4xLiAoZm9yIFBTSykgYW5k IDkuMS4zLjIuMSAoZm9yIFJQSykgb2YgUkZDNzI1MiB0aGVyZSBpcyB0aGUNCj4gPiBub3Rpb24g b2YgaWRlbnRpZmllcnMgZm9yIERUTFMgYnV0IHRob3NlIGRvbuKAmXQgbWFuaWZlc3QgaW4gQ29B UD8NCj4gPiBBZGRpdGlvbmFsbHksIHdoZW4gRFRMUyB3aXRoIGEgY2VydGlmaWNhdGUgaXMgdXNl ZCwgaXMgaXQgaW50ZW5kZWQgdG8NCj4gPiBjb21wYXJlIHRoZSBzdWJqZWN0QWx0TmFtZSB3aXRo IHRoZSBhdXRob3JpdHkgaW4gdGhlIFJlZ2lzdHJhdGlvbiBCYXNlDQo+ID4gVVJJIChpLmUuLCB3 aGljaCBleGFjdCBjZXJ0aWZpY2F0ZSBmaWVsZHMgc2hvdWxkIGl0IGNvbXBhcmUgd2l0aCB0aGUg Q29BUCk/DQo+IA0KPiByZXNwb25zZToNCj4gDQo+IFRoZSBwcmVjaXNlIGlkZW50aWZpZXJzIHVz ZWQgd2lsbCBkZXBlbmQgb24gdGhlIHNlY3VyaXR5IHBvbGljaWVzIGluIHBsYWNlLg0KPiANCj4g VGhlIGFib3ZlbWVudGlvbmVkIEZpcnN0LUNvbWUtRmlyc3QtUmVtZW1iZXJlZCBwb2xpY3kgbWFr ZXMgcHJlY2lzZSBwb2ludHMNCj4gYWJvdXQgdGhlIGZpZWxkcyB0byBpbnRyb3NwZWN0IGZvciB0 aGF0IGNhc2UsIG90aGVyIHRvLWJlLWRlZmluZWQgcG9saWNpZXMgYXJlDQo+IGV4cGVjdGVkIHRv IGRvIHRoZSBzYW1lLg0KPiANCj4gQW5kIGFzIENPTU1FTlQ6DQo+IA0KPiA+ICoqIFNlY3Rpb24g My41LiAgUGVyIOKAnFdoZW4gZW5kcG9pbnRzIGFyZSBub3QgY29ubmVjdGVkIOKApiBhIHJlbW90 ZQ0KPiA+IHNlcnZlciBpcyB1c3VhbGx5IHVzZWQgdG8gcHJvdmlkZSBwcm94eSBhY2Nlc3MgdG8g dGhlIGVuZHBvaW50c+KAnSwgdGhpcw0KPiA+IGFyY2hpdGVjdHVyZSB3YXNu4oCZdCBlbnRpcmVs eSBjbGVhciB0byBtZS4gIEhvdyBjYW4gYSBwcm94eSBwcm92aWRlDQo+ID4gYWNjZXNzIHRvIGFu IGVuZHBvaW50IHRoYXQgaXNu4oCZdCBjb25uZWN0ZWQ/ICBPciBpcyBwcm94eSBtZWFudCBhcyBh DQo+ID4gc3Vic3RpdHV0ZSBoZXJlIG9yIGFuIGludGVybWVkaWFyeT8NCj4gDQo+IHJlc3BvbnNl Og0KPiANCj4gVGhlcmUgaGF2ZSBiZWVuIGRpZmZlcmVudCBhcHByb2FjaGVzIHRvIHRoZSBzbGVl cHkgbm9kZXMgcHJvYmxlbS4gTm9uZSBoYXMNCj4gcmVzdWx0ZWQgaW4gYSBXRyBkb2N1bWVudCBl dmVuLCBidXQgdGhlIGF3YWtlIGhlbHBlciBiZWluZyBhIHByb3h5IGlzIGENCj4gY29tbW9uIHRo ZW1lLiBOb3RlIHRoYXQgYSBwcm94eSBkb2VzIG5vdCBuZWVkIHRvIGNvbnRhY3QgdGhlIG9yaWdp biBzZXJ2ZXINCj4gdG8gc2VydmUgYWxsIHJlcXVlc3RzIGFzIGl0IG1heSBoYXZlIGEgZnJlc2gg cmVwcmVzZW50YXRpb24uIFRoZSBkaWZmZXJlbnQNCj4gYXBwcm9hY2hlcyB0byBzbGVlcHkgcmVz dWx0IGluICJiZWVmZWQgdXAiIHByb3hpZXMgdGhhdCBoYXZlIGJldHRlciBjaGFuY2VzIG9mDQo+ IGJlaW5nIGFibGUgdG8gc2VydmUgc29tZSBraW5kIG9mIGNhY2hlZCByZXNwb25zZS4NCj4gDQo+ ID4gKiogU2VjdGlvbiAzLjYuICBUaGUgaG9tZSBhbmQgYnVpbGRpbmcgYXV0b21hdGlvbiB1c2Ug Y2FzZSBkb2VzbuKAmXQNCj4gPiBtYWtlIGFueSByZWZlcmVuY2UgdG8gdGhlIFJEIGFyY2hpdGVj dHVyZSAobGlrZSB0aGUgb3RoZXIgdHdvIHVzZSBjYXNlcykuDQo+IA0KPiByZXNwb25zZToNCj4g DQo+IFRoZXkgZG8gbm93IChhcyBwZXIgaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvcmVzb3Vy Y2UtZGlyZWN0b3J5L3B1bGwvMjY0KS4NCj4gDQo+ID4gKiogU2VjdGlvbiA0LjAuICBQZXIg4oCc 4oCmIGZhbGxpbmcgYmFjayB0byBmYWlsaW5nIHRoZSBvcGVyYXRpb25zIGlmDQo+ID4gcmVjb3Zl cnkgaXMgbm90IHBvc3NpYmxl4oCdLCBjYW4g4oCcZmFpbGluZyB0aGUgb3BlcmF0aW9u4oCdIGJl IGNsYXJpZmllZD8NCj4gDQo+IHJlc3BvbnNlOg0KPiANCj4gTm90IHdpdGhvdXQgZ3Jvd2luZyB0 aGUgdGV4dCBhIGxvdC4gQSBmYWlsZWQgb3BlcmF0aW9uJ3MgbWVhbmluZyBkZXBlbmRzIG9uDQo+ IHRoZQ0KPiBvcGVyYXRpb246IEluIHN0ZXBzIGZyb20gZmluZGluZyBhbiBSRCB0byByZWdpc3Ry YXRpb24sIGl0IG1lYW5zIHN0b3BwaW5nDQo+IHdoYXRldmVyIHdhcyBqdXN0IHRyaWVkIGFuZCBj b250aW51aW5nIHdpdGggb3RoZXIgb3B0aW9ucywgYW5kIGV2ZW50dWFsbHkNCj4gcnVubmluZyBv dXQgb2YgdGhlbSBub3RpZnlpbmcgdGhlIHVzZXIuIEluIHJlZ3N0cmF0aW9uIHVwZGF0ZXMsIGl0 IG1lYW5zIHRoYXQgYQ0KPiBuZXcgcmVnaXN0cmF0aW9uIGlzIHN0YXJ0ZWQuIEluIGxvb2t1cHMs IHRoZSBhcHBsaWNhdGlvbiBtYXkgZmFsbCBiYWNrIHRvIG1ldGhvZHMNCj4gb3V0c2lkZSB0aGUg c3BlY2lmaWNhdGlvbiAoZWcuIGRvaW5nIG11bHRpY2FzdCBkaXNjb3Zlcnkgd2hlbiBubyBSRCBp cyBhcm91bmQNCj4gb3IgdXNhYmxlKSBvciBqdXN0IHJlcG9ydCB0byB0aGUgdXNlci4NCj4gDQo+ IEZvciB3aGVyZSB0aGVyZSBpcyBzb21ldGhpbmcgdG8gc2F5LCBzZWN0aW9ucyBjb250YWluIHBh cmFncmFwaHMgc3RhcnRpbmcgIklmDQo+IHRoZSAuLi4gZmFpbHMiLg0KPiANCj4gPiAqKiBQZXIg U2VjdGlvbiA0LjAuICBQZXIg4oCcQW4gUkQgTUFZIG1ha2UgdGhlIGluZm9ybWF0aW9uIHN1Ym1p dHRlZCB0bw0KPiA+IGl0IGF2YWlsYWJsZSB0byBmdXJ0aGVyIGRpcmVjdG9yaWVz4oCdLCBhcmUg dGhlcmUgY2lyY3Vtc3RhbmNlcyB3aGVyZQ0KPiA+IGVuZCBwb2ludHMgd291bGQgbm90IHdhbnQg dGhhdD8NCj4gDQo+IHJlc3BvbnNlOg0KPiANCj4gSWYgdGhlcmUgaXMgYSBzZWN1cml0eSBwb2xp Y3kgaW4gcGxhY2UgZm9yIGxpbmsgY29uZmlkZW50aWFsaXR5LCB5ZXMuIFRoZSBwcmVzZW5jZSBv Zg0KPiBzdWNoIGEgcG9saWN5IGRvZXNuJ3QgcnVsZSBvdXQgcmVwbGljYXRpb24gYXQgYWxsLCB0 aG91Z2ggLS0gaWYgdGhlIHRhcmdldCBkaXJlY3RvcnkNCj4gaXMgYXV0aG9yaXplZCB0byByZWNl aXZlIHRoZSBsaW5rcyAoYXMgaXQgdXBob2xkcyB0aGUgc2FtZSBsaW5rIGNvbmZpZGVudGlhbGl0 eQ0KPiBwb2xpY2llcyksIGZvcndhcmRpbmcgY2FuIHN0aWxsIGJlIGp1c3RpZmllZCwgYW5kIGlz IGV4cGVjdGVkIHRvIGhhcHBlbiBsaWtlIHRoYXQgaW4NCj4gbWFuYWdlZCBpbnN0YWxsYXRpb25z Lg0KPiANCj4gVGhlIHBhcmFncmFwaCBoYXMgYmVlbiBhbWVuZGVkIHRvIHJlZmVyIHRvIHRoZSBz ZWN1cml0eSBwb2xpY2llcyBhcHBsaWNhYmxlIHRvDQo+IGxvb2t1cHMuIChDb25jcmV0ZSBjaGFu Z2UgaW4gaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvcmVzb3VyY2UtDQo+IGRpcmVjdG9yeS9w dWxsLzI3MikuDQo+IA0KPiA+ICoqIFNlY3Rpb24gNC4xLiAgUGVyIOKAnDIuIEluIGEgbmV0d29y ayB0aGF0IHN1cHBvcnRzIG11bHRpY2FzdCB3ZWxsLA0KPiA+IOKApuKAnSwgd2hhdCBkb2VzIGl0 IG1lYW4gdG8g4oCcc3VwcG9ydCBtdWx0aWNhc3QgX3dlbGxf4oCdPw0KPiANCj4gcmVzcG9uc2U6 DQo+IA0KPiAiTm90IHdlbGwiIGlzIG1lYW50IHRvIHJvdWdobHkgc3VtbWFyaXplICJub3QgZWZm aWNpZW50bHkiICh3aGVuIHRoZSBtdWx0aWNhc3QNCj4gd291bGQgYmUgZmxvb2RlZCBvdmVyIG1h bnkgaW5kaXZpZHVhbCBsaW5rcyksICJub3QgY29udmVuaWVudGx5IiAod2hlbiBpdA0KPiB3b3Jr cyBidXQgdGhlIHRvb2xpbmcgYXJvdW5kIGl0IG1ha2VzIGl0IGhhcmQgdG8gdXNlIGZvciBpbXBs ZW1lbnRhdGlvbnMpLCBvcg0KPiBldmVuICJub3QgYXQgYWxsIiAod2hlbiBvdGhlciBDb0FQIHRy YW5zcG9ydHMgdGhhbiBDb0FQLW92ZXItVURQIGFyZQ0KPiBpbnZvbHZlZCkuDQo+IA0KPiA+ICoq IFNlY3Rpb24gNS4gIFBlciB0aGUgZXAgZGVmaW5pdGlvbiBvZiB0aGUgVVJJIFRlbXBsYXRlIFZh cmlhYmxlcywNCj4gPiB3aGF0IGRvZXMgaXQgbWVhbiBmb3IgdGhlIGFuIGVuZHBvaW50IHRvIGJl IOKAnChtb3N0bHkgbWFuZGF0b3J5KT8NCj4gDQo+ICJNb3N0bHkgbWFuZGF0b3J5IiBoZXJlIG1l YW5zIHRoYXQgaXQgaXMgbWFuZGF0b3J5IHVubGVzcyB0aGUgUkQgaXMNCj4gY29uZmlndXJlZCB0 byByZWNvZ25pemUgdGhlIGVuZHBvaW50IG5hbWUgZnJvbSB0aGUgY3JlZGVudGlhbHMuDQo+IEVu aGFuY2VtZW50cyBoYXZlIGJlZW4gbWFkZSB0byB0aGUgd29yZGluZyBvZiB0aGUgZXhjZXB0aW9u IGF0DQo+IGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL3Jlc291cmNlLWRpcmVjdG9yeS9wdWxs LzI3Mywgd2hpY2ggc2hvdWxkIG1ha2UNCj4gdGhlIHBocmFzZSAibW9zdGx5IG1hbmRhdG9yeSIg ZnVsbHkgdW5kZXJzdGFuZGFibGUgYnkgdGhlIGVuZCBvZiB0aGUgaXRlbS4NCj4gDQo+ID4gKiog U2VjdGlvbiA3LjEuICBQZXIg4oCcV2hlbiBjZXJ0aWZpY2F0ZXMgYXJlIHVzZWQgYXMgYXV0aG9y aXphdGlvbg0KPiA+IGNyZWRlbnRpYWxzLCB0aGUgc2VjdG9yKHMpIGFuZCBlbmRwb2ludCBuYW1l KHMpIGNhbiBiZSB0cmFuc3BvcnRlZCBpbg0KPiA+IHRoZSBzdWJqZWN04oCdLCByZWNvbW1lbmQg YmVpbmcgbW9yZSBwcmVjaXNlIG9uIHdoYXQgZXhhY3QgWC41MDkNCj4gPiBmaWVsZChzKSB5b3Ug bWVhbiB3aGVuIHNheWluZyDigJxzdWJqZWN04oCdLg0KPiANCj4gcmVzcG9uc2U6DQo+IA0KPiBT ZWUgR0VORVJJQy1TVUJKRUNULg0KPiANCj4gPiAqKiBTZWN0aW9uIDcuMS4xLiBQZXIg4oCcUmVn aXN0cmFudHMgdGhhdCBhcmUgcHJlcGFyZWQgdG8gcGljayBhDQo+ID4gZGlmZmVyZW50IGlkZW50 aWZpZXIgd2hlbiB0aGVpciBpbml0aWFsIGF0dGVtcHQgYXQgcmVnaXN0cmF0aW9uIGlzDQo+ID4g dW5hdXRob3JpemVkIHNob3VsZCBwaWNrIGFuIGlkZW50aWZpZXIgYXQgbGVhc3QgdHdpY2UgYXMg bG9uZyBhcyB0aGUNCj4gPiBleHBlY3RlZCBudW1iZXIgb2YgcmVnaXN0cmFudHPigJ0sIGhvdyB3 b3VsZCBhIHJlZ2lzdHJhbnQga25vdyB0aGUNCj4gcG9wdWxhdGlvbiBzaXplPw0KPiANCj4gcmVz cG9uc2U6DQo+IA0KPiBBcHBsaWNhdGlvbnMgY2FuIGRlc2NyaWJlIHR5cGljYWwgc2l6ZXMgb2Yg dGhlaXIgZGVwbG95bWVudHM7IGZvciBleGFtcGxlLCBpbiBhDQo+IHNpbmdsZS10ZW5hbnQgaG9t ZSBhdXRvbWF0aW9uIHN5c3RlbSwgMjU2IGlzIGEgc2FuZSB1cHBlciBib3VuZCBmb3IgdGhlIHNp emUNCj4gZXN0aW1hdGUsIHNvIDQgaGV4IGRpZ2l0cyB3b3VsZCBzdWZmaWNlLg0KPiANCj4gV2hl cmUgdGhlcmUncyBubyBzdWNoIGVzdGltYXRlcyBhdmFpbGFibGUsIHRoZSBVVUlEIHdheSBpcyB1 bml2ZXJzYWxseQ0KPiBhcHBsaWNhYmxlLg0KPiANCj4gPiAqKiBTZWN0aW9uIDcuMi4gIFBlciDi gJxUbyBhdm9pZCB0aGUgbGltaXRhdGlvbnMsIFJEIGFwcGxpY2F0aW9ucyBzaG91bGQNCj4gPiBj b25zaWRlciBwcmVzY3JpYmUgdGhhdCBsb29rdXAgY2xpZW50cyBvbmx5IHVzZSB0aGUgZGlzY292 ZXJlZA0KPiA+IGluZm9ybWF0aW9uIGFzIGhpbnRzLCBhbmQgZGVzY3JpYmUgd2hpY2ggcGllY2Vz IG9mIGluZm9ybWF0aW9uIG5lZWQgdG8NCj4gPiBiZSB2ZXJpZmllZCB3aXRoIHRoZSBzZXJ2ZXLi gJ0sIEkgd2FzbuKAmXQgc3VyZSB3aGljaCB2ZXJpZmljYXRpb24gdGhpcyB3b3VsZCBiZS4NCj4g DQo+IHJlc3BvbnNlOg0KPiANCj4gVGhlIGludGVuZGVkIHZlcmlmaWNhdGlvbiBpcyB3aXRoIGEg dHJ1c3RlZCBzb3VyY2UsIHdoaWNoIHdvdWxkIHR5cGljYWxseSBiZSB0aGUNCj4gc2VydmVyIGhv c3RpbmcgdGhlIHJlc291cmNlLg0KPiANCj4gVGhpcyBiZWNhbWUgcGFydCBvZiBhIGxhcmdlciBk aXNjdXNzaW9uIGFyb3VuZCBzZXJ2ZXIgYXV0aG9yaXphdGlvbiBhdA0KPiA8aHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9jb3JlL0p5VzBYQWtYcmUxd3ZLb054TXdlZ09VQ3kN Cj4gd2MvPiwNCj4gYW5kIHdoaWxlIHRoZXJlIGlzIGhvcGUgdGhhdCB3aGF0IGNvbWVzIG9mIHRo aXMgd2lsbCBiZSB1c2VmdWwgdG8gQ29SRSAob3IgZXZlbg0KPiB3ZWIpIGFwcGxpY2F0aW9ucyBp biBnZW5lcmFsLCB0aGUgY2hhbmdlcyB0byB0aGUgdGV4dCAoInRvIHJlcXVlc3QgaXQgYWdhaW4g ZnJvbQ0KPiBhbiBhdXRob3JpemVkIHNlcnZlciwgdHlwaWNhbGx5IHRoZSBvbmUgdGhhdCBob3N0 cyB0aGUgdGFyZ2V0IHJlc291cmNlIiwNCj4gaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cvcmVz b3VyY2UtZGlyZWN0b3J5L3B1bGwvMzA2KSBzaG91bGQgbWFrZSB0aGUNCj4gcGFyYWdyYXBoIGl0 c2VsZiBjbGVhciBlbm91Z2guDQo+IA0KPiA+ICoqIFNlY3Rpb24gNy4zLiAgVGhpcyBzZWN0aW9u IGNhdXRpb25zIGFib3V0IHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuDQo+ID4gdGhlIHJlZ2lzdHJh bnQgcHVibGlzaGVzIGl0c2VsZiB2cy4gd2hhdCBpcyBpbiB0aGUgUkQuICBJdCBtaWdodCBiZQ0K PiA+IHdvcnRoIHJlaXRlcmF0aW5nIHRoYXQgdGhlIFJEIG1heSBhbHNvIHB1Ymxpc2ggd2hhdCBp dCBrbm93cyB0byBvdGhlcnMNCj4gPiBwZXIgU2VjdGlvbiA0LjDigJlzIOKAnEFuIFJEIE1BWSBt YWtlIHRoZSBpbmZvcm1hdGlvbiBzdWJtaXR0ZWQgdG8gaXQNCj4gPiBhdmFpbGFibGUgdG8gZnVy dGhlciBkaXJlY3Rvcmllc+KAnQ0KPiANCj4gcmVzcG9uc2U6DQo+IA0KPiBBIHJlZmVyZW5jZSBo YXMgYmVlbiBhZGRlZCBpbiB0aGUgb3RoZXIgZGlyZWN0aW9uLCBhcyB0aGF0IGlzIHdoZXJlIHRo ZSBjYXJlDQo+IG11c3QgYmUgdGFrZW4gLS0gdGhlICJNQVkgbWFrZSBbLi4uXSBhdmFpbGFibGUi IG5vdyBjYXV0aW9ucyBhYm91dCBhbnkgbGluaw0KPiBjb25maWRlbnRpYWxpdHkgcG9saWNpZXMg KGNoYW5nZSBpbiBodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9yZXNvdXJjZS0NCj4gZGlyZWN0 b3J5L3B1bGwvMjcyKS4NCj4gDQo+ID4gKiogRWRpdG9yaWFsIE5pdHMgLS0gR2xvYmFsLiAgcy9j YW4gbm90L2Nhbm5vdC9nDQo+IA0KPiByZXNwb25zZToNCj4gDQo+IEFkZHJlc3NlZCBpbiBodHRw czovL2dpdGh1Yi5jb20vY29yZS13Zy9yZXNvdXJjZS1kaXJlY3RvcnkvcHVsbC8yNTMNCj4gDQo+ ID4gLS0gU2VjdGlvbiA0LiAgRWRpdG9yaWFsLiAgUGVyIOKAnE9ubHkgbXVsdGljYXN0IGRpc2Nv dmVyeSBvcGVyYXRpb25zDQo+ID4gYXJlIG5vdCBwb3NzaWJsZSBvbiBIVFRQLCBhbmQgU2ltcGxl IFJlZ2lzdHJhdGlvbiBjYW4gbm90IGJlIGV4ZWN1dGVkDQo+ID4gYXMgYmFzZSBhdHRyaWJ1dGUg 4oCmIGNhbiBub3QgYmUgdXNlZCB0aGVyZeKAnSwgdGhpcyBzZW50ZW5jZSBkaWRu4oCZdCBwYXJz ZS4NCj4gDQo+IHJlc3BvbnNlOg0KPiANCj4gVW5kZXJzdGFuZGFibGU7IGl0IHdhcyBjaGFuZ2Vk IGluIGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL3Jlc291cmNlLQ0KPiBkaXJlY3RvcnkvcHVs bC8yNzQuDQo= From nobody Mon Nov 16 01:19:34 2020 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 B512D3A1648 for ; Mon, 16 Nov 2020 01:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 GMuLcliHx9d3 for ; Mon, 16 Nov 2020 01:19:30 -0800 (PST) Received: from wforward3-smtp.messagingengine.com (wforward3-smtp.messagingengine.com [64.147.123.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C56B43A0E50 for ; Mon, 16 Nov 2020 01:19:30 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.west.internal (Postfix) with ESMTP id 57465949; Mon, 16 Nov 2020 04:19:29 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 16 Nov 2020 04:19:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=Mut2ITKo/uYO4Nbt6fN9dFQkCTzgOjF/ney5P63aU M4=; b=jsFEUtEGDJcrUyxkqLjkjgBzdziVCCVL9jwg1hu41+F0JqTBhltTUv99T 5lRnwHXu/ADVnHpc7dk8jFotNiNQKZXhujO9gM4eGwLCD5i1EMnqOg2nq377tlRO 8DQpA01Q2t7sOkqI8zUxbjhKJfNTzWesSMOiK7LD7GoHMuFOTAzpHEDSngQeJVsL UO1iSLls1rLv7p1bDgHHIq9C66BMLPRi2OfxceOuUVMZoHNz87RQ+aIDCpshZq15 2ctM3+8Nju6Q4mzuT9H4LkM7fmBArEvnyRbBOAQ5CTPSpuvVYQ3EEwafAE2ocK03 YrrhaKLCgu3p/IEIqx9axXZ000qwg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefuddgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtugfgjgesthekredttddtjeenucfhrhhomheplfgrihhm vgculfhimhornhgviicuoehjrghimhgvsehikhhirdhfiheqnecuggftrfgrthhtvghrnh epiedujeeitddvleevjeefueehteeftdevteelieeiveehvdevkefgkedvfefguddunecu ffhomhgrihhnpehirghnrgdrohhrghdpuhhsrghgvgdrmhhgnecukfhppeekvddrvddtfe drvddvjedruddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepjhgrihhmvgesihhkihdrfhhi X-ME-Proxy: Received: from EMB-918HFH01 (82-203-227-12.bb.dnainternet.fi [82.203.227.12]) by mail.messagingengine.com (Postfix) with ESMTPA id 9C0F63280063; Mon, 16 Nov 2020 04:19:27 -0500 (EST) Date: Mon, 16 Nov 2020 11:19:26 +0200 From: =?utf-8?Q?Jaime=20Jim=C3=A9nez?= To: Carsten Bormann Cc: CoRE WG Message-ID: <20201116091926.deyitohypascri6q@EMB-918HFH01> References: <20201109144145.nzp2oqiam7bdlqed@EMB-918HFH01> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [core] Proposed new SenML Units X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 16 Nov 2020 09:19:33 -0000 Hi Carsten, On 09.11.2020 16:12, Carsten Bormann wrote: >Hi Jaime, > >> On 2020-11-09, at 15:41, Jaime Jiménez wrote: >> >> >> Dear CoRE and SeNML experts, >> >> the IPSO WG has some new objects being registered that contain units >> that are not currently present in the IANA SenML registry ( >> https://www.iana.org/assignments/senml/senml.xhtml ) nor derived >> from it. We would like to discuss the addition of the units below: >> >> +===========+================================+=======+ >> | Symbol | Description | Type | >> +===========+================================+=======+ >> | NTU | Nephelometric Turbidity Unit | Float | >> +-----------+--------------------------------+-------+ >> | mg/l | milligrams per liter | Float | >> +-----------+--------------------------------+-------+ > > >> NTU is the most common way to measure turbidity. > >This one is interesting. There are several Turbidity units, which are not in a simple linear relationship, so I would like to get some input from domain experts which ones we should have (and which are more of a historical interest). > AFAIK NTU was chosen by the experts of the uCIFI Alliance, who work on the "Smart Water" domain field. Also Michael Koster commented on this thread on the NTU usage. >> mg/l is used to measure >> concentration, possibly g/l should also be added as shown in the table >> below. > >We already have >kg/m3 kilogram per cubic meter (mass density, mass concentration) float [RFC8798] > >One mg/l is 1/1000 kg/m3, so that would go into table 2. That sounds very good to me. > >> On the secondary units table we would have the units below. >> +=========+======================+======+==========+======+ >> |Secondary| Description |SenML | Scale |Offset| | Unit | |Unit | | | >> +=========+======================+======+==========+======+ >> | ppb | parts per billion | / | 1e-9 | 0 | >> +---------+----------------------+------+----------+------+ >> | ppt | parts per trillion | / | 1e-12 | 0 | >> +---------+----------------------+------+----------+------+ >> | KB | Kilobytes | B | 1000 | 0 | >> +---------+----------------------+------+----------+------+ >> | VAh | Volt Ampere x Hour | kVAh | 1/1000 | 0 | >> +---------+----------------------+------+----------+------+ >> | g/l | grams per liter | mg/l | 1000 | 0 | >> +---------+----------------------+------+----------+------+ > >VAh should be on the SI base unit, i.e.: > > VAh volt-ampere-hour VAs 3600 0 > OK >g/l is a synonym for kg/m3 (i.e. scale=1); that is not strictly needed but could be added if the g/l people can’t adjust to kg/m3. > If it's not much effort, having g/l would help. >> As to the KB addition, the reason is that many are still confused as to >> whether KB is 1000 or 1024 bytes. > >KB = Kelvin-Byte, pretty much nonsensical. >kB is 1000 B, which is not very widely used. >KiB is 1024 B, which we already have. Yes, sorry not KB but kB. > >> If we are taking KB as 1000 bytes, > >KB is like kph, it’s not properly defined and should not be added. > I agree kB is not used in practice, though when people use KiB they often call it kB still. Perhaps that's off-topic when it comes to senml. >> then having an entry in the table would be a good clarification to avoid >> ambiguity. >> >> ppt could be confused with parts per thousand by some, so I would like >> to clarify in this email that "parts per thousand" would be the "/1000" >> or "permille" entry in the secondary units registry. Please confirm this >> as well. > >Yes. >So, after adding ppb and ppt, we’ll have >/ /100 /1000 ppm ppb ppt >1 0.01 1e-3 1e-6 1e-9 1e-12 > OK! >> I believe the scale of ppb and ppt is correct, please double check just >> in case. > >Yes. OK! > >Grüße, Carsten > > From nobody Mon Nov 16 01:22:19 2020 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 619BE3A1643 for ; Mon, 16 Nov 2020 01:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 pdkU9LKKVdsT for ; Mon, 16 Nov 2020 01:22:16 -0800 (PST) Received: from wforward3-smtp.messagingengine.com (wforward3-smtp.messagingengine.com [64.147.123.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3BEF3A1636 for ; Mon, 16 Nov 2020 01:22:16 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.west.internal (Postfix) with ESMTP id 08F19203; Mon, 16 Nov 2020 04:22:15 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 16 Nov 2020 04:22:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=UvLbl1 ApanNFzvAdo4uQ5Jwvi3NA5tVuuEHxyf8RURM=; b=ruN13J65DtYSMgvcdXupZd Z7WBfyQaOtaWdYnG7uiFYYWiCaVJiLNupJt+esubi/OP7AUObceB6TDe68pn7I53 FRZoVBVoam3u7TWfsCl+FDMkUQl/n7mMe8Kcnfv8fkjbv0vL17zLAxweyrLi8VAu zi15os04nSHnNRXRmVYQE617hAsIaPZlZCKTOg9ihA99nb8aUMprmL1V3TD0HVrD mxX533W9XEvTslcFrvyyCSpZqVtFZYc972JJC/7SbucPSUUYc6c0lFGZtcYMcX8l OtpdjI686qkuEZX2nFigxzH9ZEsNGtdFu+id/boqOeLu8Qi2N2q5P+K+wUhuow5A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefuddgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttdejnecuhfhrohhmpeflrghimhgv ucflihhmrohnvgiiuceojhgrihhmvgesihhkihdrfhhiqeenucggtffrrghtthgvrhhnpe dtvdffiedtledvfeekgfelffetffevgefftdfgfedtvdfhveeggfehkeefkedvleenucfk phepkedvrddvtdefrddvvdejrdduvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehjrghimhgvsehikhhirdhfih X-ME-Proxy: Received: from EMB-918HFH01 (82-203-227-12.bb.dnainternet.fi [82.203.227.12]) by mail.messagingengine.com (Postfix) with ESMTPA id 177C3328005E; Mon, 16 Nov 2020 04:22:13 -0500 (EST) Date: Mon, 16 Nov 2020 11:22:13 +0200 From: =?utf-8?Q?Jaime=20Jim=C3=A9nez?= To: Michael Koster Cc: Carsten Bormann , CoRE WG Message-ID: <20201116092213.k2jzis7ycqjyi3zq@EMB-918HFH01> References: <20201109144145.nzp2oqiam7bdlqed@EMB-918HFH01> <041E8922-F467-430B-957C-6BB193D8352F@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline In-Reply-To: <041E8922-F467-430B-957C-6BB193D8352F@gmail.com> Archived-At: Subject: Re: [core] Proposed new SenML Units X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 16 Nov 2020 09:22:18 -0000 Hi Michael, thank you very much for your confirmation and insights on the topic. I now wonder if we should add ug/l as well as NTU. For IPSO it looks like NTU would be sufficient. Ciao! -- Jaime On 09.11.2020 07:43, Michael Koster wrote: > >> On Nov 9, 2020, at 7:12 AM, Carsten Bormann wrote: >> >>> >>> +===========+================================+=======+ >>> | Symbol | Description | Type | >>> +===========+================================+=======+ >>> | NTU | Nephelometric Turbidity Unit | Float | >>> +-----------+--------------------------------+-------+ >>> | mg/l | milligrams per liter | Float | >>> +-----------+--------------------------------+-------+ >> >> >>> NTU is the most common way to measure turbidity. >> >> This one is interesting. There are several Turbidity units, which are not in a simple linear relationship, so I would like to get some input from domain experts which ones we should have (and which are more of a historical interest). >> >> > >FWIW > >While I'm not specifically a domain expert, I do have experience in a water turbidity measurement program. > >I was responsible for process control and measurement systems in a large number of oil & gas installations in Alaska in the 1980s (please no "historical interest jokes...) > >One of the installations was a water injection facility that needed to be accountable for the purity of the water injected into the ground over a period of decades. We maintained a fleet of "Surface-Scatter Turbidimeters" which measured turbidity in NTU. I was responsible for calibration of the machines and "certification" of the measurement record. > >Turbidity is an indirect measure of suspended solids in water or other fluid, measured according of the amout of light blocked from transmission through the fluid. The Surface-Scatter Turbidimeter, or Nephelometer, measures the diffraction of light from surface roughness caused by the suspended solids. Standard solutions or cards (for field calibration) are used to calibrate the measurements. > >A quick check on Wikipedia and discussion with an acquaintance who is a (retired) water treatment consultant (chemical salesman) confirms that NTU is still the metric of choice, though some facilities that know what their contaminants are can convert it to a concentration unit like ug/l for "internal" use. > >Best regards, > >Michael From nobody Mon Nov 16 04:01:46 2020 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 9C6D93A0D9B; Mon, 16 Nov 2020 04:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s998uo9xs1Ol; Mon, 16 Nov 2020 04:01:42 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 6D31E3A0D99; Mon, 16 Nov 2020 04:01:40 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0AGC1W96019779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Nov 2020 07:01:37 -0500 Date: Mon, 16 Nov 2020 04:01:32 -0800 From: Benjamin Kaduk To: Michael Richardson Cc: The IESG , draft-ietf-core-stateless@ietf.org, core-chairs@ietf.org, core@ietf.org, Carsten Bormann Message-ID: <20201116120132.GW39170@kduck.mit.edu> References: <158741679923.20291.1071401061463555301@ietfa.amsl.com> <0c186080-6ac1-2a9d-1e0a-7cf3b3667d52@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0c186080-6ac1-2a9d-1e0a-7cf3b3667d52@sandelman.ca> Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-stateless-06: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 16 Nov 2020 12:01:45 -0000 Hi Michael, Thanks; this looks good and I'm happy to clear the discuss (and will do so shortly). A couple notes inline, and also one on the (nicely) expanded 5.2: When encryption is used, the use of AES-CCM [RFC3610] with a 64-bit tag is recommended, combined with a sequence number and a replay window. This choice is informed by available hardware acceleration of on many constrained systems. If a different algorithm is available accelerated on the sender, with similar strength, then it SHOULD be preferred. Where privacy of the state is not required, and (similar strength or stronger, presumably). On Thu, Nov 05, 2020 at 11:16:18AM -0500, Michael Richardson wrote: > The ID submission system is closed, but we have a -08 ready. (It's open again now!) > You can view the diff against -06 at: > > https://ietf.org/rfcdiff?url1=draft-ietf-core-stateless-06.txt&url2=https://raw.githubusercontent.com/core-wg/stateless/master/draft-ietf-core-stateless-08.txt > > If you'd like to approve updating this document, the XML is at: > > https://raw.githubusercontent.com/core-wg/stateless/master/draft-ietf-core-stateless-08.xml > > The document is ready. > > On 2020-04-20 5:06 p.m., Benjamin Kaduk via Datatracker wrote: > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Let's discuss whether the various and sundry conditional SHOULDs in > Section > > 3.1 are better written as conditional MUSTs (i.e., with the listed > > exclusions being the only allowed exclusion). > > Hi, we have left them as SHOULD. > AFAIK, a SHOULD is a conditional MUST, and I agree that exclusions need > to be > listed. Okay, thanks for thinking about it. > The security considerations say: > It maybe that in some very specific case, as a result of a careful > and detailed analysis of any potential attacks, that there may be > cases where such cryptographic protections do not add value. The > authors of this document have not found such a use case as yet, but > this is a local decision. nit: I see what you are trying to say, but the current wording looks like there's supposed to be cause/effect between doing the analysis and lack of value in cryptographic protection. Maybe s/as a result of/as revealed by/? Thanks again! -Ben > There are no interoperability requirements around what the token format is. > I don't feel strongly one way or another but it seems like the text is > already pretty clear. > > > Also, Appendix A.2 seems to show "Len (extended)" as just 0-2 bytes when > > IIUC it is 0-4 bytes. > > This was fixed in the diagram. > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Section 2.1 > > > > The new definition of the TKL field increases the maximum token > > length that can be represented in a message to 65804 bytes. However, > > the maximum token length that sender and recipient implementations > > support may be shorter. For example, a constrained node of Class 1 > > [RFC7228] might support extended token lengths only up to 32 bytes. > > > > Is there anything to say about IP MTU here? > > Not really. Obviously, if you can't fit the bigger token into the packet, > then you can't use it. > > > This is a fairly subtle way of saying that core RFC 7252 > > procedures/semantics are being updated; I'd suggest calling out > (alongside > > the other updates) the new(?) requirement for distinguishing whether an > > extension is unrecognized vs. an invalid value by producing reset vs. a > > distinguished error code. (I do see that the semantics for 5.03 and 4.00 > > are not changing, but the use of Reset vs. error code for feature > > negotiation seems important for implementors to be aware of.) > > This was opened as https://github.com/core-wg/stateless/issues/3 > The document already Updates RFC7252. > > comments on Section 3.1/3.2 already applied > > > Section 4 > > > > Perhaps it's worth noting that this nesting of state will necessarily > > increase the token size as it progresses along a chain of intermediaries? > > > > There's also some considerations relating to how the freshness window > of the > > client an intermediary interact, with the client effectively being > limited > > to the minimum of all windows in use by client and intermediate(s) on the > > path. > > > > If the intermediary has a very long freshness window it could be tricked > > into sending "replies" to addresses that it thinks are clients but > may not > > be any more, e.g., allowing a DoS attack to traverse a NAT or firewall. > > Opened as https://github.com/core-wg/stateless/issues/4 > closed as wontfix after some discussion in the issue and on the list > > > Section 4.3 > > > > RFC 7252 doesn't really suggest that there's a protocol element that > would > > be set to "infinite" here; perhaps we should just say that "in this case, > > the gateway cannot return such a response and as such cannot > implement such > > a timeout". > > Text updated as suggested. > > > Section 5 > > > > With no integrity protection on the rejection of trial-and-error (section > > 2.2.2) it's susceptible to downgrade, IIUC even by an off-path attacker. > > (I did not think too hard about whether OSCORE could protect the > Resets in > > question or not, though.) It seems like such forced downgrade would have > > second-order effects in causing clients to use more local state and > thus be > > more readily susceptible to other DoS vecros. > > > > Also, when integrity protection is not in use, the client is > susceptible to > > spoofed responses that had no corresponding request -- only a very > limited > > subset of request/response pairs are safe to convert to "unauthenticated > > server push", as that would effectivley do, and we should probably > mention > > that explicitly. > > > > I'd also suggest noting that a self-encrypted state token bears > significant > > resemblance to a TLS self-encrypted session ticket, and reference the RFC > > 5077 security considerations. (Yes, I know that RFC 8446 Obsoletes RFC > > 5077; it would be an informational reference only.) > > > > This could also lead to some discussion about having in general an > > appropriate amount of sanity checks on the returned token that may or may > > not reflect serialized state, to limit the scope of various attacks > even in > > the absence of cryptographic protections. > > open as issue: https://github.com/core-wg/stateless/issues/5 > Text updated as per: > https://github.com/core-wg/stateless/commit/83535c69958467099cd20ca49d9bbb8e8cc03068 > and > https://github.com/core-wg/stateless/commit/83535c69958467099cd20ca49d9bbb8e8cc03068 > > > Section 5.1 > > > > size that need to be mitigated. A node in the server role supporting > > extended token lengths may be vulnerable to a denial-of-service when > > an attacker (either on-path or a malicious client) sends large tokens > > to fill up the memory of the node. Implementations need to be > > prepared to handle such messages. > > > > This seems particularly problematic given that we disallow sending > Reset in > > response to too-large tokens and instead imply that it should echo > the large > > token in a 4.00 response. I guess technically this is a SHOULD and not a > > MUST, so there is some leeway to do something else, but what would that > > "something else" be in this case? It seems like we have a hard > requirement > > to do something sane with a token as large as 65804 bytes. > > opened as https://github.com/core-wg/stateless/issues/6 > Discussion is that in order to receive such a large token, you have to > receive it. If you can receive such a large packet, then you can answer it. > As the token is never stored, there is no exhaustion attack possible. > closed as wontfix > > > Section 5.2 > > > > The use of encryption, integrity protection, and replay protection of > > serialized state is recommended, unless a careful analysis of any > > potential attacks to security and privacy is performed. [...] > > > > I suggest an alternative wording: > > > > % It is generally expected that the use of encryption, integrity > protection, > > % and replay protection for serialized state is appropriate. However, a > > % careful analysis of any potential attacks to the security and privacy > > % properties of the system might reveal that there are cases where such > > % cryptographic protections do not add value in a specific case. > > Text used as part of rewrite. > > > > a 64 bit tag is recommended, combined with a sequence number and a > > replay window. Where encryption is not needed, HMAC-SHA-256, > > combined with a sequence number and a replay window, may be used. > > > > Can we give guidance on sizing the replay window? > > Should the HMAC-SHA-256 output be truncated akin to the truncated CCM > tag? > > In what cases would one want to use an absolute timestamp instead of/in > > addition to a sequence-based replay window? > > issue opened as: https://github.com/core-wg/stateless/issues/7 > Replay recommendation/analysis is at: > https://github.com/core-wg/stateless/commit/b019c61e2b44757a4427956af95e99fbec15180e > updated by: > https://github.com/core-wg/stateless/commit/a7157fea61c3948899ded7311b5b0920cbd1b1c2 > and then today by: > https://github.com/core-wg/stateless/pull/15 > > > guarantees are voided. Devices with low-entropy sources -- as is > > typical with constrained devices, which incidentally happen to be a > > natural candidate for the stateless mechanism described in this > > > > nit: "low-entropy sources" is a weird phrasing; "low-quality entropy > > sources" would feel more natural to me. > > Also, draft-irtf-cfrg-randomness-improvements may be of interest to > at least > > some such devices. > > suggested text adopted. > > > > > provides the above uniqueness guarantee. Additionally, since it can > > be difficult to use AES-CCM securely when using statically configured > > keys, implementations should use automated key management [RFC4107]. > > > > This is BCP 107, so I think we could use stronger language than "should > > use". Also we should cite it as the BCP. > > open as https://github.com/core-wg/stateless/issues/8 > We removed the reference to RFC4107. > There is no reason to cite RFC4107, there is no key agreement needed. > The key is entirely a local manner, and a few pull requests referenced in > this ticket rewrite that text. > > > Section 6.1 > > > > Should the table formatting be consistent between here and Section 2.2.1? > > The tables look similar now. > From nobody Mon Nov 16 08:38:20 2020 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 C0A593A02BB for ; Mon, 16 Nov 2020 08:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 WMmZMdeiYlO7 for ; Mon, 16 Nov 2020 08:38:16 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E0A3A1293 for ; Mon, 16 Nov 2020 08:38:11 -0800 (PST) Received: from [192.168.217.120] (p548dcb31.dip0.t-ipconnect.de [84.141.203.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4CZZWP5S09zyTl; Mon, 16 Nov 2020 17:38:09 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <20201116092213.k2jzis7ycqjyi3zq@EMB-918HFH01> Date: Mon, 16 Nov 2020 17:38:09 +0100 Cc: Michael Koster , CoRE WG X-Mao-Original-Outgoing-Id: 627237489.182398-d14169b2644f2e58e9146dab64abad44 Content-Transfer-Encoding: quoted-printable Message-Id: <2CE9F4CA-5B42-4A90-A3D1-2F049BC7CBD8@tzi.org> References: <20201109144145.nzp2oqiam7bdlqed@EMB-918HFH01> <041E8922-F467-430B-957C-6BB193D8352F@gmail.com> <20201116092213.k2jzis7ycqjyi3zq@EMB-918HFH01> To: =?utf-8?Q?Jaime_Jim=C3=A9nez?= X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] Proposed new SenML Units X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 16 Nov 2020 16:38:19 -0000 > On 2020-11-16, at 10:22, Jaime Jim=C3=A9nez wrote: >=20 > thank you very much for your confirmation and insights on the topic. I = now wonder if we should add ug/l as well as NTU. For IPSO it looks like = NTU would be sufficient. Note that we already have =20 ug/m3 microgram per cubic meter kg/m3 1e-9 0 = [RFC8798] So adding ug/l would be like ug/l microgram per liter kg/m3 1e-6 0 This scaled unit of mass concentration is useful beyond Turbidity; e.g. = as in "the U.S. EPA set the maximum allowable concentration of lead in = public drinking water at 15 =C2=B5g/L=E2=80=9D (asciified as = =E2=80=9Cug/l=E2=80=9D). I think we could use an updated version of the original mail so we can = initiate registration from that. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Nov 16 14:00:19 2020 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 B42343A14FB for ; Mon, 16 Nov 2020 14:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 AoD6B6dthWNW for ; Mon, 16 Nov 2020 14:00:15 -0800 (PST) Received: from wforward4-smtp.messagingengine.com (wforward4-smtp.messagingengine.com [64.147.123.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35FA03A14FD for ; Mon, 16 Nov 2020 14:00:13 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailforward.west.internal (Postfix) with ESMTP id C44ADD6A; Mon, 16 Nov 2020 17:00:12 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 16 Nov 2020 17:00:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=vpRdjQcX7ElKsxewNeF5u0A12WuCthdPJ6z8fwqwX RM=; b=k6LRYJW+4ZesVR184mbTt0eE8lUQrBTYd1MiDZLjK/86w0GEtNfyF/I+i 3mh7h2hBEZePfUF29F/GXB9ReTr+ut3Xx7Bl6z/TmDd0UFybzKsTuY9EU1dBPMEE z5dwx3K01u1QZQKwfXvYFRY8b7yZr01+2j1pAyCckK26OZKXiclTlUriasDOP9s9 MSVSqQGAvhUzeaoUF13uptRKrGWP7bmDHGnswn1zrBqp7KkpQxMr7Eb0cdoFruRr P5FXaZK09SWOMO4CdcmdrhalpsSyHN7tkqBP8SVFtY96o48N8X2MNujbVLa9UEeh DN8rjZTpwmLVGoKh8yZn8SFqiC1oQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefuddgudehiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggugfgjsehtkeertddttdejnecuhfhrohhmpeflrghi mhgvucflihhmrohnvgiiuceojhgrihhmvgesihhkihdrfhhiqeenucggtffrrghtthgvrh hnpedtudduffdtueeugfegtdethfekffdtveekiedvveetudetgeegveeuvdegffffieen ucfkphepkedvrddvtdefrddvvdejrdduvdenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehjrghimhgvsehikhhirdhfih X-ME-Proxy: Received: from EMB-918HFH01 (82-203-227-12.bb.dnainternet.fi [82.203.227.12]) by mail.messagingengine.com (Postfix) with ESMTPA id 02F023280059; Mon, 16 Nov 2020 17:00:09 -0500 (EST) Date: Mon, 16 Nov 2020 23:59:49 +0200 From: =?utf-8?Q?Jaime=20Jim=C3=A9nez?= To: Carsten Bormann Cc: Michael Koster , CoRE WG Message-ID: <20201116215949.oh4qgsqymarq5fzq@EMB-918HFH01> References: <20201109144145.nzp2oqiam7bdlqed@EMB-918HFH01> <041E8922-F467-430B-957C-6BB193D8352F@gmail.com> <20201116092213.k2jzis7ycqjyi3zq@EMB-918HFH01> <2CE9F4CA-5B42-4A90-A3D1-2F049BC7CBD8@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2CE9F4CA-5B42-4A90-A3D1-2F049BC7CBD8@tzi.org> Archived-At: Subject: Re: [core] Proposed new SenML Units X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 16 Nov 2020 22:00:18 -0000 Hi Carsten, The updated version of the tables in the original email would be the ones below, please have a look and verify I did not intriduce new errors: On the SenML Units registry: +===========+================================+=======+ | Symbol | Description | Type | +===========+================================+=======+ | NTU | Nephelometric Turbidity Unit | Float | +-----------+--------------------------------+-------+ On the Secondary Units registry: +=========+======================+======+==========+======+ |Secondary| Description |SenML | Scale |Offset| | Unit | | Unit | | | +=========+======================+======+==========+======+ | ppb | parts per billion | / | 1e-9 | 0 | +---------+----------------------+------+----------+------+ | ppt | parts per trillion | / | 1e-12 | 0 | +---------+----------------------+------+----------+------+ | VAh | volt-ampere hour | VAs | 3600 | 0 | +---------+----------------------+------+----------+------+ | mg/l | milligrams per liter | kg/m3| 1/1000 | 0 | +---------+----------------------+------+----------+------+ | ug/l | microgram per liter | kg/m3| 1e-6 | 0 | +---------+----------------------+------+----------+------+ | g/l | grams per liter | kg/m3| 1 | 0 | +---------+----------------------+------+----------+------+ Ciao! -- Jaime On 16.11.2020 17:38, Carsten Bormann wrote: > > >> On 2020-11-16, at 10:22, Jaime Jiménez wrote: >> >> thank you very much for your confirmation and insights on the topic. I now wonder if we should add ug/l as well as NTU. For IPSO it looks like NTU would be sufficient. > >Note that we already have >ug/m3 microgram per cubic meter kg/m3 1e-9 0 [RFC8798] > >So adding ug/l would be like >ug/l microgram per liter kg/m3 1e-6 0 > >This scaled unit of mass concentration is useful beyond Turbidity; e.g. as in "the U.S. EPA set the maximum allowable concentration of lead in public drinking water at 15 µg/L” (asciified as “ug/l”). > >I think we could use an updated version of the original mail so we can initiate registration from that. > >Grüße, Carsten > From nobody Mon Nov 16 14:16:49 2020 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 367EE3A1549 for ; Mon, 16 Nov 2020 14:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 cT3RvcKkl9UZ for ; Mon, 16 Nov 2020 14:16:46 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9313A153D for ; Mon, 16 Nov 2020 14:16:28 -0800 (PST) Received: from [192.168.217.118] (p548dcb31.dip0.t-ipconnect.de [84.141.203.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4CZk1k3pXmzyTZ; Mon, 16 Nov 2020 23:16:26 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <20201116215949.oh4qgsqymarq5fzq@EMB-918HFH01> Date: Mon, 16 Nov 2020 23:16:25 +0100 Cc: Michael Koster , CoRE WG X-Mao-Original-Outgoing-Id: 627257785.868803-83f722296527a38ed8b51048db63ed86 Content-Transfer-Encoding: quoted-printable Message-Id: <922BCE09-874C-4445-9ACC-24740CB94FD4@tzi.org> References: <20201109144145.nzp2oqiam7bdlqed@EMB-918HFH01> <041E8922-F467-430B-957C-6BB193D8352F@gmail.com> <20201116092213.k2jzis7ycqjyi3zq@EMB-918HFH01> <2CE9F4CA-5B42-4A90-A3D1-2F049BC7CBD8@tzi.org> <20201116215949.oh4qgsqymarq5fzq@EMB-918HFH01> To: =?utf-8?Q?Jaime_Jim=C3=A9nez?= X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] Proposed new SenML Units X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 16 Nov 2020 22:16:48 -0000 On 2020-11-16, at 22:59, Jaime Jim=C3=A9nez wrote: >=20 > intriduce new errors: Something weird happened with the table lines. The units need to be singular, i.e., milligram, not milligrams. (For ppb, ppt we probably want to stay with =E2=80=9Cparts per=E2=80=A6=E2= =80=9D as this is vernacular anyway.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Nov 16 21:14:22 2020 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 D3BFB3A0DDC; Mon, 16 Nov 2020 21:14:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.22.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <160559005780.15243.11540146785094181824@ietfa.amsl.com> Date: Mon, 16 Nov 2020 21:14:17 -0800 Archived-At: Subject: [core] I-D Action: draft-ietf-core-stateless-08.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 05:14:20 -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 WG of the IETF. Title : Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP) Authors : Klaus Hartke Michael C. Richardson Filename : draft-ietf-core-stateless-08.txt Pages : 22 Date : 2020-11-16 Abstract: This document provides considerations for alleviating CoAP clients and intermediaries of keeping per-request state. To facilitate this, this document additionally introduces a new, optional CoAP protocol extension for extended token lengths. This document updates RFCs 7252 and 8323 with an extended definition of the TKL field in the CoAP message header. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-stateless/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-stateless-08 https://datatracker.ietf.org/doc/html/draft-ietf-core-stateless-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-stateless-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 16 21:16:24 2020 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 BAD2B3A0DDC; Mon, 16 Nov 2020 21:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8zWnSOK4L5O; Mon, 16 Nov 2020 21:16:17 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 008113A0DD5; Mon, 16 Nov 2020 21:15:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7EFF9389B2; Tue, 17 Nov 2020 00:16:24 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 644ef-gcS3cB; Tue, 17 Nov 2020 00:16:23 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EEAEE389A9; Tue, 17 Nov 2020 00:16:22 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 41DD3A76; Tue, 17 Nov 2020 00:15:32 -0500 (EST) From: Michael Richardson To: Benjamin Kaduk cc: The IESG , draft-ietf-core-stateless@ietf.org, core-chairs@ietf.org, core@ietf.org, Carsten Bormann In-Reply-To: <20201116120132.GW39170@kduck.mit.edu> References: <158741679923.20291.1071401061463555301@ietfa.amsl.com> <0c186080-6ac1-2a9d-1e0a-7cf3b3667d52@sandelman.ca> <20201116120132.GW39170@kduck.mit.edu> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-stateless-06: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 17 Nov 2020 05:16:20 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Benjamin Kaduk wrote: > Thanks; this looks good and I'm happy to clear the discuss (and will = do so > shortly). > A couple notes inline, and also one on the (nicely) expanded =C2=A75.= 2: > When encryption is used, the use of AES-CCM [RFC3610] with a 64-bit > tag is recommended, combined with a sequence number and a replay > window. This choice is informed by available hardware acceleration > of on many constrained systems. If a different algorithm is > available accelerated on the sender, with similar strength, then it > SHOULD be preferred. Where privacy of the state is not required, and > (similar strength or stronger, presumably). Right, I've added "or stronger" > On Thu, Nov 05, 2020 at 11:16:18AM -0500, Michael Richardson wrote: >> The ID submission system is closed, but we have a -08 ready. > (It's open again now!) I have posted -08 now. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+zXHMACgkQgItw+93Q 3WXcVwf7BuOtf71LXHQsBi03xDOQjs/yNwmtipdGnazEaMFm3m+RO6yAvo19IkzD K4nNErBdWMFg0QJ5O7hFHkib3/h9MpqNxRinotfWywsNATJKKanYqh0+4YzHbnCD o4Ueu7SVs6tteKc4/VZN1SGzboZnboKnfOL3slhzEPFCzCd1Ii8yVlXYzx6sUP/f Y8yqJYWm5weOknRirbmckQBXkmVFw77ChePjeL/XI3ZdQFZEWFzNecrfMqNsTG/r 92FfiGdBM/uyN6bAcWhuVKvpL9sq/cTN4z/8JoVm/RY3NVDaS0zigV9sOEngy1d2 maJomAQURB4Fl9VqeKCaaj5dPZEJJA== =1AQM -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 17 02:07:19 2020 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 6802C3A0DEE; Tue, 17 Nov 2020 02:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otz9IFu7yq6c; Tue, 17 Nov 2020 02:07:15 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6117E3A0DEF; Tue, 17 Nov 2020 02:07:10 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 58E654083B; Tue, 17 Nov 2020 11:07:08 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 20400AB; Tue, 17 Nov 2020 11:07:04 +0100 (CET) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:f94e:4afb:3326:ba58]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2991C180; Tue, 17 Nov 2020 11:07:03 +0100 (CET) Received: (nullmailer pid 2871458 invoked by uid 1000); Tue, 17 Nov 2020 10:07:02 -0000 Date: Tue, 17 Nov 2020 11:07:02 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: draft-tiloca-core-groupcomm-proxy@ietf.org Cc: Core WG mailing list Message-ID: <20201117100702.GA2838739@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline Archived-At: Subject: [core] Aligning groupcomm-proxy and mutlicast-notifications X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 17 Nov 2020 10:07:18 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Marco and Esko, =66rom today's CoRE meeting I've seen that the Response-Forwarding option has a similar structure as multicast-notifications' tp_info / Listen-To-Multicast-Responses option. Both share that they encode a host address (and possibly port) that isn't typically a name but really an address, and that the underlying protocol may not be fully understood by the client behind the proxy. The latter is not in groupcomm-proxy as it is now, but may make sense: All the client needs to know is that the host of the resource *is* actually a multicast address, not how that precisely works. (It may even take that information from somewhere else if the authority component is a host name which the client can't resolve). What makes this a bit tricky is that we don't have any other multicast-capable transport, but I imagine we could have. A related component that could play a role in the alignment is how the address is then encoded when contacting the host directly through the proxy. Unless the proxy is reverse (which is AFAIK not discussed at all, and may be worth discussing on its own), if the client still wants to use the proxy, it needs to set Proxy-Scheme: "coap" and Uri-Host: "2001:db8::1" from the data received as srv_info =3D [#6.260(h"20010db8...1")]. The information that goes into Proxy-Scheme would currently be hardcoded; if something like multicast-notifications' tp_info is used, that would be looked up from there. (Granted, when follow-up requests are used, even a client that knows the tp_info is mapped, but at least that could be an easy extension). Anything we come up with here that works for both our use cases might also be suitable for CRIs[1], which could then be a reusable component in converting back and forth between (Proxy-Scheme, Uri-Host) and something that contains binary IP addresses. BR c [1]: https://tools.ietf.org/html/draft-ietf-core-href-03 --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl+zoMMACgkQOY0REtOk veHTfhAAg5nUmvcBlg3gb46CHuG/qk6TrhsOKlB1mLCe6TX8e53tNv9mh/5jhJLA DIjoNj0ujUKuhZlVJiYPZqUJS1cZI7HIb2QDdtEvqFRq9aaIXg8y5Olmk68j8WI8 id4d+9KK9kKWzP4jfxkoQHzSMPIZvguQMZpKTtIMdNCFOe3dFEX3GYXMCVpNc+qv OBeoKISmA+FPS0TyHMHAN5a/GlBjyEXrWoDLfYCoKV1d/Rg+RjKSLuqgwSl3VXsC IPpfmKpU7QzlnjumfZyo1pUQ5nLfqrEnXRpGaNPutftbP3CdeV4O3zNje39lDHac ZtSgWo8Sc1bH7lV0QmlVUVz9QsqxadjEhSbtMqzuQGfPKLaoIJpBDTb45X6LOj/e 0746fkp8qW35nTDTatpD10/KH14huOIJ2+YwXtGTeQKqJeo6vYYlzoq7CWs+mIO4 MG+8w1NHhN+RdO69ttxeNAmzm4hmpOi8OR6j/xHXsWwnViX7oGwiJa5XwdzZo8Zt xHQ8eskrrNW/W/edngJiBC65Dp2FfLad9ICzuzi0xeDvaH9D2b9IiNwsnAdXSgxd 4Qjf+jbLknKO5V7cT4T9d7Su3dWzVxMv1hIQR2fXaT3MKxTA2zZwOqSOWKehT+zs LfTfVQBfNpE1bltTvMOiG8GKix+mfnL8VMZP390XOd9cDbQ4o+I= =2R3b -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- From nobody Tue Nov 17 05:12:04 2020 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 4B1093A104A; Tue, 17 Nov 2020 05:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancy.nl 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 D9U3hCQk__8W; Tue, 17 Nov 2020 05:12:00 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2108.outbound.protection.outlook.com [40.107.20.108]) (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 E58F93A1072; Tue, 17 Nov 2020 05:11:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e00DPMAqrlFJQJVS/74txC6uKHuoMu97n7zwl7/nNYsJmf5Ds4vBRPM7xzFfsZL5vUiS692FXJLbcbLWwhPsftHfwnC6jDtqYoymLJpdUJ4pLX0AvffJSA7klsqMUt1KuNVdtWsBZ5XIHdmkAx4iLsmDI5xDwK8x5mxyMWHXLj6x2ZLfa3BgHsHQVbH6m8tNDhpk4BDHF++uJ9QjAcNDckabKsVbyFzDANkMYdW3o7/etUc1IZV4MOsI1A2Ffu3W5aIFO8Ra5W7XjzGev4k94MwiIGCIxE+3EPmbqCGNRQZZ8H3njk/ClJ5bqjLeVEYYp2yBhfHMZS18b+qO4Q5Glw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qHGjuILOyymcEvTGS14AKAi351E9SZPU0AVg7BDVaCY=; b=dFIiyVFAqlh3YzZd3AjrAtJU0/s6x+yyfceCfuGJFu0Pc+YzK3jaKSmxn0x3P2l31CIecLSCJlH3v64LBElg/5vig6S5XPhkxf2rgDK0cndc0D/MtmRGItQVBYk7REmfamchuVcKFWuQU4Sfjgp7FZThzbLrOVZEqziupbOh05/ahH3qxdHobNcsPvAYbCCp0XnEln4pKd4Q5O/b81r1YIZwdPJxp++hMRqfmd63Bk9s3M8KS64WHd5CKNvV+6f+NQCHUegLczHXc/GOQLrocWNkl+pXe3B21o2+GjVmzM0tu+8lfz6OrpNDfIo+ClKDERP3vWAi2RhkQLyIqdveVA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qHGjuILOyymcEvTGS14AKAi351E9SZPU0AVg7BDVaCY=; b=OrTwBP98dLjWX+vYD8nvnCyfEdM35zrOqNLSwQn//zcwz2yIHwxW4cgzbnpbthDIh5Rsx7iHaLAEuVkgKVR1YdEduMIiLzdNUTtU0CyFqiMxByWclVgXMWwM/I3gjyoTgzUyS0jcfluvEY4B4HG5ij7vaQnTwQu+T4AC9e+vpjo= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM9P190MB1123.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:271::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.25; Tue, 17 Nov 2020 13:11:55 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa%5]) with mapi id 15.20.3564.028; Tue, 17 Nov 2020 13:11:55 +0000 From: Esko Dijk To: =?utf-8?B?Q2hyaXN0aWFuIE0uIEFtc8O8c3M=?= , "draft-tiloca-core-groupcomm-proxy@ietf.org" CC: Core WG mailing list Thread-Topic: Aligning groupcomm-proxy and mutlicast-notifications Thread-Index: AQHWvMlxnySWq+fjv0Kz7WycfqkXoKnMRS9Q Date: Tue, 17 Nov 2020 13:11:55 +0000 Message-ID: References: <20201117100702.GA2838739@hephaistos.amsuess.com> In-Reply-To: <20201117100702.GA2838739@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: amsuess.com; dkim=none (message not signed) header.d=none;amsuess.com; dmarc=none action=none header.from=iotconsultancy.nl; x-originating-ip: [2001:1c02:3103:f000:f468:4e0f:12c6:19f7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 88d1dd61-efb1-4abb-525d-08d88afa5bb6 x-ms-traffictypediagnostic: AM9P190MB1123: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0MTcjQsirf1XfB8UbUnjH8EatyYW/se6TjkzRr9c6ZIfmeO/CKvYrfKjXzJBfdF3rC33XqCDdGcfktTBYAaIKnpxaIUn/b02ptEG6UPQJi7sAQBtic4oygNu+uf1sxJ6KjNjKsimXI8e1qqqgJ4bydMi90Thy6C0zCwc1zV9K/717jmETQJfEllcqLDkFILf2qni18dz1/DDAk0yu/daEUzBP87odRBM0meugeBj2ks7Dsovg8hh5KMcPW2wJmTUM3+WCLd3XdxykZVAZoe1cncOdETcs0rz2W/LUsmqP1EG51ZJvHvoohui1z979v3ghlnLUrugElAiUWnbXSIeMvuh1XN2Okez7uh8mKGF20dHHwUCW1lu6j2IAYcKUIdch0TrzTs32Rr9dI/2phfGKw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(346002)(136003)(366004)(396003)(39830400003)(33656002)(478600001)(86362001)(66574015)(83380400001)(55016002)(2906002)(53546011)(5660300002)(186003)(66946007)(66556008)(64756008)(76116006)(66476007)(52536014)(9686003)(66446008)(15650500001)(71200400001)(44832011)(6506007)(110136005)(966005)(316002)(7696005)(8676002)(8936002)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: eQmmWA2DH7rMEksOIe9mSpFGvgcgPHYRNNs99dCP+epBBIn1a/fGTHVTa1etxz2RP/n0xfhgTzWNrBPVsUz5ojSG0o0iLvGCRAU6ViNORSOleHdlZp1XohT7mBfV+j1IdLMEJ3bfv7ZQoYcwS6FsIZQKmN73J9RX/lmzMlBkg4IvfAMSg49tftPcTkW+1BGt0FQ7m8KAkEsc3r7UKax+NcpDNBiDccXf0cD/CklHlv3EJ55gUrKdvqR0GYQONKaRtgUlMFSAgdq4HhuLix0meupNQZv0S599H6pU54f1V1KJExemXmH0XaiaG8JnNntBw/cn7npLn/hPGAPk5s6FqwBTkZgGpkPteaGnEWCILjGrD5f0iQOEzjLri1MAoFxE3GQLs86H9hRQ1O2klT60pRw9Fz2ifXm97HZ2vrOP+Kfchkfj2nfUFTuzYLj4X58c3jykTgqlkUSAyl8lz6Vd635rhnOL8n5d08bfeOiDbJN4hnzsU3jeefPuELph9U1uudisrX6z2r8Ncn5NquRczKt+Qq/N3rLtb5Ti+0DdBzek6t+Ua7UL6hDpSIv8X+scecWJbD8J7fRwok2FzDtwoRAGKVZChTZiwqKcfZPLsARqPZw/Blrz2XHYyerO+kbgOhagn+RKrOvpcCzsk2Cf7z20eb4FJ1ENGTTBP3sCcy0SKK4kwsXcHwkqbeMb8a8Dmlr1zMhoVX5woqE8yWPzgw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 88d1dd61-efb1-4abb-525d-08d88afa5bb6 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2020 13:11:55.7111 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZZO7YZnuXNoT4voqc4Cy9IrfnlD0k3hbLyIVUQ9UL+LfsF3OMSgSdMAcDKtN1bab5M2kObm+gOipOzde6eKXW8EPX25ALezqL43vuDc4Zng= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1123 Archived-At: Subject: Re: [core] Aligning groupcomm-proxy and mutlicast-notifications X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 17 Nov 2020 13:12:02 -0000 SGVsbG8gQ2hyaXN0aWFuLA0KDQpZZXMgdGhlcmUncyBzb21lIHNpbWlsYXJpdHkgaW4gdGhlIG9w dGlvbnMuIEluIGRyYWZ0LWdyb3VwY29tbS1wcm94eSBvbmx5IGEgZm9yd2FyZC1wcm94eSBpcyBj b25zaWRlcmVkLCB3aGljaCBtZWFucyB0aGUgY2xpZW50IGlzIGV4cGxpY2l0bHkgYXdhcmUgb2Yg dGhlIHByb3RvY29sIHVzZWQgYnkgdGhlIHByb3h5LiAoRW5jb2RlZCBpbiBlaXRoZXIgdGhlIFBy b3h5LVVyaSBvciBQcm94eS1TY2hlbWUgb3B0aW9uLikNCkZvciB0aGlzIHJlYXNvbiB0aGVyZSB3 YXMgbm8gbmVlZCB0byBpbmNsdWRlIHNjaGVtZSBpbmZvcm1hdGlvbiBpbiB0aGUgUmVzcG9uc2Ut Rm9yd2FyZGluZyBvcHRpb24gYXMgdGhlIGNsaWVudCB3b3VsZCBhbHJlYWR5IGtub3cgdGhpcy4N Cg0KSW4gY2FzZSB0aGUgc2NoZW1lIGluZm9ybWF0aW9uIGlzIGVuY29kZWQgaW4gYSBjb21wYWN0 IGZvcm0gKGUuZy4gYSBzaW5nbGUgQ0JPUiB1aW50IGFzIGluIG11bHRpY2FzdC1ub3RpZmljYXRp b25zKSBpdCBjb3VsZCBzdGlsbCBiZSBpbmNsdWRlZCBpbiB0aGUgT3B0aW9uIGZvcm1hdCBJIHRo aW5rLCBpZiB0aGF0IHdvdWxkIGhlbHAgdGhlIGFsaWdubWVudCBhbmQgcmUtdXNlIG9mIHRoZSBP cHRpb24gZm9yIG11bHRpcGxlIHVzZSBjYXNlcy4NCg0KUmV2ZXJzZSBwcm94aWVzIG1pZ2h0IGFs c28gYmUgY29uc2lkZXJlZCBmb3IgZ3JvdXBjb21tLXByb3h5OyBzZWUgYWxzbyBTZWN0aW9uIDgu NCBpbiBSRkMgODA3NS4gVGhpbmtpbmcgb3V0IGxvdWQsIHRoZXJlIGNvdWxkIGJlIGEgcHJveHkg c2VydmVyIHRoYXQgaXMgZGVzaWduZWQgbGlrZSB0aGlzOg0KKiByZWd1bGFyIHJlc291cmNlcyAv cmVzbSBtYXBzIHRvIGEgbXVsdGljYXN0IENvQVAgcmVxdWVzdCBiZWluZyBleGVjdXRlZA0KKiBj bGllbnQgdGhhdCBpbnZva2VzIGEgbWV0aG9kIG9uIC9yZXNtIHdpdGhvdXQgdXNpbmcgJ011bHRp Y2FzdC1TaWduYWxpbmcnIE9wdGlvbiBnZXRzIGFuIGVycm9yIGJhY2sgYW5kIGEgJ011bHRpY2Fz dC1TaWduYWxpbmcnIE9wdGlvbiBpbiB0aGUgcmVzcG9uc2UgdG8gaW5kaWNhdGUgdGhhdCB0aGlz IGlzIG5lZWRlZC4NCiogY2xpZW50IGNhbiBpbnZva2UgYSBtZXRob2Qgb24gL3Jlc20gd2l0aCAn TXVsdGljYXN0LVNpZ25hbGluZycgT3B0aW9uIHRvIGxldCB0aGUgcHJveHkgd29yay4gTXVsdGlw bGUgcmVzcG9uc2VzIHdpbGwgY29tZSBiYWNrIHRvIHRoZSBjbGllbnQuIA0KKiB0aGUgcHJveHkg bWF5IGhhdmUgc2VsZWN0ZWQgdGhlIG11bHRpY2FzdCBncm91cCB0byBzZW5kIHRvIGJ5IGl0c2Vs ZiwgYmFzZWQgb24gY2hvaWNlIG9mIC9yZXNtIGJ5IHRoZSBjbGllbnQuDQoNCk9yIGEgdmFyaWF0 aW9uIG9uIGFib3ZlOg0KKiBwcm94eSBzZWxlY3RzIHRoZSBtdWx0aWNhc3QgZ3JvdXAgYW5kIHJl c291cmNlIGJhc2VkIG9uIHRoZSBVUkkgcGF0aCwgaS5lLiBpdCBpcyBlbWJlZGRlZCBpbiB0aGUg VVJJLCBzaW1pbGFyIHRvIFNlY3Rpb24gNSBvZiBSRkMgODA3NSAuICBUaGlzIGNhbiB3b3JrIHRv d2FyZHMgSFRUUCBjbGllbnRzIGJ1dCBhbHNvIHRvd2FyZHMgQ29BUCBjbGllbnRzLiAgKEZvciB0 aGUgbGF0dGVyOiBpZiBmb3Igc29tZSByZWFzb24gdGhleSBjYW4ndCB1c2UgdGhlIGZvcndhcmQt cHJveHkgZnVuY3Rpb24gb2YgQ29BUCBlLmcuIGJlY2F1c2UgdGhlaXIgbGlicmFyeSAvIEFQSSBk b2Vzbid0IHN1cHBvcnQgaXQuKQ0KDQpFc2tvDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBDaHJpc3RpYW4gTS4gQW1zw7xzcyA8Y2hyaXN0aWFuQGFtc3Vlc3MuY29tPiANClNl bnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDE3LCAyMDIwIDExOjA3DQpUbzogZHJhZnQtdGlsb2NhLWNv cmUtZ3JvdXBjb21tLXByb3h5QGlldGYub3JnDQpDYzogQ29yZSBXRyBtYWlsaW5nIGxpc3QgPGNv cmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBBbGlnbmluZyBncm91cGNvbW0tcHJveHkgYW5kIG11dGxp Y2FzdC1ub3RpZmljYXRpb25zDQoNCkhlbGxvIE1hcmNvIGFuZCBFc2tvLA0KDQpmcm9tIHRvZGF5 J3MgQ29SRSBtZWV0aW5nIEkndmUgc2VlbiB0aGF0IHRoZSBSZXNwb25zZS1Gb3J3YXJkaW5nIG9w dGlvbg0KaGFzIGEgc2ltaWxhciBzdHJ1Y3R1cmUgYXMgbXVsdGljYXN0LW5vdGlmaWNhdGlvbnMn IHRwX2luZm8gLw0KTGlzdGVuLVRvLU11bHRpY2FzdC1SZXNwb25zZXMgb3B0aW9uLg0KDQpCb3Ro IHNoYXJlIHRoYXQgdGhleSBlbmNvZGUgYSBob3N0IGFkZHJlc3MgKGFuZCBwb3NzaWJseSBwb3J0 KSB0aGF0DQppc24ndCB0eXBpY2FsbHkgYSBuYW1lIGJ1dCByZWFsbHkgYW4gYWRkcmVzcywgYW5k IHRoYXQgdGhlIHVuZGVybHlpbmcNCnByb3RvY29sIG1heSBub3QgYmUgZnVsbHkgdW5kZXJzdG9v ZCBieSB0aGUgY2xpZW50IGJlaGluZCB0aGUgcHJveHkuDQoNClRoZSBsYXR0ZXIgaXMgbm90IGlu IGdyb3VwY29tbS1wcm94eSBhcyBpdCBpcyBub3csIGJ1dCBtYXkgbWFrZSBzZW5zZToNCkFsbCB0 aGUgY2xpZW50IG5lZWRzIHRvIGtub3cgaXMgdGhhdCB0aGUgaG9zdCBvZiB0aGUgcmVzb3VyY2Ug KmlzKg0KYWN0dWFsbHkgYSBtdWx0aWNhc3QgYWRkcmVzcywgbm90IGhvdyB0aGF0IHByZWNpc2Vs eSB3b3Jrcy4gKEl0IG1heSBldmVuDQp0YWtlIHRoYXQgaW5mb3JtYXRpb24gZnJvbSBzb21ld2hl cmUgZWxzZSBpZiB0aGUgYXV0aG9yaXR5IGNvbXBvbmVudCBpcw0KYSBob3N0IG5hbWUgd2hpY2gg dGhlIGNsaWVudCBjYW4ndCByZXNvbHZlKS4gV2hhdCBtYWtlcyB0aGlzIGEgYml0DQp0cmlja3kg aXMgdGhhdCB3ZSBkb24ndCBoYXZlIGFueSBvdGhlciBtdWx0aWNhc3QtY2FwYWJsZSB0cmFuc3Bv cnQsIGJ1dA0KSSBpbWFnaW5lIHdlIGNvdWxkIGhhdmUuDQoNCkEgcmVsYXRlZCBjb21wb25lbnQg dGhhdCBjb3VsZCBwbGF5IGEgcm9sZSBpbiB0aGUgYWxpZ25tZW50IGlzIGhvdyB0aGUNCmFkZHJl c3MgaXMgdGhlbiBlbmNvZGVkIHdoZW4gY29udGFjdGluZyB0aGUgaG9zdCBkaXJlY3RseSB0aHJv dWdoIHRoZQ0KcHJveHkuIFVubGVzcyB0aGUgcHJveHkgaXMgcmV2ZXJzZSAod2hpY2ggaXMgQUZB SUsgbm90IGRpc2N1c3NlZCBhdCBhbGwsDQphbmQgbWF5IGJlIHdvcnRoIGRpc2N1c3Npbmcgb24g aXRzIG93biksIGlmIHRoZSBjbGllbnQgc3RpbGwgd2FudHMgdG8NCnVzZSB0aGUgcHJveHksIGl0 IG5lZWRzIHRvIHNldCBQcm94eS1TY2hlbWU6ICJjb2FwIiBhbmQgVXJpLUhvc3Q6DQoiMjAwMTpk Yjg6OjEiIGZyb20gdGhlIGRhdGEgcmVjZWl2ZWQgYXMgc3J2X2luZm8gPQ0KWyM2LjI2MChoIjIw MDEwZGI4Li4uMSIpXS4gVGhlIGluZm9ybWF0aW9uIHRoYXQgZ29lcyBpbnRvIFByb3h5LVNjaGVt ZQ0Kd291bGQgY3VycmVudGx5IGJlIGhhcmRjb2RlZDsgaWYgc29tZXRoaW5nIGxpa2UgbXVsdGlj YXN0LW5vdGlmaWNhdGlvbnMnDQp0cF9pbmZvIGlzIHVzZWQsIHRoYXQgd291bGQgYmUgbG9va2Vk IHVwIGZyb20gdGhlcmUuIChHcmFudGVkLCB3aGVuDQpmb2xsb3ctdXAgcmVxdWVzdHMgYXJlIHVz ZWQsIGV2ZW4gYSBjbGllbnQgdGhhdCBrbm93cyB0aGUgdHBfaW5mbyBpcw0KbWFwcGVkLCBidXQg YXQgbGVhc3QgdGhhdCBjb3VsZCBiZSBhbiBlYXN5IGV4dGVuc2lvbikuDQoNCkFueXRoaW5nIHdl IGNvbWUgdXAgd2l0aCBoZXJlIHRoYXQgd29ya3MgZm9yIGJvdGggb3VyIHVzZSBjYXNlcyBtaWdo dA0KYWxzbyBiZSBzdWl0YWJsZSBmb3IgQ1JJc1sxXSwgd2hpY2ggY291bGQgdGhlbiBiZSBhIHJl dXNhYmxlIGNvbXBvbmVudA0KaW4gY29udmVydGluZyBiYWNrIGFuZCBmb3J0aCBiZXR3ZWVuIChQ cm94eS1TY2hlbWUsIFVyaS1Ib3N0KSBhbmQNCnNvbWV0aGluZyB0aGF0IGNvbnRhaW5zIGJpbmFy eSBJUCBhZGRyZXNzZXMuDQoNCkJSDQpjDQoNClsxXTogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtY29yZS1ocmVmLTAzDQoNCi0tIA0KVG8gdXNlIHJhdyBwb3dlciBpcyB0 byBtYWtlIHlvdXJzZWxmIGluZmluaXRlbHkgdnVsbmVyYWJsZSB0byBncmVhdGVyIHBvd2Vycy4N CiAgLS0gQmVuZSBHZXNzZXJpdCBheGlvbQ0K From nobody Tue Nov 17 05:45:56 2020 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 B1B3A3A130E for ; Tue, 17 Nov 2020 05:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancy.nl 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 cspUDEwzHQI0 for ; Tue, 17 Nov 2020 05:45:52 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130104.outbound.protection.outlook.com [40.107.13.104]) (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 8BBF93A10B5 for ; Tue, 17 Nov 2020 05:45:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I2jBnq5vNy3QARPdFJPA6cOicJzAzroXlmzSLic0ep1rgINRzF5jfPFytFcK/mxVpnH/vqjPGKV+bXIiCqMtnsIAjd0cdcVW5ncGtvEhTKtw0okuXWfwWEmv/92YSUrdFBo5bmXpenVdZLZbb5u1yyBAjkHcAKeKqjfbf3czvp0jnEcIoNP7hnzTCK7F0AVZwCjcqWxntmw7dE81SwstBhcRAHxnJlwhpQQ4pTyc6wUOKs+aky+mmLAp0sCwnlw1w337JzpaZhA4/ihoJb64j8jtjOrHEs8XT/yqcAwPZhgf2TxQIyue1GIrx1bNanswr7suNpDHsPQxybxfWI3I5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oesfxwstXF2/ut0lJv615LqwNwyi5uITmHvfRQXimUY=; b=ZR8hpM6pfSCDY3YPBRQhTAvNLqIW6Kw+MTe3Pv5LaPL/9OLUMEPiVnqUXU3shtFH4G7UqbudC3HKJP5htlG8nViyhksD1FU+Uowt+vGJrJeOIkUTKgkqipp/scV+lg0WKaHvLdNDSSNxN1L+7ybwzwEFDPJzZJ2nZ4K3Jm4Ts4w909tngk1QcszO7n6M7OzDkI5VGGCIgN5as1CinJdzYA9bA/eadPBAdW0eneVgUSdGxM0/tl9Zd0R1m0Rt3S6huNqNxsdewJvga/XiaRk5iLk5DVnEqzqs+eb0jbbZT7M6JRqP9Vh3VD3BOTNkySkKMbXodQhSix72nT9teG50CQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oesfxwstXF2/ut0lJv615LqwNwyi5uITmHvfRQXimUY=; b=IsZ1qsVsVGlNYevzNzlpkJtJvQOxzcIzCOr6SIyA75ELWg9WxLTuWxnqkYR0jwwWtzctGIx1OBynuy7KGoRipoCRHhsWH3CwaTJ51Hu6HbfZczTSkAA1g30mj+KbjkBGnMIsGqWkEGwtkRVRfg0dIPhvFLzB/fOWTU2CdlstEJg= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM8P190MB0996.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1c7::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.25; Tue, 17 Nov 2020 13:45:47 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa%5]) with mapi id 15.20.3564.028; Tue, 17 Nov 2020 13:45:47 +0000 From: Esko Dijk To: "Turner, Randy" , "core@ietf.org WG" Thread-Topic: CoAP - HTTP proxies Thread-Index: Ada5CpldoJFysbEKQ4GMv/OUtyIXswD2iFXg Date: Tue, 17 Nov 2020 13:45:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_ActionId=5f3fde0f-7e7a-4960-bcfa-c30f3a5935bd; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_ContentBits=0; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_Enabled=true; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_Method=Standard; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_Name=724d29b2-602f-4b77-ba15-b7b42511c7c5; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_SetDate=2020-11-12T15:43:21Z; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_SiteId=ee2cd48b-958f-4be4-9852-b8f104c001b9; authentication-results: landisgyr.com; dkim=none (message not signed) header.d=none;landisgyr.com; dmarc=none action=none header.from=iotconsultancy.nl; x-originating-ip: [2001:1c02:3103:f000:f468:4e0f:12c6:19f7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e123632b-5e0b-43f4-7401-08d88aff16c9 x-ms-traffictypediagnostic: AM8P190MB0996: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qIg692bKSyiKQBQd9F2Gt4GPE/0ZqTIvbDfFNRWzoewsGANb6MOVHztPISv6AH77xV0aiybiUR30DIoV6TpnX/mJBychnBunth8hmimDXzAU6vmKVSiQhfhpZRLOPxLw7kshWdnlAZLE+D9KLFZ4C/FNG9naI5S/3OFse2WNq/gRA78ag3TP46vAvWI9ogEhCkcYBJ3O/btYsW2dUv9ey73V5at863oVfwlIzw3E3kim7xqaDkIuOcJ6IO5JX9nyP328MKWHap+pcS1j8QgVJPFl6PjcC0TINsbFXl5ybxpdBGPHHiAcDbKL3QmIOc6bwjsOtb/J9M24ltLTlkZY/6hAIjKf0cVkr36unvaY1XE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(376002)(366004)(346002)(396003)(39830400003)(5660300002)(71200400001)(166002)(55016002)(8936002)(8676002)(86362001)(9326002)(52536014)(83380400001)(9686003)(966005)(33656002)(7696005)(186003)(66556008)(66446008)(6506007)(53546011)(76116006)(66476007)(64756008)(66946007)(478600001)(316002)(44832011)(2906002)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: tC6ocS9l5ORb++W03KExCmyUllFwXpAPv26r+UuyVtVw/hJZyM1XGM9bnczQ/Y8Tv9cH6ueFtjsxoNtO6hTDCPUrHRtwd6lvNOmiM8m6Bj8o8NrWsVUv4r4giO6tKuKVhG6ip0COxZVS2HWtLfq2oB8FWcIBuXzTV/Ut3QVUWO+7c3ynMESWLAmqjBgs0Wc84W8wmWMv8CHVFycU/NqOXacwcux//TLp628IMHFvW1WvzlSipnAgW6lxvkO0YutltKGgdE34VFUM7HX83dE31TBFjSuWGsFDYctAOt9ZrCJR7S5CDnOJuNy6/kRDLdRTSF4Z4mmdSO2wh7L/+S1z85Zt6QRrFKUN4LM/mhek7lSOfhkoMj8EDBuJLC0mvmaCYUitaYOo6KWYt+oT1apVZtv8RrUH4CKpqyJa2W/Z2eFmC6d8fid4XpL9dExseLyCrlpBdQUlupU7/Lv63+HPAMYaNqOiurNk3wV0D9IYr6/U7qK6AwekLL8E5qv7re7Dfv9fnTLyK3r1AzxIS25a1uJPxcvuGNV4uuYZDVjaop1eJhV3eOkhusheQ09JIVaZ7Pxw0mVh12YLisdw6HgiONWHW8Q6LMyyY+kRZP0Ipd3yKkEZaEqE0Ys06ShaiRMyxa6AX6WGHzKf3itHYR0lNc1f0CKYlv5DIYajQP8dvSB0O4KXQZEVf4sAUygo8vWyAZvpOt8/xn7XyjLfRc+Ndg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM8P190MB0979E2F72757878CCFFBD2C0FDE20AM8P190MB0979EURP_" MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: e123632b-5e0b-43f4-7401-08d88aff16c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2020 13:45:47.5454 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: htZ9OimqZIhk6e9hX1Qe+2t2CDPsmX8MF2GkK09h8ECNKukXLcpvyxH82TJsK2Cd9Eh235Z9Dqnaz/mCUSlRrZGBPHpycZEJ7I5Z4lIotAg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8P190MB0996 Archived-At: Subject: Re: [core] CoAP - HTTP proxies X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 17 Nov 2020 13:45:55 -0000 --_000_AM8P190MB0979E2F72757878CCFFBD2C0FDE20AM8P190MB0979EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gUmFuZHksDQoNClRoZSBSZWdpc3RyYXIgZGVzY3JpYmVkIGluIFNlY3Rpb24gNiBvZiBk cmFmdC1hY2UtY29hcC1lc3QgaXMgaW5kZWVkIGRvaW5nIHNvbWUgcHJveHlpbmcsIGJ1dCBpdCBp cyBhIGhpZ2hseSBzcGVjaWZpYyBzb3J0IG9mIHByb3h5IGFuZCBjZXJ0YWlubHkgbm90IGdlbmVy aWM6DQoNCiAgKiAgIEl0IHBlcmZvcm1zIHNvbWUgY29udGVudCBjb252ZXJzaW9ucyB0by9mcm9t IEJhc2U2NCBlbmNvZGluZw0KICAqICAgSXQgcGVyZm9ybXMgZGVkaWNhdGVkIFVSSSBwYXRoIGNv bnZlcnNpb24gYXMgcGVyIFRhYmxlIDENCiAgKiAgIEl0IHVzZXMgYSBjZXJ0aWZpY2F0ZSB0aGF0 IGlzIGZsYWdnZWQgYXMgYW4g4oCYUkHigJkgKFJlZ2lzdHJhdGlvbiBBdXRob3JpdHkpICwgYm90 aCB0b3dhcmRzIHRoZSBIVFRQIEVTVCBzZXJ2ZXIgYW5kIHRvd2FyZHMgdGhlIENvYXAgY2xpZW50 cy4gIEl0IHdvdWxkIGJlIHVubGlrZWx5LCBpbiB0ZXJtcyBvZiBzZWN1cml0eSwgdGhhdCB0aGUg UmVnaXN0cmFyL3Byb3h5IHdvdWxkIHByb3h5IGFyYml0cmFyeSBhcHBsaWNhdGlvbiByZXF1ZXN0 cyBmb3Igb3RoZXJzIHVzaW5nIHN1Y2gg4oCYYXV0aG9yaXR54oCZIGNyZWRlbnRpYWxzLg0KDQoq IFRoZSBUTFMgY3JlZGVudGlhbHMgdGhhdCBhIGdlbmVyaWMgcHJveHkgd291bGQgdXNlIHRvd2Fy ZHMgSFRUUCBzZXJ2ZXJzLCBtaWdodCBiZSBzb21lIGFwcGxpY2F0aW9uL2RlcGxveW1lbnQgc3Bl Y2lmaWMgY3JlZGVudGlhbHMgdGhhdCBoYXZlIHN1ZmZpY2llbnQgcHJpdmlsZWdlcyB0byBleGVj dXRlIGFsbCBpbnRlbmRlZCBwcm94aWVkIHJlcXVlc3RzIGJ1dCBub3QgbW9yZSB0aGFuIHRoYXQu DQoNCiAgKiAgIOKApiB0aGVyZSBtYXkgYmUgbW9yZS4NCg0KQnV0IGRlc3BpdGUgb2YgdGhpcywg Z2VuZXJpYyBwcm94eSBmdW5jdGlvbnMgY291bGQgYmUgX2FkZGVkXyB0byBhYm92ZSBSZWdpc3Ry YXI6DQoNCiAgKiAgIEEgZm9yd2FyZC1wcm94eSByZXF1ZXN0IHdpdGggYSBQcm94eS1Vcmkgb3Ig UHJveHktU2NoZW1lIE9wdGlvbiBpbmRpY2F0aW5nIOKAmGh0dHAocynigJkgc2NoZW1lIGNhbiBi ZSBlYXNpbHkgaWRlbnRpZmllZCBhbmQgcHJvY2Vzc2VkIHNlcGFyYXRlbHkgZnJvbSBhYm92ZSBm dW5jdGlvbnMuDQogICogICBUaGUgcHJveHkgY291bGQgdXNlIGEgZGlmZmVyZW50IFRMUyAoY2Vy dGlmaWNhdGUpIGlkZW50aXR5IGZvciBwZXJmb3JtaW5nIHRoZXNlIHByb3h5IHJlcXVlc3RzLCBp biBIVFRQIGNsaWVudCByb2xlLiAgKFNvIG5vdCB1c2UgdGhlIFJBLWNlcnRpZmljYXRlIGluIHRo aXMgY2FzZSBidXQgc3dpdGNoIHRvIGFub3RoZXIgaWRlbnRpdHkgbW9yZSBzdWl0YWJsZSBmb3Ig dGhlIGdpdmVuIHRvLWJlLXNlbnQgSFRUUCByZXF1ZXN0LikNCiAgKiAgIEEgcmV2ZXJzZS1wcm94 eSByZXF1ZXN0IGNvdWxkIGFsc28gYmUgc2VydmVkIGZyb20gYSBkZWRpY2F0ZWQgcmVzb3VyY2Uu DQoqICBlLmcuIGEgQ29BUCByZXF1ZXN0IHRvIHJlc291cmNlIC9jaC9odHRwL3MuZXhhbXBsZS5j b20vbGlnaHQgIGlzIHRyYW5zbGF0ZWQgYnkgdGhlIHJldmVyc2UtcHJveHkgaW50byBhIGh0dHAg cmVxdWVzdCBodHRwOi8vcy5leGFtcGxlLmNvbS9saWdodCAuICBUaGUgc3ludGF4IGhlcmUgaXMg Ym9ycm93ZWQgZnJvbSBSRkMgODA3NSB3aGljaCB1bmZvcnR1bmF0ZWx5IG9ubHkgZGVzY3JpYmVz IHRoZSBIVFRQLT5Db0FQIGRpcmVjdGlvbiBub3QgdmljZSB2ZXJzYSEgQnV0IHRoZSBzYW1lIG1h cHBpbmcgaWRlYXMgY2FuIGJlIGFwcGxpZWQuIFRvIGRvIDopDQoNClNvIGZvciDigJwx4oCdIHBy b3h5IHRvIGRvIGJvdGgsIGl0IHdpbGwgYWx3YXlzIG5lZWQgc3BlY2lhbC1jYXNlIGNvZGUgZm9y IEVTVC10by1Db0FQIGFuZCBpdCBtYXkgYWxzbyBuZWVkIHRvIGJlIGNvbmZpZ3VyZWQgd2l0aCBt dWx0aXBsZSAoPj0yKSBpZGVudGl0aWVzIGZvciBzZWN1cml0eSByZWFzb25zLiBUaGUg4oCYUkHi gJkgaWRlbnRpdHkgd291bGQgYmUgdXNlZCBvbmx5IG9uIHRoZSBUTFMgY29ubmVjdGlvbiB0b3dh cmRzIEhUVFAtRVNULVNlcnZlciwgbm90IGZvciBhcmJpdHJhcnkgcHJveGllZCByZXF1ZXN0cy4N CklmIHdlIHdvdWxkIGxpa2UgYSBmdWxseSBnZW5lcmljIHByb3h5IHRvIGJlIHVzZWQgYXMgdGhl IOKAmFJlZ2lzdHJhcuKAmSBpbiB0aGUgQ29BUCBkb21haW4gLCB3aXRob3V0IGRvaW5nIHRoZSBz cGVjaWFsIHRyYW5zbGF0aW9ucywgdGhlbiB0aGUgRVNULXRvLUNvQVAgZHJhZnQgd291bGQgbmVl ZCBzb21lIHNldmVyZSBlZGl0cyBhbmQgcmV0aGlua2luZywgSSBndWVzcy4NCg0KQmVzdCByZWdh cmRzDQpFc2tvDQoNCg0KSW9UY29uc3VsdGFuY3kubmwgIHwgIEVtYWlsL1RlYW1zOiBlc2tvLmRp amtAaW90Y29uc3VsdGFuY3kubmwNCg0KDQoNCkZyb206IGNvcmUgPGNvcmUtYm91bmNlc0BpZXRm Lm9yZz4gT24gQmVoYWxmIE9mIFR1cm5lciwgUmFuZHkNClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJl ciAxMiwgMjAyMCAxNjo1Nw0KVG86IGNvcmVAaWV0Zi5vcmcgV0cgPGNvcmVAaWV0Zi5vcmc+DQpT dWJqZWN0OiBbY29yZV0gQ29BUCAtIEhUVFAgcHJveGllcw0KDQpISSBBbGwsDQoNClJGQyA3MjUy IHByb3ZpZGVzIGEgZ29vZCBkZXNjcmlwdGlvbiByZWdhcmRpbmcgQ29BUC10by1IVFRQIHByb3h5 IChmb3J3YXJkLCByZXZlcnNlKSBvcGVyYXRpb24gYW5kIG90aGVyIGRvY3VtZW50cyBkZXRhaWwg c29tZSBndWlkZWxpbmVzIGZvciBkb2luZyB0aGlzIGluIGFuIGFjdHVhbCBkZXBsb3ltZW50Lg0K DQpJbiByZWFkaW5nIHRoZSBFU1Qtb3Zlci1DT0FQKHMpIGRvY3VtZW50LCB0aGUgdGV4dCB0YWxr cyBhYm91dCBhIOKAnHJlZ2lzdHJhcuKAnSAoc2VjdGlvbiA2KSB0aGF0IHBlcmZvcm1zIHByb3h5 LWxpa2Ugb3BlcmF0aW9ucy4gIEhvd2V2ZXIsIHNlY3Rpb24gNiByZWZyYWlucyBmcm9tIG1lbnRp b25pbmcgYW55dGhpbmcgcmVnYXJkaW5nIHRoZSBwcm94eSBvcGVyYXRpb24gZGVzY3JpYmVkIGlu IFJGQyA3MjUyLg0KDQpEb2VzIHRoaXMgaW1wbHkgdGhhdCBpZiBJIHdhbnQgdG8gZGVwbG95IGEg Z2VuZXJpYyBDb0FQLXRvLUhUVFAgcHJveHkgYmV0d2VlbiBteSBjb25zdHJhaW5lZCBhbmQgbm9u LWNvbnN0cmFpbmVkIG5ldHdvcmtzLCBBTkQgSSB3YW50IHRvIHN1cHBvcnQgYW4gRVNULW92ZXIt Q29BUCByZWdpc3RyYXIsIHRoYXQgSSBhY3R1YWxseSBuZWVkIOKAnDLigJ0gcHJveGllcyA/ICBP ciBjYW4gSSB1c2UgbXkgZ2VuZXJpYyBDb0FQIHRvIEhUVFAgcHJveHkgdG8gc29sdmUgYm90aCBn ZW5lcmljIENvQVAgdG8gSFRUUCBwcm94eSBhbmQgRVNULW92ZXItQ29BUChzKSByZWdpc3RyYXIg ZnVuY3Rpb25zID8gIFVuZGVyc3RhbmRpbmcgdGhhdCBpZiBJIHdhbnQg4oCcMeKAnSBwcm94eSB0 byBkbyBib3RoLCBJIG1heSBoYXZlIHRvIGhhdmUgc3BlY2lhbCBjYXNlIGNvZGUgaW4gbXkgZ2Vu ZXJpYyBwcm94eSB0byBoYW5kbGUgRVNULW92ZXItQ09BUChzKSBzcGVjaWZpYyBiZWhhdmlvcg0K DQpUaGFua3MsDQpSYW5keQ0K --_000_AM8P190MB0979E2F72757878CCFFBD2C0FDE20AM8P190MB0979EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2Rpbmdz Ow0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFn cmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1h cmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJ bWFyZ2luLWxlZnQ6LjVpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6OTAxMTQyNDQzOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczo0ODUwNzIxNiAtMTQxODQ1NjU0OCA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBB NzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBBNzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpcRjBBNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1 NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8gUmFuZHks PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBSZWdpc3RyYXIgZGVzY3JpYmVkIGluIFNlY3Rp b24gNiBvZiBkcmFmdC1hY2UtY29hcC1lc3QgaXMgaW5kZWVkIGRvaW5nIHNvbWUgcHJveHlpbmcs IGJ1dCBpdCBpcyBhIGhpZ2hseSBzcGVjaWZpYyBzb3J0IG9mIHByb3h5IGFuZCBjZXJ0YWlubHkg bm90IGdlbmVyaWM6PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0 eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+SXQgcGVyZm9ybXMgc29tZSBjb250ZW50 IGNvbnZlcnNpb25zIHRvL2Zyb20gQmFzZTY0IGVuY29kaW5nPG86cD48L286cD48L2xpPjxsaSBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+SXQgcGVyZm9ybXMgZGVkaWNhdGVkIFVSSSBwYXRoIGNvbnZlcnNpb24g YXMgcGVyIFRhYmxlIDE8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5JdCB1c2Vz IGEgY2VydGlmaWNhdGUgdGhhdCBpcyBmbGFnZ2VkIGFzIGFuIOKAmFJB4oCZIChSZWdpc3RyYXRp b24gQXV0aG9yaXR5KSAsIGJvdGggdG93YXJkcyB0aGUgSFRUUCBFU1Qgc2VydmVyIGFuZCB0b3dh cmRzIHRoZSBDb2FwIGNsaWVudHMuJm5ic3A7IEl0IHdvdWxkIGJlIHVubGlrZWx5LCBpbiB0ZXJt cyBvZiBzZWN1cml0eSwNCiB0aGF0IHRoZSBSZWdpc3RyYXIvcHJveHkgd291bGQgcHJveHkgYXJi aXRyYXJ5IGFwcGxpY2F0aW9uIHJlcXVlc3RzIGZvciBvdGhlcnMgdXNpbmcgc3VjaCDigJhhdXRo b3JpdHnigJkgY3JlZGVudGlhbHMuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCI+KiBUaGUgVExTIGNyZWRlbnRpYWxzIHRoYXQgYSBnZW5lcmljIHByb3h5 IHdvdWxkIHVzZSB0b3dhcmRzIEhUVFAgc2VydmVycywgbWlnaHQgYmUgc29tZSBhcHBsaWNhdGlv bi9kZXBsb3ltZW50IHNwZWNpZmljIGNyZWRlbnRpYWxzIHRoYXQgaGF2ZSBzdWZmaWNpZW50IHBy aXZpbGVnZXMgdG8gZXhlY3V0ZSBhbGwgaW50ZW5kZWQgcHJveGllZCByZXF1ZXN0cyBidXQgbm90 IG1vcmUgdGhhbiB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBp biIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPuKApiB0aGVyZSBtYXkgYmUgbW9y ZS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IGRlc3BpdGUgb2YgdGhpcywgZ2Vu ZXJpYyBwcm94eSBmdW5jdGlvbnMgY291bGQgYmUgXzxpPmFkZGVkPC9pPl8gdG8gYWJvdmUgUmVn aXN0cmFyOjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0i ZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkEgZm9yd2FyZC1wcm94eSByZXF1ZXN0IHdpdGgg YSBQcm94eS1Vcmkgb3IgUHJveHktU2NoZW1lIE9wdGlvbiBpbmRpY2F0aW5nIOKAmGh0dHAocyni gJkgc2NoZW1lIGNhbiBiZSBlYXNpbHkgaWRlbnRpZmllZCBhbmQgcHJvY2Vzc2VkIHNlcGFyYXRl bHkgZnJvbSBhYm92ZSBmdW5jdGlvbnMuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+VGhlIHByb3h5IGNvdWxkIHVzZSBhIGRpZmZlcmVudCBUTFMgKGNlcnRpZmljYXRlKSBpZGVu dGl0eSBmb3IgcGVyZm9ybWluZyB0aGVzZSBwcm94eSByZXF1ZXN0cywgaW4gSFRUUCBjbGllbnQg cm9sZS4mbmJzcDsgKFNvIG5vdCB1c2UgdGhlIFJBLWNlcnRpZmljYXRlIGluIHRoaXMgY2FzZSBi dXQgc3dpdGNoIHRvIGFub3RoZXINCiBpZGVudGl0eSBtb3JlIHN1aXRhYmxlIGZvciB0aGUgZ2l2 ZW4gdG8tYmUtc2VudCBIVFRQIHJlcXVlc3QuKTxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPkEgcmV2ZXJzZS1wcm94eSByZXF1ZXN0IGNvdWxkIGFsc28gYmUgc2VydmVkIGZyb20g YSBkZWRpY2F0ZWQgcmVzb3VyY2UuDQo8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4qICZuYnNwO2UuZy4gYSBDb0FQIHJl cXVlc3QgdG8gcmVzb3VyY2UgL2NoL2h0dHAvcy5leGFtcGxlLmNvbS9saWdodCZuYnNwOyBpcyB0 cmFuc2xhdGVkIGJ5IHRoZSByZXZlcnNlLXByb3h5IGludG8gYSBodHRwIHJlcXVlc3QNCjxhIGhy ZWY9Imh0dHA6Ly9zLmV4YW1wbGUuY29tL2xpZ2h0Ij5odHRwOi8vcy5leGFtcGxlLmNvbS9saWdo dDwvYT4gLiZuYnNwOyBUaGUgc3ludGF4IGhlcmUgaXMgYm9ycm93ZWQgZnJvbSBSRkMgODA3NSB3 aGljaCB1bmZvcnR1bmF0ZWx5IG9ubHkgZGVzY3JpYmVzIHRoZSBIVFRQLSZndDtDb0FQIGRpcmVj dGlvbiBub3QgdmljZSB2ZXJzYSEgQnV0IHRoZSBzYW1lIG1hcHBpbmcgaWRlYXMgY2FuIGJlIGFw cGxpZWQuIFRvIGRvIDopPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGZvciDigJwx4oCdIHBy b3h5IHRvIGRvIGJvdGgsIGl0IHdpbGwgYWx3YXlzIG5lZWQgc3BlY2lhbC1jYXNlIGNvZGUgZm9y IEVTVC10by1Db0FQIGFuZCBpdCBtYXkgYWxzbyBuZWVkIHRvIGJlIGNvbmZpZ3VyZWQgd2l0aCBt dWx0aXBsZSAoJmd0Oz0yKSBpZGVudGl0aWVzIGZvciBzZWN1cml0eSByZWFzb25zLiBUaGUg4oCY UkHigJkgaWRlbnRpdHkgd291bGQgYmUgdXNlZCBvbmx5IG9uIHRoZSBUTFMgY29ubmVjdGlvbiB0 b3dhcmRzDQogSFRUUC1FU1QtU2VydmVyLCBub3QgZm9yIGFyYml0cmFyeSBwcm94aWVkIHJlcXVl c3RzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgd2Ugd291bGQgbGlr ZSBhIGZ1bGx5IGdlbmVyaWMgcHJveHkgdG8gYmUgdXNlZCBhcyB0aGUg4oCYUmVnaXN0cmFy4oCZ IGluIHRoZSBDb0FQIGRvbWFpbiAsIHdpdGhvdXQgZG9pbmcgdGhlIHNwZWNpYWwgdHJhbnNsYXRp b25zLCB0aGVuIHRoZSBFU1QtdG8tQ29BUCBkcmFmdCB3b3VsZCBuZWVkIHNvbWUgc2V2ZXJlIGVk aXRzIGFuZCByZXRoaW5raW5nLCBJIGd1ZXNzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0 IHJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVza288bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Jb1Rjb25zdWx0YW5jeS5ubCZuYnNwOyB8Jm5ic3A7IEVtYWlsL1RlYW1zOiBlc2tvLmRp amtAaW90Y29uc3VsdGFuY3kubmwNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PkZyb206PC9iPiBjb3JlICZsdDtjb3JlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFs ZiBPZiA8L2I+DQpUdXJuZXIsIFJhbmR5PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBOb3Zl bWJlciAxMiwgMjAyMCAxNjo1Nzxicj4NCjxiPlRvOjwvYj4gY29yZUBpZXRmLm9yZyBXRyAmbHQ7 Y29yZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2NvcmVdIENvQVAgLSBIVFRQ IHByb3hpZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhJIEFsbCw8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UkZDIDcyNTIgcHJvdmlkZXMgYSBnb29kIGRlc2NyaXB0 aW9uIHJlZ2FyZGluZyBDb0FQLXRvLUhUVFAgcHJveHkgKGZvcndhcmQsIHJldmVyc2UpIG9wZXJh dGlvbiBhbmQgb3RoZXIgZG9jdW1lbnRzIGRldGFpbCBzb21lIGd1aWRlbGluZXMgZm9yIGRvaW5n IHRoaXMgaW4gYW4gYWN0dWFsIGRlcGxveW1lbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklu IHJlYWRpbmcgdGhlIEVTVC1vdmVyLUNPQVAocykgZG9jdW1lbnQsIHRoZSB0ZXh0IHRhbGtzIGFi b3V0IGEg4oCccmVnaXN0cmFy4oCdIChzZWN0aW9uIDYpIHRoYXQgcGVyZm9ybXMgcHJveHktbGlr ZSBvcGVyYXRpb25zLiZuYnNwOyBIb3dldmVyLCBzZWN0aW9uIDYgcmVmcmFpbnMgZnJvbSBtZW50 aW9uaW5nIGFueXRoaW5nIHJlZ2FyZGluZyB0aGUgcHJveHkgb3BlcmF0aW9uIGRlc2NyaWJlZCBp biBSRkMgNzI1Mi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG9lcyB0aGlzIGltcGx5IHRoYXQg aWYgSSB3YW50IHRvIGRlcGxveSBhIGdlbmVyaWMgQ29BUC10by1IVFRQIHByb3h5IGJldHdlZW4g bXkgY29uc3RyYWluZWQgYW5kIG5vbi1jb25zdHJhaW5lZCBuZXR3b3JrcywgQU5EIEkgd2FudCB0 byBzdXBwb3J0IGFuIEVTVC1vdmVyLUNvQVAgcmVnaXN0cmFyLCB0aGF0IEkgYWN0dWFsbHkgbmVl ZCDigJwy4oCdIHByb3hpZXMgPyZuYnNwOyBPciBjYW4gSSB1c2UgbXkgZ2VuZXJpYyBDb0FQDQog dG8gSFRUUCBwcm94eSB0byBzb2x2ZSBib3RoIGdlbmVyaWMgQ29BUCB0byBIVFRQIHByb3h5IGFu ZCBFU1Qtb3Zlci1Db0FQKHMpIHJlZ2lzdHJhciBmdW5jdGlvbnMgPyZuYnNwOyBVbmRlcnN0YW5k aW5nIHRoYXQgaWYgSSB3YW50IOKAnDHigJ0gcHJveHkgdG8gZG8gYm90aCwgSSBtYXkgaGF2ZSB0 byBoYXZlIHNwZWNpYWwgY2FzZSBjb2RlIGluIG15IGdlbmVyaWMgcHJveHkgdG8gaGFuZGxlIEVT VC1vdmVyLUNPQVAocykgc3BlY2lmaWMgYmVoYXZpb3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmFuZHk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM8P190MB0979E2F72757878CCFFBD2C0FDE20AM8P190MB0979EURP_-- From nobody Wed Nov 18 22:06:34 2020 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 6F3D63A0E49; Wed, 18 Nov 2020 22:06:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk CC: marco.tiloca@ri.se, core-chairs@ietf.org, Marco Tiloca , core@ietf.org, barryleiba@gmail.com, draft-ietf-core-echo-request-tag@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <160576598797.13448.13519029767702511285@ietfa.amsl.com> Date: Wed, 18 Nov 2020 22:06:28 -0800 Archived-At: Subject: [core] Last Call: (CoAP: Echo, Request-Tag, and Token Processing) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 06:06:29 -0000 The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'CoAP: Echo, Request-Tag, and Token Processing' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-12-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC7252 with respect to the client Token processing requirements, forbidding non-secure reuse of Tokens to ensure binding of response to request when CoAP is used with a security protocol, and with respect to amplification mitigation, where the use of Echo is now recommended. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Nov 18 22:10:44 2020 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 273FC3A0E51; Wed, 18 Nov 2020 22:10:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk CC: core-chairs@ietf.org, barryleiba@gmail.com, Marco Tiloca , marco.tiloca@ri.se, draft-ietf-core-dev-urn@ietf.org, core@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <160576623714.13448.6205852284625278149@ietfa.amsl.com> Date: Wed, 18 Nov 2020 22:10:37 -0800 Archived-At: Subject: [core] Last Call: (Uniform Resource Names for Device Identifiers) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 06:10:37 -0000 The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Uniform Resource Names for Device Identifiers' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-12-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage, or equipment inventories. A URN-based representation can be easily passed along in any application that needs the information. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-dev-urn/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Nov 19 00:14:42 2020 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 5D7193A117F; Thu, 19 Nov 2020 00:14:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Carsten Bormann , rfc-editor@rfc-editor.org, core@ietf.org, core-chairs@ietf.org, The IESG , draft-ietf-core-stateless@ietf.org, barryleiba@gmail.com, cabo@tzi.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <160577368136.11050.5048096148494008113@ietfa.amsl.com> Date: Thu, 19 Nov 2020 00:14:41 -0800 Archived-At: Subject: [core] Protocol Action: 'Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)' to Proposed Standard (draft-ietf-core-stateless-08.txt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 08:14:41 -0000 The IESG has approved the following document: - 'Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)' (draft-ietf-core-stateless-08.txt) as Proposed Standard This document is the product of the Constrained RESTful Environments Working Group. The IESG contact persons are Murray Kucherawy and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-stateless/ Technical Summary This is a standards-track update to RFC 7252 (CoAP) and RFC 8323 (CoAP-TCP/TLS), updating the semantics of the TKL (token length) field to support extended-length tokens, and defining how to use these for placing requests with reduced state-keeping requirements. Working Group Summary There was considerable trepidation about touching the basic format of CoAP messages, but there is now consensus that the present approach is minimally invasive and a good way to solve the requirement for reducing per-request state in certain cases, as required by 6TiSCH and other technologies. Document Quality The document has received reviews both from core CoRE members and members of the communities that intend to make use of it. Implementation efforts likely will be focused initially on the environments using the dependent documents; we have not surveyed that yet. Personnel Carsten Bormann is the document shepherd, and Barry Leiba is the responsible AD. From nobody Sun Nov 22 15:12:02 2020 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 09D513A0FB6; Sun, 22 Nov 2020 15:11:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christer Holmberg via Datatracker To: Cc: last-call@ietf.org, core@ietf.org, draft-ietf-core-dev-urn.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160608671301.5921.450198697310395020@ietfa.amsl.com> Reply-To: Christer Holmberg Date: Sun, 22 Nov 2020 15:11:53 -0800 Archived-At: Subject: [core] Genart last call review of draft-ietf-core-dev-urn-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 23:11:53 -0000 Reviewer: Christer Holmberg Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-core-dev-urn-08 Reviewer: Christer Holmberg Review Date: 2020-11-22 IETF LC End Date: 2020-12-02 IESG Telechat date: Not scheduled for a telechat Summary: The document is well written, and easy to read, and I don't have any technical issues. However, I do have some questions (one that I consider major, the rest minor/editorial) which I think needs clarifications: Major issues: Q1_MA: Section 6.1. says: "The URNs generated according to the rules defined in this document result in long-term stable unique identifiers for the devices." - What are those rules? In Section 3.3 I do see the following statement: "The DEV URN type SHOULD only be used for persistent identifiers, such as hardware-based identifiers or cryptographic identifiers based on keys intended for long-term usage." Is that what you refer to as rules? Or, have I missed something? Also, to me the statement seems like an important applicability statement for DEV URNs. If so, should there be a separate Applicability (or similar) section earlier in the document, which points it out? Minor issues: Q2_MI: Section 3.1. says: "The DEV URNs identify devices with device-specific identifiers such as network card hardware addresses." - Can there be multiple DEV URNs associated with a single device? Q3_MI: Section 3.1. says: "DEV URN is global in scope." - What does that actually mean? Nits/editorial comments: Q4_ED: In the Introduction, SenML and RD are given as examples where the URN may be useful. It would be nice to exactly see some usage examples of the URN. Section 5 only contains examples of the URN itself. From nobody Mon Nov 23 05:48:36 2020 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 6C5B93A0B21 for ; Mon, 23 Nov 2020 05:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.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 JLcs_renWbrL for ; Mon, 23 Nov 2020 05:48:32 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140088.outbound.protection.outlook.com [40.107.14.88]) (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 775943A0B20 for ; Mon, 23 Nov 2020 05:48:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iLd3mrR6tiDnInk1b+cU4BInUDnJEgSUdEpb58uQSkTsOh5cdbzOpqusdRaUGxyT/EE1i1kw4aXuFJo7uZ4O+qtqM87nKe/WpSzL4o3vzBcbMuvIa22UwMNaGP+eVi1/KRhtF4yarX2+5muSAaAlq0KDWdRTZzCiTJ+Hvhy0/JV+KHjNEGZK96AJbNY4ZNt3ec1xVwbDFvVnXzR01t5hP8kWqGi3euakZXS0Tgkm7aupmHixAC2keeOTk75V7RZ4wgWXdab5hZHAw7jeUi4sL+SwiFaBJrMJekd+7XHcz62RvPhydrVnVLSqHIuYp2/wYmmsbcvnHrTMnm50HdoaXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yr0lnsBGPywB9C5DipjavYf39NV9Qzd60oGuXjCdP2A=; b=YLo1CGy2z4/VF2WPso0DlsJ3xpN/EFcPt5mpuKyCfD3+sSduncTd7y3EenV4XtmwSdsIpGUWI8c6r8+Haqn6xovclQH3YM+cBgGaltOk8N79pkzoer7w3ePpJU6D3lZiFCVtE9I6F56ZCbhTt5wL3AoHnXC92PIsNhaB47T5OAXxXT9VuUescCJoxP07UjLk84sS5rhPy4W7kLbrlDFxufcmb8Hu7kQEv/DOzvjhoSmG+8crlej0EacpEEXnDz1f7FtB4/L0GXYrcLPlNdd3b0aYLgcLeB41F6ViD4AFRRMiJHMAOAzu3z8zN8XsfK6vimWyIRrrH6cwlmMF3l84Ig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yr0lnsBGPywB9C5DipjavYf39NV9Qzd60oGuXjCdP2A=; b=Din9BhHkWWgGBQYTbzn4/TEz+rwQoxDoMFRfDuh36HRbG2jppysuG+S0ypbEN13SCtVeRrz6o1BlH8m5i2Tla7tkuaCuLf1k6W1yaWjWQkvMOGN41FkOmwVbmIxIvKMEqY3npp9iiMyDc8b1Iu84cDqTcVgTSAK+dFoBBFjJTek= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB1095.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:169::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.22; Mon, 23 Nov 2020 13:48:28 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd%9]) with mapi id 15.20.3589.030; Mon, 23 Nov 2020 13:48:28 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: Date: Mon, 23 Nov 2020 14:48:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4efd4Dcf3xAdhXvYHll7ecM8HBCQzCtoT" X-Originating-IP: [185.236.42.29] X-ClientProxiedBy: HE1P191CA0006.EURP191.PROD.OUTLOOK.COM (2603:10a6:3:cf::16) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.6] (185.236.42.29) by HE1P191CA0006.EURP191.PROD.OUTLOOK.COM (2603:10a6:3:cf::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Mon, 23 Nov 2020 13:48:28 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: aaa0b6b1-d1d9-45fc-2022-08d88fb67509 X-MS-TrafficTypeDiagnostic: DB8P189MB1095: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ZNAIj4x7GlIsP47/iJ7LNWoHu80JaYvvX0ErzR9MJiZMz4AiUcu9pJlraSjUAyPCx9yvPWnJBLvKAN90pTh3C1qXalkylSKGv7sc/+236oVYci/qfThohsq1RGjkknjQUesmlL8up/x2fH4ZkHOAhxFRHuhL2/EASbjzbFOiMJ5bP1+hFDvtUBY31zIZciiKPdSQj1R1XvoZ+j3n4RyTP8YBHrbsr+VTXGx3MYIEFNM4zkmETQFBLh8L0IgmPChotJSLMuzwQL6emDyRcz07W/P4kgUqSCX4QHrzfktQr8FmC3Rs148pyAbwZCUjvmpK6qp0TFZudqjj6E7N9Mnoj6ocdBXWphi3vvViIS5AnaOsv1Pcs2pP4lqauPwQ+A02Do1PvVsNsBzLwXgQhpur46xZ44bKYrH6zb7V82OCYpE+ogXsaRm9aCBMGVanaAuFkqS1bxewXxnnlMI4hGODjQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(366004)(39860400002)(376002)(346002)(33964004)(66574015)(316002)(956004)(2906002)(2616005)(83380400001)(16526019)(52116002)(31696002)(26005)(16576012)(44832011)(31686004)(21480400003)(186003)(5660300002)(235185007)(6666004)(36756003)(86362001)(8676002)(966005)(8936002)(66476007)(478600001)(66556008)(66946007)(6486002)(30864003)(6916009)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: FigBqFIdSsb+v0CooUGksnI5BdMsgFDSv8vpsVhzs8LoKJ1Dhy0AQgGA1Iw4pTeizvE5sOyWEJImZau5KQ0m7/Srn0V+EFKCCiab+643XGqH8QZrY1uH2cJRNJdwyVpmAc7j6coPAi7q/25vCzG4N00i2PDDFdGSHJ8Atb5dkw/nvIb5M/t+FiEU+8KM6fHNSY2GbrCoIIgfL7L81PrX8lpefVSmDqTeBRjLHOGg+IvqWxkgtiVf65jLSPnUgw+iIkSkXE8bu6D2WyiPfLu39LedkSj4kJKI/UlfS5A8pkwYJNYi5/D00+Sy1er9BwdJ0wVLVkdIIGdoQQ7itobhqAPaRRlG+8/rKB8jRX4zFpFoIY+suUzOgfvJwYZ6KU1vBFNXAMPQZb2aFRf80mUAzKucJdhgFCLRcP9VbJwvia5KL8KILV5iN0KCyzM1Pa6w4XEpXABlu5cYplpksXRzy4rHphpW9tsfv5nSaRkAwBdwhnDfR4+nIukerhjBiIbOyXF/Ouf9LtlIfzgye20WYKbdB/rD5jlI73/Gr5GvZuu1xtBpcrxOjWU4GoDFSzZUk73DbJWT1MA+hPtsdT+glOlEKQK2VSaSdGKgzfPYZkJRMhyW0vgRQXSBRPjxEkJOYViHZy2KCigmkAXgxQ8r3xdycwMtIJepcouzzJWcQsi5bHbRbPxGPMbyCMMwuDDOifugHPbsLYYPrFuyOr+Tbgb1O9ndrkqZPyI7vfnW4XDQOBPxGGQd7/20T26tqGRAjbhOjcxz4t30one/cZJAPJhG7sY2sLb+iqGqv7PDJefdxROvZSQiBRB5WlH/+taT7dD3gDAntKxs/VOqMWJUAAB1N3jnAFidn1nUGrdaKVNds24rjGqmdkzLvObuq9hY1ii1sc/HWW7P1UAXEMp02A== X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: aaa0b6b1-d1d9-45fc-2022-08d88fb67509 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Nov 2020 13:48:28.5178 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 75Dr1jrRTiwKPHvEZ19+fpcuvGCqMbA0YrFu8EnZI0cGcOtRRtC7VgGKEY7Ystfdg93D+uD4j19MQUoUrpjymA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB1095 Archived-At: Subject: [core] CoRE @ IETF 109 - Minutes and summary X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 23 Nov 2020 13:48:35 -0000 --4efd4Dcf3xAdhXvYHll7ecM8HBCQzCtoT Content-Type: multipart/mixed; boundary="kBdAPHlUk6vScNJ9c2XnjL6071YGPxFfB" --kBdAPHlUk6vScNJ9c2XnjL6071YGPxFfB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, The minutes for the two CoRE sessions are available at [1]. Thanks to the fantastic note takers Christian, Francesca, Michael and G=C3=B6ran! Please, send possible fixes and updates to core-chairs@ietf.org or to the mailing list, preferably within the next 7 days. The recordings of the two CoRE sessions are now available at [2][3]. Finally, you can find below the usual summary of the two sessions, with fewer technical details. This summary, together with the raw minutes, is also available at [4]. Thank you all for your participation and contribution! Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/109/session/core [2] https://www.youtube.com/watch?v=3DaCiY4HS0-IY [3] https://www.youtube.com/watch?v=3DA70LOOSrfdg [4] https://github.com/core-wg/wg-materials/blob/master/ietf109/core-109-summ= ary.md ---------- # Summary ## WG and document status * RFC Editor Queue =C2=A0=C2=A0=C2=A0 * draft-ietf-core-stateless-08 * IESG Processing: =C2=A0=C2=A0=C2=A0 * draft-ietf-core-resource-directory-26: IESG Evaluati= on::AD Followup =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * In Last Call =C2=A0=C2=A0=C2=A0 * draft-ietf-core-dev-urn-08 =C2=A0=C2=A0=C2=A0 * draft-ietf-core-echo-request-tag-11 * In Post-WGLC processing: =C2=A0=C2=A0=C2=A0 * draft-ietf-core-comi-10: under shepherd write-up =C2=A0=C2=A0=C2=A0 * draft-ietf-core-sid-14: under shepherd write-up =C2=A0=C2=A0=C2=A0 * draft-ietf-core-yang-cbor-13: under shepherd write-u= p =C2=A0=C2=A0=C2=A0 * draft-ietf-core-yang-library-02: under shepherd writ= e-up =C2=A0=C2=A0=C2=A0 * draft-ietf-core-oscore-groupcomm-10: processed WGLC = comments; one new review to process ## Resource Directory * draft-ietf-core-resource-directory-26 Reviews from the IESG were processed and answered. Three open points will be addressed in version -27 coming in December, about DTLS replay protection, trusting links from the RD and ambiguities of Link Format. One point from Ben Kaduk requires an explicit follow-up. ## Stateless * draft-ietf-core-stateless-08 The latest version addressed all comments left since May from IESG review. The remaining DISCUSS ballot was cleared up. During the IETF week, the document was approved for publication as Proposed Standard and entered the RFC Queue. ## Groupcomm-bis * draft-ietf-core-groupcomm-bis-02 The document aims at obsoleting RFC 7390 towards a Standards Track, now that there is a possible security mode for CoAP group communication. This version closes issues from earlier reviews. Next steps include handling of multiple responses from a same server to a same request, cachability of responses and usage of ETAGs, and implementation tests. Pending reviews: Christian and Francesca. ## Group OSCORE * draft-ietf-core-oscore-groupcomm-10 This version addresses comments from the July WGLC and around IETF 108. The third round of interop tests occurred during the hackathon, with three different implementations, covering also the pairwise mode for message protection. The main next step is running more tests and addressing a new review from Christian, covering among other points the need for a better distinction between anti-replay and freshness requirements. Other points to cover include optimization and generalization of the external_aad form= at. ## OSCORE Group Discovery * draft-tiloca-core-oscore-discovery-07 Method to use the Resource Directory to find links for joining OSCORE groups at their Group Manager (GM). Full support for Link Format or CoRAL= =2E Latest updates include an alignment with draft-ietf-ace-oscore-gm-admin as to the names of the application groups, and considerations on an application group using multiple security groups. It was noted that the link relation between a security group and an ACE Authorization Server is a general thing that may be better handled in ACE, possibly as a dedicated document. Next steps include adding parameters about the pairwise mode of Group OSCORE, alignment with upcoming updates to the Resource Directory document, more security considerations, and early tests among implementations. ## Multicast Notifications * draft-tiloca-core-observe-multicast-notifications-04 Method to send observe notifications to a set of clients observing a same resource at the server, by using multicast responses. These are responses to a phantom observation request that the server creates. Latest updates include encoding of informative response (transport-dependent and transport-specific information, flexible for non-UDP transport); improved rough counting of clients; added support for proxies. Next steps will focus on improving the examples with proxies, the negotiation for client supporting this mechanisms or not, making some content optional, and specifying a possible server acting as its own OSCORE Group Manager. The document has its core approach stable for a while now, and there has been interest for adoption from 12 people. People to review: G=C3=B6ran and Carsten (since IETF 108), Jaime, Esko an= d Thomas. ## Groupcomm proxy * draft-tiloca-core-groupcomm-proxy-02 Method for proxies to work in a CoAP group communication setting, addresses the related issues from draft-ietf-core-groupcomm-bis. The proxy forwards back to the client the individual responses from the servers, for an amount of time indicated by the client. The client can distinguish the different servers originating the responses and learn their addresses. Two new CoAP options are defined. Group OSCORE is possible between client and servers; any security between client and prox= y. Latest updates include improved semantics and encoding of the two new CoAP options, and support for a chain of forward proxies. Next steps will focus on support for HTTP-to-CoAP cross proxies, to enable HTTP clients to talk to a group of CoAP servers. Need for reviews; promised at IETF 108 are from Christian, Carsten and Francesca. ## OSCORE with EDHOC * draft-palombini-core-oscore-edhoc-01 Different approaches to combine an execution of EDHOC with the first OSCORE exchange following it. The different approaches can also be signaled in different ways. The third and final EDHOC message from the client is merged with the first OSCORE request protected with the derived security context. This would reduce the overall number of roundtrips. Following feedback from IETF 108, this update reduces the candidate approaches to the one using "EDHOC in OSCORE". The goal is now to select the exact way for signaling this approach, as either a flag bit in the OSCORE option or a dedicated new CoAP option (which seems preferred). Both ways require an IANA registration. Need for reviews; promised at IETF 108 are from Christian and Carsten. ## SenML Versions * draft-ietf-core-senml-versions-01 This version includes only minor updates; it needs reviews before WGLC. There is a working implementation from Ari. Alexey reviewed preview versions. Need for more reviews before WGLC. Will review this version: Jaime and Bill. ## SenML Data CT * draft-ietf-core-senml-data-ct-02 Need to integrate the comments following the WGLC after IETF 108. After that, plan to request publication. The document refers to draft-bormann-core-media-content-type-format (MCTF) , which would preferably be an adopted draft before this document is sent to the IESG. It's not clear where MCTF belongs to (out of scope for EMAILCORE, very generic for CoRE), so it will go through DISPATCH. Alexey offered as shepherd for MCTF, while Barry can possibly sponsor it as AD. ## New Block * draft-ietf-core-new-block-02 This update addresses all major points. The WG has decided to call the approach "Q-Block". Will submit -03 soon with minor additions, then need for more reviews (also about the usage of OSCORE), then WGLC. Will review: Christian. ## Dynlink * draft-ietf-core-dynlink-11 Work is ongoing on new parameters and their usage, also relevant in OMA LwM2M, i.e. 'pmin', 'pmax', 'edge' and 'con'. Related issues are open on Github for comments. It seems reasonable to allow pmin =3D=3D pmax. It's still open if and how= this should support the presence of proxies, that are not used in LwM2M but have to be assumed in REST as scope of CoRE. There will be more discussion at the next series of CoRE interim meetings= =2E ## Fasor * draft-ietf-core-fasor-01 Presented status and planned next steps; authors see the document as stable and needing for review, also from tsvarea. After addressing review comments, WGLC would be a target. Characteristics of the approach have been emulated but there are no plans for further evaluation. Will review: Carles Gomez CoRE chairs will approach tsvarea chairs for more reviews. ## CoAP over GATT * draft-amsuess-core-coap-over-gatt-01 Presented updates on the exchange of CoAP messages on GATT, a mode of Bluetooth Low Energy, targeting applications with limited APIs. The goal is to gather implementation experience and have this as Experimental "This is how a few people do it" document. There was consensus that it is good to extend support for CoAP on more environments/platforms, and that Experimental is the right type of target at the moment. It was noted that GATT specific new COAP URI scheme might need detailed examination. ## Rekeying for OSCORE and AEAD limits * https://mailarchive.ietf.org/arch/msg/core/bbzZCt6ZZn4ysR7yLujPNscBF3g/= Depending on the used encryption algorithm, a safe limit exists in terms of performed encryptions or failed decryptions using the same key. Once passed the limit, the key should not be used any longer. This affects also OSCORE, especially when using CCM_8, and should be considered also for Group OSCORE. Some preliminary assessment was presented, and more work is required to have a better model and better values to take as threshold. It has to be taken into account that CCM_8 is used today. The immediate next step is a new draft where the problem is better documented and analyzed. Building on that, it will be possible to better understand if OSCORE needs a new lightweight, symmetric-key rekeying mechanism. There will be more discussion at the next series of CoRE interim meetings= =2E --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --kBdAPHlUk6vScNJ9c2XnjL6071YGPxFfB-- --4efd4Dcf3xAdhXvYHll7ecM8HBCQzCtoT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEyBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl+7vaQACgkQ7iZktA5Y 2kM83gf4mTGX+JOtNdxMC7HDYEgdcS2NgU0CHtCyc0heYgMEqqzKxZYEW+PEGAAV 1bL68Br/eP6xQSQ2+IA9Ugy3oyKEE5LeOGa0HAWqhPtV+lViMhlojP20UB40V4WF 8ycl9o27DjnuGxBuW5SxqELzXoL0xScl1oHcfqWCa4JtBYU6nx4SjPKCTxdWcDLj VbdKxUUoax912M3Wwt+YeQi27FsTrpJhkAb+bUF/Rh8qZynrbBNSHJDkS/M+EGg8 MwdEPbwEda9HCAKzZ/F5sy7SMa5ktl64eoyT+A343bw1vOLUt5OSSdj1kj67sr8C j/6OM9QyxqsSY4ykjE+I/Cq/ra2c =Xuvt -----END PGP SIGNATURE----- --4efd4Dcf3xAdhXvYHll7ecM8HBCQzCtoT-- From nobody Mon Nov 23 08:07:41 2020 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 B3F6D3A03F8 for ; Mon, 23 Nov 2020 08:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 BG9Fk37Ba7NQ for ; Mon, 23 Nov 2020 08:07:37 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2064.outbound.protection.outlook.com [40.107.21.64]) (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 84A143A03F1 for ; Mon, 23 Nov 2020 08:07:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RaUilOLnQTtSfA6zE3CuKy67In2YxD1LEUw1Z2ys3n+3EzNA7ItdQVDH1hWmwXWgYgk1wpKDyInSgYUSbzI0Z9gALd6GeCiXOuVemqlnPyvZbddoFTePg2V8HtWvq3KATBishPIxvwANqjA93Ntd6dXG81spJ1dBpzcZljjP/m6noJRhhiPFUsDBAbQnkeJnngFj6ZKzw9JXM+oZ2ugaC6mycX2D4tBX0P04chPM7fvQ58lZaXIvT6bg+ZJxb8DvL7Cv8oJy+ugcpsMOm+QJDEUBDnP+IxLbcPjl98v/Hxnyt9VamFnjSMgkEbocaoJ80LDyb6yVbLcSJHBb+RXnaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Mx20DyQT61lNar3fsWlOEvG3+ewwxKM4QyqWXefUt/I=; b=XrVFngWPpF3zgfNN0HC0ESgiHzbR6wvWNvXg8st0M1+0LOoVLqfpbk1dwklsQymXchmcsw8zlZluzdRnaAJdktvRLCAI3jjH2rWohsSmHlrSxDNmfbBKucRTM6st1ME9XKSxQQddIz9ib9LgtnFw/9t1qwKyQyF6sTTWLnj3GoSiInEzXMojq68NHFrj9U/Mn/JZHwc39XbrAZ3EpYMfnWkj36kw+f2GYF3qKvLCbKlJJEDF0xz6X6u4IKZZ++lxTTUsswhS9iRoVP4pJ+ipEdhNjxe1KjD6eYiAwKcV9h+rnOlHB1tHFR7cLGCllfZHW9sjfAlOFfS0UvCIjlFv9g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Mx20DyQT61lNar3fsWlOEvG3+ewwxKM4QyqWXefUt/I=; b=TiQUcd5+EiRu9qs52pqS3atWRzcjdegwmDL25PFrBTlpqN4uiVIbNhFo0S733glIGoDEn/GRFA4FBi/jsjHYZCPHCaEXvN43hLrHM+lbIZdawv/k3kP2BnWcp5/12I+JDmiVqsWqCL9bGH9846kfUwnZmJVbT4mSgznQ73DDNvM= Received: from HE1PR07MB3226.eurprd07.prod.outlook.com (2603:10a6:7:33::20) by HE1PR07MB3337.eurprd07.prod.outlook.com (2603:10a6:7:32::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.16; Mon, 23 Nov 2020 16:06:53 +0000 Received: from HE1PR07MB3226.eurprd07.prod.outlook.com ([fe80::4129:a61d:7e11:b77f]) by HE1PR07MB3226.eurprd07.prod.outlook.com ([fe80::4129:a61d:7e11:b77f%4]) with mapi id 15.20.3611.018; Mon, 23 Nov 2020 16:06:53 +0000 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: core Thread-Topic: Review and implementation of draft-ietf-core-senml-versions-01 Thread-Index: AQHWwbCPck1fkHnzK02/PCjiVGTlcQ== Date: Mon, 23 Nov 2020 16:06:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:1a1:2d7d:4cc1:1899:9f2d:a060] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 35a279b1-9d8e-4344-19f7-08d88fc9cb64 x-ms-traffictypediagnostic: HE1PR07MB3337: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hZHPNllC0tH92ZnCqp/memObgUqIqpHjWU0rvcnfMpEvt5GqWrPnxeDdTb+rLASmWE2F4qW2FlXP1D1VE+3FLjdblN/9EJiLA6xKE7hKwh6Rgl3cORS3KkoFitz4/izMlPFSNxCjmmu0bxddjiCmYhLBPDO5K+2sNDZP9Co7K008lohYrj0whOUEEWreGC//vVIuxBQ+Gmfd5gRCv2a21cS4Rvq88CgXrgKtGDoYUvuxqICeqqGwwzQfrKEPKI/Ly1zp/dm0G/4bz9R7lkWyNn3UaaCZodqAOyWHw0WauNTS2dp9KWn/AcCys2o5BfGVFh0xToqHEcSemAki0nbJt5qVxu3PrSkNdiQ4+FlJD34zeEs9wg1/fpyEgFcQ0IIK2qvVEcubikZQDb1lu5SwVQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3226.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(39860400002)(136003)(346002)(366004)(279900001)(316002)(8936002)(478600001)(7696005)(5660300002)(71200400001)(33656002)(52536014)(186003)(9686003)(76116006)(83380400001)(64756008)(8676002)(66446008)(86362001)(6506007)(966005)(55016002)(4744005)(2906002)(66476007)(66556008)(66946007)(6916009); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?ac6E4L2jTNZC0DCNX1JlgLu2GzaQp47FsfHVLfBgBqqG8Fc+0V+uTb3bKC?= =?iso-8859-1?Q?4p/bFYFqPoWP2bNC6KxN0A0b+FOSlOqbEt7B6XQskn4Z+vQeUzQEDGf2qo?= =?iso-8859-1?Q?WR+Z+NokMQV02mAFo5OYNWYs54GO/caEkI14pyY8hFKuaXF5yqb9rOU9oS?= =?iso-8859-1?Q?DmMhsQIiMzrXmjsGokeuechdu2L1M6Gf4KCrxEvY6GdvcqETuHzTEXx7y8?= =?iso-8859-1?Q?tOTHeoJ7QGF8fKW9abfiJeJfCeELoKiPliStYp0prC5iD/p+NZHJRS7bt0?= =?iso-8859-1?Q?bYkUnuvsXSxtdW8LhPS9n6+balkoyrzgEDdCkVqkKxXgqQRsXSvCTJuISM?= =?iso-8859-1?Q?4oVDOYwoQxhMu8HpWOcvxL1Aag+6W0IlmpR87PkKLOI5KfbXJzztLqwcLc?= =?iso-8859-1?Q?8aORzUZ2fUe7v+VSHlMpSwJZorzE81r4Q9xbri+66CkIExDY07cVSppt/5?= =?iso-8859-1?Q?0EIDx36k9MjD3YNREz09FcpHI1jfMX8ob4ZH1uVARfJnk7XXb9LUakxBLa?= =?iso-8859-1?Q?vdkDY/uJXpHVqNH8iWzffUsh/GyWBUtcwvobuXLyDS7KL1y+Fvo/hkzOVp?= =?iso-8859-1?Q?sO3OsopRXDUcPoHdMA3gjC785ciHbx+83XY3pLKio3DCVx1e7TLid8uKwG?= =?iso-8859-1?Q?KgnqjDAKaAOUJSM1zXEuvj4aP2NkSOXNpW7ZcDdh2A9G6wzRP5E/o0rVPx?= =?iso-8859-1?Q?Xuk2zzuO7+Dwbd0MXEexFTE2jCrx+0kPTX9rBmOYZ5fMq4G9UqptO2LZ2q?= =?iso-8859-1?Q?ffUrnTp2ivw0o43WGR0av8Y3N2wvTfjcfCDQy4mPni0JEGzAQsI+bdN/sb?= =?iso-8859-1?Q?C2DOjKOndpG93hs+mayUZEsGDTrGcspBQ6abwGadxXGzZed3S9DZPu+BOP?= =?iso-8859-1?Q?cVbcZUySPd6SEjclKIj7tMueT6lq42e0m+BOGS/o1s806JOAoNWOfQJyFf?= =?iso-8859-1?Q?R4L8hZOr2KNCaxh0aWtMJxTR3wlD+v1MC1TgG6NUTAqjli70t+E97w=3D?= =?iso-8859-1?Q?=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3226.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 35a279b1-9d8e-4344-19f7-08d88fc9cb64 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2020 16:06:53.5739 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8XuWXHXvEYMgBj5ZBBt+XUTrXpeV7lbcRsGW6bN1ZGn0m0Hud6kUFvDrwq0W+hkWX50X4F1uvW1jhaqXVG6lg1LIHTIOCdsreOLy5RRzHKc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3337 Archived-At: Subject: [core] Review and implementation of draft-ietf-core-senml-versions-01 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 23 Nov 2020 16:07:40 -0000 Hi all, As discussed in the CoRE meeting last week, I reviewed and implemented the = draft-ietf-core-senml-versions-01. It's a rather short draft so both implem= entation and review were essentially done between the sessions that day. Fo= r me the draft looks good to go forward. My implementation is currently running as a web service if you want to play= around with it. You can try for example: curl -X POST http://wishi.nomadiclab.com:8086/senml-validate -d '[{"bver": = 26, "v":42,"bn":"foo","bu":"km/h"}]' You get either 200 OK or error with description depending on if the SenML p= ack was valid or not. If you want to resolve the secondary units you can use the senml-resolve-un= its functionality: curl -X POST http://wishi.nomadiclab.com:8086/senml-resolve-units -d '[{"bv= er": 26, "v":42,"bn":"foo","bu":"km/h"},{"v":44,"t":2}]' (there's also senml-resolve if you want to resolve base values) Cheers, Ari From nobody Wed Nov 25 01:43:16 2020 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 636503A00D9 for ; Wed, 25 Nov 2020 01:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=kamstrup.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 WYV2wL3taWiL for ; Wed, 25 Nov 2020 01:43:12 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20719.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::719]) (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 14C153A00D8 for ; Wed, 25 Nov 2020 01:43:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ob3r+i72a2UA/xpkL/HvO89g4qmY/PSw2nPrNrhRyf2rqxAZ/UHMPfd7alJryzirRTkkXFFJfCQ4lNN96nVG+7r/tlZkekjVLVczCzDAgYBwjkI/jTbqyN7S2TuEIljcQPHwO+ol21L4R2PyDNw5Tbmwr9NK9nFYsntiJCcbIIgGr2Dq7LDEBd6VDDS3WfupArB4QC1K8pE8B89C0WzVI4b5jyjjZ2ZIjbWyks0ofQuNT8fqOAIGL2Jzo0virhnzKJLyUZOsWaObFDl9t1TarXd13NlZ/P+5t8S+EYKKd8wA/28w56WqXooZ4m2MkVRvTtBnZLVebUtucOmND9bjqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h0RAnvPAIcTXx3QZCtMoCkn8NPEJsQc86RiZ5jHsmyM=; b=cnMCCtN79nqodju4Ej4gAzJZAK8Aisik0FdPI66kFoqhASDzUxGj0k0P+jwj/b9RptlxFUDxMMqWvbsM4OG2y6A4UgSr/KJ+vz5k/D09p9LFn8Yd95BlZuAJIA3V9awS7eE55GzGAfh4veAtiqU98QDQdnMR29XAR/0UIwUcpUzsuKp7MJdokChwTUCugJF25xWzMECkydhqTKWhC/kdJhyHyeA+7FuQs+uQhcHQyB9oc8xchYgJFCNmpboWioQDoIG+aSs+S3ldrXeALmJX+GSHBRsSTIu+6maQ1rBo3pCI3exCjV49MKESXxYhFjYWJc42q6p/cdI9SjUr+8xcoQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=kamstrup.com; dmarc=pass action=none header.from=kamstrup.com; dkim=pass header.d=kamstrup.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kamstrup.onmicrosoft.com; s=selector2-kamstrup-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h0RAnvPAIcTXx3QZCtMoCkn8NPEJsQc86RiZ5jHsmyM=; b=TXZa2DcXKSXg9nStx8GvvYiVMqgrBf/b6QLKrTxJqhe1DIYKEqXl+jrGXpJ59lG93i/SOeeLaYCvqd+9BJgVR/ObmP8lvcuPZIi+XwjZ1LLNygTGJNtfLOh37DC5PaY6kfAmJyguwGcGtJWBr11z4JWsrPLoExxddjxPAdon/zM= Received: from AM0PR04MB4546.eurprd04.prod.outlook.com (2603:10a6:208:75::32) by AM8PR04MB7442.eurprd04.prod.outlook.com (2603:10a6:20b:1d8::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.25; Wed, 25 Nov 2020 09:43:07 +0000 Received: from AM0PR04MB4546.eurprd04.prod.outlook.com ([fe80::606f:2953:8b44:6352]) by AM0PR04MB4546.eurprd04.prod.outlook.com ([fe80::606f:2953:8b44:6352%5]) with mapi id 15.20.3589.025; Wed, 25 Nov 2020 09:43:07 +0000 From: Karen Elisabeth Egede Nielsen To: "core@ietfa.amsl.com" , "core-chairs@ietf.org" Thread-Topic: Observe for POST method Thread-Index: AdbDDnohQDaZzUETSDClhZlzLQ6DOg== Date: Wed, 25 Nov 2020 09:43:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [185.181.22.4] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e857356b-98a4-4187-e4ab-08d891268364 x-ms-traffictypediagnostic: AM8PR04MB7442: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kI/6AqgKCYanIlbtCUKdrDP3EPcYo/bl0DaOlkdvnfyvONxfySWsjAo8uyacq6T1NnMUb3GFfzbNnoYw6OSS18OoqFYnT3wcYLEbBDUwwITlnOJapGBKkJ6Yb4vAmxEYacEZcsQ49clDrr1RKkfrWMZxrgLtdw0AZntSBA9gUCvg87oF0e43kL2FiCPNdPf/WahdGExFvjEVGg2akMnBI73xtswlhbWQ9+e0PRUEBRAdSFigjmGWOnVLmxMnIEiPrLItpvrxdo3jFUiYOB8OPCaHZsqnJz6ReMhy8zemkE7NDdufJsVEG6cit7HPmj4i x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR04MB4546.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(39850400004)(396003)(136003)(376002)(346002)(366004)(76116006)(64756008)(7696005)(66556008)(478600001)(66446008)(8936002)(66476007)(6506007)(316002)(3480700007)(26005)(2906002)(86362001)(83380400001)(52536014)(66946007)(110136005)(8676002)(55016002)(71200400001)(33656002)(5660300002)(9686003)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?RgMvvJ1DiYwPy/g37EaM9Snb8qOg6x/UngtNa/EzjQBkDuQfvDr0zlv3ZHZv?= =?us-ascii?Q?LKBcNmbQFoVVFwn5XIkwZJkz2hSfVDy4v8wpke27V+se4RcMmFitZB6vn22A?= =?us-ascii?Q?Ch1glmbPR0WgabwunDsqvDf3frfd5c1zIzRKcjIPdUbAr9TfCnO/GOOGyAk4?= =?us-ascii?Q?NVtvtwQHZnNKcv5FixMVKYAUL+VsxQgR5HZDJt3VhNaTNMV78oIkpKs4Zp8C?= =?us-ascii?Q?MxwMmSVjh4MBCAC5I/RXxg6j7QJ/H+8CNEeuzp1/nr2602x4hTD/izUHR4JS?= =?us-ascii?Q?5mPI3BFfaPyULeYCTaGUu6vg0BqPZrTmx877pMRZ1Q8ZoUFgRXcg7hf0KiCQ?= =?us-ascii?Q?kPoD6wKElQJlVWNkhJbsROQa6gZEqgsh7QSf1CVkoqrLtHNfGTpBOlBV+yiC?= =?us-ascii?Q?HwGUfyifVAFtIpRbT5ZOSmbvSeHjyx9XHyipk03G9dm1WMQVC+CScxfVrhA5?= =?us-ascii?Q?LLQFeI440QDPkbTOiAPNTXL15INXjj4jrzLkvWZo3WlsE+U+jCH2ojKSV3lK?= =?us-ascii?Q?hStrRN7Zy7D8gBqs7Zpv4K5Uo/0uf9E5zH/O+NWGBjqaTi/PkA9X8eTyb5Vi?= =?us-ascii?Q?DbnyUTRfQ7eggG54S8m80Q7KHtOX5M3R3FwHGQVzfwmdUbOfDgFDkYlMuuS7?= =?us-ascii?Q?4V2qio9wb8BLlfQzvanmRaall7k0iS1ZZop1ZjiS/3h5VoxIoWu/mWEdVou4?= =?us-ascii?Q?wNzW7l6xOMVXlZp+rl339ljVDTfraZIEBg2o3cif/FAHJ/LVFvcBT355ZQ7/?= =?us-ascii?Q?ypDhjcAuYplFwlMteh2kAPYXD2QD/kP0NHh5YfFWIwGc+PULAdUgDxX4Gr03?= =?us-ascii?Q?cXb4myLmUV1v92DooLu2jeiRl9ZwCUFAOK2BlBa1KPihFxid9T8VyKBXqiQN?= =?us-ascii?Q?keX7UsqhfmQobqXL48tRMj1W26/Mt5SCMWoWrcCXmatALeU207UkzGrCjzBn?= =?us-ascii?Q?8Iun2p+dSbk2ZeUxIz/ITiLDA0ttE3D6FWfwWs8gNFk=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR04MB4546F27764F4580679B11993C9FA0AM0PR04MB4546eurp_" MIME-Version: 1.0 X-OriginatorOrg: kamstrup.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR04MB4546.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e857356b-98a4-4187-e4ab-08d891268364 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2020 09:43:07.1777 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 90a8229b-1514-47f2-93a9-6b8b3cf3e0c3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xJiBCEjFv1yUHtONHpYMDAYjdXYGDKPaTzPE8PUVHVK/+vw5XREQXNpl9ZYEUCmK207EdLPeAISXx1U1wAgisQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR04MB7442 Archived-At: Subject: [core] Observe for POST method X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 25 Nov 2020 09:43:14 -0000 --_000_AM0PR04MB4546F27764F4580679B11993C9FA0AM0PR04MB4546eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Core wg, Chairs Have it ever been considered to support the observe option for POST? Background: We are in the situation where we would like for our IoT application layer t= o use the CoAP POST method over CoAP/UDP as a "transfer layer" operation. T= hus being able to rely on the CoAP/UDP stack with OSCORE/DTLS and its conti= nuous evolutions (e.g. FASOR) for end-to-end communication. At this point in time we would not like to port the application layer to in= tegrate/operate in full through the CoAP RESTFul services. Rather we would = like to operate the application by interchanging the application layer data= units (APDUs) through the CoAP POST method with the URI identifying the ta= rget application layer. To get the most efficient operation it is of interest to support piggyback = of responses as well as to have unsolicited APDUs (e.g. event channel) be t= ransferred by means of separate responses as it would be possible had the observe option been standardized to be usab= le also with the POST request. BR, Karen Nielsen Karen E E Nielsen System Architect Technology Software Kamstrup A/S --_000_AM0PR04MB4546F27764F4580679B11993C9FA0AM0PR04MB4546eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Core wg, Chairs

 

Have it ever been considered to support the observe = option for POST?

 

Background:

 

We are in the situation where we would like for our = IoT application layer to use the CoAP POST method over CoAP/UDP as a “= ;transfer layer” operation. Thus being able to rely on the CoAP/UDP s= tack with OSCORE/DTLS and its continuous evolutions (e.g. FASOR) for end-to-end communication.

 

At this point in time we would not like to port the = application layer to integrate/operate in full through the CoAP RESTFul ser= vices. Rather we would like to operate the application by interchanging the= application layer data units (APDUs) through the CoAP POST method with the URI identifying the target applicati= on layer.

 

To get the most efficient operation it is of interes= t to support piggyback of responses as well as to have unsolicited APDUs (e= .g. event channel) be transferred by means of separate responses=

as it would be possible had the observe option been = standardized to be usable also with the POST request.

 

BR, Karen Nielsen

 

Karen E E Nielsen
Syst= em Architect
Tec= hnology Software
Kamstrup A/S

--_000_AM0PR04MB4546F27764F4580679B11993C9FA0AM0PR04MB4546eurp_-- From nobody Sat Nov 28 00:23:12 2020 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 686EF3A0ED5 for ; Sat, 28 Nov 2020 00:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.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 OVMVnR3ZZfy5 for ; Sat, 28 Nov 2020 00:23:08 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80054.outbound.protection.outlook.com [40.107.8.54]) (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 911863A0E96 for ; Sat, 28 Nov 2020 00:23:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Wwu2pnVdDdoppTdRUFFpoRk2FdrtIDfSLF60RXHbZMJofDBBipsfxVWsdQTP4cT7L+RHOIckcYoamFM1cefcldwPisiTCbPN9yWGXRYX9m6GTgIq33NsYPBP/RIZO5PuIv7NWwTWqZ+VYA0gNJKnrGeVU0uQ4CUzqAeF4F7aAcBWbZGuvs1rhm4FaEzHntqdHrbmMQt98BlAPE1u1E6eiuoHcgdAQa2GQMj5LNPjwIbTrrCcT8i0GI1JL1Ef3SNjIeTshRtOQN1N4Mk+tkXQlhLEU/g3qJBiDzt2B/fUCXJ5R/v35WiSaDgBLF7xxJi/qmdsXE/RUCHh29E2bDpdwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y9rsxi60K3/JZVAaU9irrmwO5jiyaHDdABRxkBjWd+o=; b=dr6jdQBfnlVIZv9RjMTfq/DVipWoJzig9JqUjyqsSCkEm/0aLwVGvK2YZgaKR/Q0dvoU92uZbaYgftf8/pEPT7qvI3tf44xSyLhIFDzv/kLn2KtgneWJ7PDCgbDYSBX8T1MuMCaqaIBr3L8MZ6Wjoi/Ch1UELQzq/V5SMoYt1UzuxFEweCejATZbvKL/Jejeqd5AqrhQMOAIDcMNYxgRaOCPBCm71yCylORsc4GxgfkEWvJ0T7dxHrAUrbUhRU2bb8XHZ27mq91Err4vZQuMATJxYlDvxbMYR5lQ5ZQBwqgBvSkiXx7ayD3jGyZkiaE+0oFwH1cKXSU989AAb/h6Xg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y9rsxi60K3/JZVAaU9irrmwO5jiyaHDdABRxkBjWd+o=; b=fr5Y5l7yOsZMpb0h/YokMroLxBQaq8izumyTuZuNEWmuBfRa2kByLYIXQcRqhIdpS0YBFcL9Q5NONbGlMUTx35feH79nfLYi0bZekUkblLdxXstHghT5NtHc5pjzXdUTt2hDsBXNG/4kyAlZJb0Hxf1CCVb7l5UapB7Kf1LXXK0= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB6P189MB0376.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:3b::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.25; Sat, 28 Nov 2020 08:23:04 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::c906:d500:5041:56fd%9]) with mapi id 15.20.3611.025; Sat, 28 Nov 2020 08:23:03 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: <0e791a9b-9735-40fd-d145-4caaa300869f@ri.se> Date: Sat, 28 Nov 2020 09:22:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="V9HiWnurHb2CT5ymh8UhLa8SEwtGrdqtD" X-Originating-IP: [31.13.191.157] X-ClientProxiedBy: HE1PR05CA0185.eurprd05.prod.outlook.com (2603:10a6:3:f8::33) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.1.6] (31.13.191.157) by HE1PR05CA0185.eurprd05.prod.outlook.com (2603:10a6:3:f8::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.22 via Frontend Transport; Sat, 28 Nov 2020 08:23:02 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2ec673fa-7e51-403d-9bbe-08d89376d327 X-MS-TrafficTypeDiagnostic: DB6P189MB0376: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: yXAuWzJVBJ/NkGRonQkAtsAnlCXH+/XwhgNyfGJaBI8SdkPZIfFzHEGZxZT6gC5hakkcqbGAKZj5RrF1XlkBZp58cGt0ABPMurCR4bBeZ0xQ5trXHtb4PoLfsRG8XwSRZlWf3VhewKDaEDPtxEsJAf38VeBodfCFC4N/vC3NpTMJY6yYyzSF8e28kra2VEQBiwz4qHVpIfaRVoK4ywyIU2/akZYAskFIYxMiw9aeboe3q7zGm5pnWtAiy8GsfLA+DPFBgmeh/OfswlQAbY6IXi2byaHl467/eIKFNBWevmkzeow0oUQZbToK0tUeUchvEHh43oJImybbXsGdrfIXI7Jnqx7NJej51mqoW2OTmCIbe+KGJagGrv5hxf3amG1d7OcngQNl1SDEh7Kiu/ZwOudvvS7yr8P6g2awGZjnMXC8EXKl1M9k43foZsIuyOYgOcGq612X87Apnw9ZKGn0yQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(136003)(346002)(376002)(396003)(366004)(44832011)(6666004)(316002)(2906002)(966005)(86362001)(16576012)(956004)(33964004)(66476007)(36756003)(53546011)(186003)(66556008)(66946007)(52116002)(2616005)(5660300002)(8936002)(83380400001)(235185007)(31686004)(26005)(8676002)(21480400003)(4001150100001)(478600001)(31696002)(6486002)(16526019)(6916009)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?VmNGbTBvQXVVMGNZVnBVbThXVXphb0xDakRPbVA2bS9jV0VERG1OTXliV1ZW?= =?utf-8?B?K21YNUlDUXExSHRPWDl6Y2c5MUZETUhGTEhXakMvMkU3dUsvRjNHK1BTWVBN?= =?utf-8?B?Y3dqNDJaS3NVMHRrZlJqREtCd0hISWllTTd1ZnBBWm81aXV0STZDMmxKK1ph?= =?utf-8?B?eVJSRzdSQ1Q4LzA3UmMwQVN6WUxUeTI4V252QjFJbW1ndlA4MFQwcmt1Wmcr?= =?utf-8?B?Y2U5Wk54Qk5zZm5BZ3lxMzhPQ01KbTk1RTJFLzd4bzVTdVkzWkhwdEpucGxr?= =?utf-8?B?aHRIb1ltbUxQMlMvTHgyK0N4aW54cjc0RDZ5VmRKUXFaN2hZN3NvNGtxYjZt?= =?utf-8?B?OTF4TFNNY2ZocGZYaVgwQTd1cGhpWDNNVVpjL3E1MzRpWCtHakY5UG1aSUM0?= =?utf-8?B?dW15WWNRMzVJVzc1cndQUk1jWHluYU42YU1XZEw2TnFFQ3hmR1RqMVhBc1dn?= =?utf-8?B?dmltT0R6cWZVbnhPeTZFdjJwdEhjYlFGK29VTG80Tis2YUdHcU5OSVVaTFN4?= =?utf-8?B?T2VKWEJZcjZ6K1UwNHRZaXhxdVpkVzRFR294MmlubGhHdEc1Y09CMk5hVTlZ?= =?utf-8?B?bHF5OXlyZlJQWkg0K0czdDE0TXhWbG95UGErNkJOS05tWCtleXdxUGhoU0Fy?= =?utf-8?B?L0kyNTNDK0o5RWZYTTQxN1BESmhnRFZpaHAwOWFrd1Rab2REanVjOWlCQkk3?= =?utf-8?B?RkgrSzI3VVFucVRhRDJ3TTV2a0pmSzlHU0xHcDlOM0diZkQrWTd0RE5CUlZs?= =?utf-8?B?MmY3ODBkaVkwUmhsd0QyN0NydUpXSkNIN24ra2RVODBKY3hTLzdQRVhQeVk0?= =?utf-8?B?cEJWdlV6K3NMb3lTY3VmYTQ5NnlqRWJOWTBEd3dkZHhQOURaZWZHZEVvbC9y?= =?utf-8?B?RFlZYktRVGxpd29sNm9pTVlWTWhxdFliekRHQXc5NktNMnJrU3lwZHBkc2FD?= =?utf-8?B?RmlEZFZRMm5vNy9RWWFYVitvUWR0SmJMeUNyZGt5dVFjUlhVaGY3ZTE1cExz?= =?utf-8?B?OUREZ2dkcVpORG10QzlTNFNha0lSU3lvdHhHb2twSzBvZEREOG1MTVkxbmZT?= =?utf-8?B?OHN0MUpTcURUd3F3anQvbEJJM1Jtb0JLeGoxT1pNaExIS2hvcHBORHBXRW5R?= =?utf-8?B?M3VZaXJ6ODlYRkR5QllGSVloeitmckxiQmNSUlYwNnJkWEhZaWt3ejZ3Wml1?= =?utf-8?B?UEJaZVg1YTdPWG8zQ04zdXVYSzQzVExkRC9hNkFYUG1vVGEzcUw1TkcvaVMw?= =?utf-8?B?NWRvbG5PRkZTZnAyMWV4djAzQXlFRmlwU2h5Ym9Uck5vRHUvTU9Gamt5akR2?= =?utf-8?Q?2urxd1TOVspMvM3xCZol2mlvkEuGRF1uAx?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 2ec673fa-7e51-403d-9bbe-08d89376d327 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Nov 2020 08:23:03.7488 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: kSJcnt2jzXzV22MKniDb4WTuZ6pgobDm6UwKuaIvd0k2egoLR/psybkd8Ke38OH95SX8HbRcvYublj0RkDlbGQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P189MB0376 Archived-At: Subject: Re: [core] CoRE @ IETF 109 - Minutes and summary X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 28 Nov 2020 08:23:11 -0000 --V9HiWnurHb2CT5ymh8UhLa8SEwtGrdqtD Content-Type: multipart/mixed; boundary="T372uVqR93wbnbS3gJ3YDVGpfYcogjjl6" --T372uVqR93wbnbS3gJ3YDVGpfYcogjjl6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, On 2020-11-23 14:48, Marco Tiloca wrote: > The recordings of the two CoRE sessions are now available Due to audio issues in some segments, the recording for the Friday session has been fixed and re-uploaded on Youtube, and the old flawed version was deleted. Please, find the recordings of the two sessions at [Day1][Day2]. Best, /Marco [Day1] https://www.youtube.com/watch?v=3DaCiY4HS0-IY [Day2] https://www.youtube.com/watch?v=3DiCWg3hMirOQ --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --T372uVqR93wbnbS3gJ3YDVGpfYcogjjl6-- --V9HiWnurHb2CT5ymh8UhLa8SEwtGrdqtD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl/CCOUACgkQ7iZktA5Y 2kPuKQf/VDtrkwjpcWDpwbdCJHx85uxZJ9xWdYRdH88IhwCWsoabbZ/4P5bdIrt3 33EN67SNKCFFJRRqOI533pFTaypb6kkbE4MOCkby2zveS1FpyCo9f4Qp+97wrzzr slzf0HIlhV75Gc9clAjAEfXAFJNRGvcV9kzmJId2rY5yov0oSUe/9cLffiFmabJR blgSP5kvqbt9ym5B2Qq1smg1Azs5LB9KxDBT6cJHCV1aCWESJUHjjxnolGEcj2jQ qsBNxiZu8Sk+yoFPfsmIAMyPiTkiDU226adwBbuUKgmMnAMT2jV9akun4Oe3OM2c xgUgXpne64/WO9jRg6jp2fYRVsOiLg== =W7g8 -----END PGP SIGNATURE----- --V9HiWnurHb2CT5ymh8UhLa8SEwtGrdqtD-- From nobody Mon Nov 30 01:01:22 2020 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 C3B1D3A116F; Mon, 30 Nov 2020 01:01:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu via Datatracker To: Cc: last-call@ietf.org, core@ietf.org, draft-ietf-core-dev-urn.all@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160672688076.4884.18269575790406202908@ietfa.amsl.com> Reply-To: Dan Romascanu Date: Mon, 30 Nov 2020 01:01:20 -0800 Archived-At: Subject: [core] Opsdir last call review of draft-ietf-core-dev-urn-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2020 09:01:21 -0000 Reviewer: Dan Romascanu Review result: Ready This informational document describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. URNs can be easily passed along in an application that needs the information, as it fits in protocols mechanisms that are designed to carry URNs. This URNs usage is an alternative to Universally Unique IDentifiers (UUIDs) for cases where it is important that the identifiers are as simple as possible and where additional requirements on stable storage, real-time clocks, and identifier length can be prohibitive. The document is short and clear. There is no significant impact form an operational or manageability point of view. It is useful for network operators to read Section 4 (DEV URN Subtypes) which can provide useful information for operational actions or troubleshooting. This document is READY from an OPS-DIR perspective. From nobody Mon Nov 30 15:00:04 2020 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 5241A3A123F; Mon, 30 Nov 2020 15:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder_via_Datatracker?= To: Cc: core@ietf.org, last-call@ietf.org, draft-ietf-core-echo-request-tag.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160677720227.31587.6421946105112933351@ietfa.amsl.com> Reply-To: =?utf-8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= Date: Mon, 30 Nov 2020 15:00:02 -0800 Archived-At: Subject: [core] Opsdir last call review of draft-ietf-core-echo-request-tag-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2020 23:00:03 -0000 Reviewer: Jürgen Schönwälder Review result: Has Nits The document defines enhancements for the CoAP protocol that close a number of security issues. Operationally most relevant is likely the Echo option, which can help to reduce the abuse of CoAP for DDoS amplification. The proposed Request-Tag option resolve ambiguities with block transfers and as such is most relevant for some CoAP applications but less so for the Internet as a whole. The document is well written, it was a pleasure to read it. I believe the document is ready to be published except two nits that confused me while reading through the document: - The number of 152 bytes mentioned in section 2.4: 3*152 would be 456 octets, I am not sure why this is the "typical size of a frame on the wire sent across the Internet". Either explain how you obtained this number of consider removing it in case it does depend on assumptions that are not guaranteed to be always true. One option could also be to simply drop this sentence. - The difference between Figure 2 and Figure 3 is rather subtle. I actually diffed the figures to find it. My understanding is that it is really only the labels t0 and t1 and e0 and e1. One could perhaps change the figures to make it more explicit when t0 (e0) take place, perhaps also clarifying the text a bit. There is perhaps some confusion caused by the notion of time t0, t1, the notion of events e0, e1, and the notion of tag values labeled (t0) and (e0). The text says "The server verifies freshness by checking that e0 equals e1, where e0 is the cached value when the Echo option value was generated, and e1 is the cached value at the reception of the request." I found this confusing. It think what you are trying to say is that the tag value cached at event e0 is the same as the tag value received at event e1, no? From nobody Mon Nov 30 16:22:56 2020 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 2AF633A12AC; Mon, 30 Nov 2020 16:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=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 D7j_i9kb-GeE; Mon, 30 Nov 2020 16:22:48 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B6F03A12AB; Mon, 30 Nov 2020 16:22:47 -0800 (PST) Received: from [192.168.217.118] (p548dca87.dip0.t-ipconnect.de [84.141.202.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4ClN9022HkzyTl; Tue, 1 Dec 2020 01:22:44 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <160677720227.31587.6421946105112933351@ietfa.amsl.com> Date: Tue, 1 Dec 2020 01:22:45 +0100 Cc: ops-dir@ietf.org, last-call@ietf.org, core@ietf.org, draft-ietf-core-echo-request-tag.all@ietf.org X-Mao-Original-Outgoing-Id: 628474965.345865-55a8d920fb97e13c311db34f5516b5ba Content-Transfer-Encoding: quoted-printable Message-Id: <03FA6734-BD39-4B6A-AD3A-2910325548D8@tzi.org> References: <160677720227.31587.6421946105112933351@ietfa.amsl.com> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [core] [Last-Call] Opsdir last call review of draft-ietf-core-echo-request-tag-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 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, 01 Dec 2020 00:22:52 -0000 Hi Juergen, thank you for this review. I was intrigued by one of your nits: > - The number of 152 bytes mentioned in section 2.4: I think you are discussing this paragraph: * Amplification mitigation should be used when the response would be more than three times the size of the request, considering the complete frame on the wire as it is typically sent across the Internet. In practice, this allows UDP data of at least 152 Bytes without further checks. I think this is trying to say that responses of 152 bytes are not = requiring amplification mitigation under this rule, so there seems to be = an assumption that the request would have been about 152/3 ~ 51 bytes, = which is close to, but smaller than an 40-byte IP, an 8-byte UDP, and a = minimal 4-byte CoAP header, which is 52 bytes, but then there are = Ethernet headers and trailers, making the request 70 bytes (or 50 bytes = for IPv4, which then becomes the minimum Ethernet frame of 64 bytes). = The maximum response would then be 3*70=3D210 bytes on the wire, minus = 18+48 bytes Ethernet/IP/UDP, leading to 154 bytes =E2=80=9CUDP Data=E2=80=9D= . I don=E2=80=99t know. > 3*152 would be 456 octets, I am not sure why this is the "typical > size of a frame on the wire sent across the Internet=E2=80=9D. Typical size of the frame (or packet?) of the request, not of any packet = on the Internet. I=E2=80=99m sure this could be phrased in a way that is a bit easier to = follow. The number to be explained is not so much the 152 (the exact value of = which I don=E2=80=99t really understand), but the three. > Either > explain how you obtained this number of consider removing it in case > it does depend on assumptions that are not guaranteed to be always > true. One option could also be to simply drop this sentence. Indeed. > - The difference between Figure 2 and Figure 3 is rather subtle. Very subtle. =E2=80=9CCthulhu!=E2=80=9D vs. =E2=80=9CComic Sans=E2=80=9D = (and t vs. e). Gr=C3=BC=C3=9Fe, Carsten